AltME groups: search

How about this [ A [ B [ [ ] p] B [[ ] r] B [ [ ] u] ]


so if the first element in the block is empty, we know the next element 
is a key?

I'll have a look at this, meanwhile ...

RebGUI v2 RC1 (build 200) uploaded to SVN

Focus of this version has been:
	* Make it look good (color scheme based on Windows 7)

 * Take into account OS sensibilities (different corner rounding, 
 window colors, system fonts)

 * Get rid of the cruft (removal of little-used widgets and options)
	* Improve tabbing
	* Make it load and run faster



Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?



Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color



Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font



Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]


WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

requesst-verify is a typo

Isn't this a personal thing "Get rid of the cruft (removal of little-used 
widgets and options)" ?

well, symbol is not usable across platforms as it depends on the 
fonts ... but I do use it beside a field to indicate a lookup widget 
is available

removed symbol

 ... not cross-platform (depends on a specific symbol font) ... icon 
 is a better approach IMHO anyway
and question
 ... use confirm instead
options [ info ] is now gone too

 ... yep, soon to be replaced by a global disable/enable system (unlike 
 the widget-specific info implementation
Isn't this a personal thing 

 ... less is more (and easier to debug/fix and maintain). pie-chart 
 (as an example) was a good widget, but anyone wanting to use it would 
 probably want a full range of graphing widgets, not just a single 
 representative example. Having said that, yell if I've removed something 
 vital and I'll add it back (or provide a functional alternative).

symbol ... use it beside a field to indicate a lookup widget is available
 ... use an icon or {button -1 "..."} instead (or an arrow)
sqlab ... what OS?
password field is now showing the text as text
 ... noted

Ashley, that was a long time ago .. where would I have changed the 
font? :)

used to be a requestor

hmm, SVN says:

RebGUI v2 RC1

Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?

Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color

Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font

Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]

WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

I used it, to set boxy design instead of rounded, and also to change 
some colors. I for one like scroller/dragger look, but don't like 
gradiented buttons/tabs ... they look like W9x, which is imo a bit 
of UI regression. I thought Ashley wanted to go more web way, not 
desktop app way (from the design pov)  ...

is it using a smaller font?

I would welcome tour.r would fit 1280x800 notebook :-) I can't see 
buttons nor the top bar, a bit tricky to handle :-)

Windows XP with 1366 x 768


After start of tour.r the upper border is outside the screen and 
the status line not visible.

After moving the window down with the cursor keys, the status line 
gets visible.

After moving  the cursor to the upper edge with every click there 
the main windows moves down a step.

changed from single color web like look to some W9x look, was there 
any reason?
 ... commercial reality ;)
where would I have changed the font?
 ... ctx-rebgui/effects/font
request-char somehow misbehaves here
 ... bug, noted
fonts must be handled differently in w7s

 ... I don't have access to W7 at home, but will check this Monday 
 at work
where do I set my UI options?

 Design time with ctx-rebgui/effects, /colors /behaviors and /sizes

 Adding request-ui back so you can alter these values from a GUI is 
 trivial ... what I've removed is the rebind logic that enabled you 
 to dynamically change values (i.e. you would have to re-do %rebgui.r 
 to see any UI changes take effect ... not very practical for an SDK 
 app)
they look like W9x

 ... the color scheme (with the colors/page change noted above) is 
 taken straight from W7
don't like gradiented buttons/tab
 ... based on W7 and Mac
I thought Ashley wanted to go more web way, not desktop app way

 ... I've actually gone for something halfway (simpler than OS, more 
 complex than Web)
is it using a smaller font?

 ... 12pt by default as always (maybe W7 renders it differently than 
 XP?)
everything seems much smaller
 ... bigger screen? ;)
I would welcome tour.r would fit 1280x800 notebook

 ... RC1 is about getting the basic functionality right, %tour.r and 
 %RebDOC.r will both be made to run 1024x768
used to fit
 ... they havn't been reworked yet
Windows XP with 1366 x 768 ...
 ... will be fixed with above

Henrik .. just do a google search for rebgui codeplex

Build 202 uploaded ( https://rebgui.svn.codeplex.com/svn/)
- Fixed password
- Added icon to tour.r
- Resized tour.r to fit smaller screens

- Reworked layout and display functions to remove duplicate show 
and do-events calls
- Removed do-events from tour.r and RebDOC.r


The layout/display change (apart from correcting numerous rendering 
anomolies and improving layout speed) may have caused other unforseen 
side-effects. At the very least it changes RebGUI in the following 
manner; previously you would write:

	display "A" [...]
	print "A"
	do-events

and get "A"  printed to the console. Now you write:

	display "A" [...]
	print "A"


and only get "A" printed to the console once the display has been 
closed. This now lets you write code like:

	display "A" [ ;do some stuff to set result]
	process result and display "B" or "C" based on result

This change is still experimental so let me know what you think.


Also, who actually uses tool-tips??? I've been debating whether to 
fix them so they work properly, or just remove them entirely. Thoughts?

One note to drop-list. Apart from the fact, that it can be closed 
only by pressing ESC, it does a little bit weird thing - it remembers 
its last mouse-over element. So mouse-over some drop-list item, then 
go-away from it, then press ESC. The value of drop-list changes to 
that last remembered mouse-over one ...

Yep, I need to rework the popup logic (drop-lists, edit-lists, menus) 
a bit. There was/is a lot of code to work around non-existant view 
bugs (which were present pre View 1.3). Most of the weird exceptions 
are now caused by the little-used tool-tip code! ;)

Just wondering if when there are major changes, if they can be uploaded 
to a different branch for testing before being committed to the main 
trunk.

That's a major change .. like changing from view/new to view

I am just trying new RebGUI and like it a lot. There is one, at least, 
big problem with disable.

Sounds like display is now always modal?

 ... I thought modal is when only the active dialog/popup can accept 
 user input? That's still the case, try the follwing:

	display "Test" [
		area
		button "A" [display "A" [button]]
		button "B" [alert "B"]
	]


Press "A" and type some text into the area, then close "A" and try 
the same thing with "B".

Another discovery. One can only select one table at a time. This 
is more serious problem, me thinks. The previous one seems to work 
later, but directtly from display.
And it seems tha I can send more than 1 line at the time now.

I was just testing tables by

>> display "" [table options ["A" left 1.0] data [1 2] table options 
["B" left 1.0] data [3 4]]

1. Only one table can be selected from as I already discovered before

2. When any table is selected from pressing <TAB> causes this ERROR
** Internal Error: Stack overflow
** Where: group?
** Near: all [
    in face 'group 
    get in face 'group
]

Note, that you can "hide" a column like this

options [ "Hidden" left .001 "Visible" left  .99 ]

aren't LEDs a little bit too big?

- opening menu while not closing previous one is allowed - a bug 
imo ... I expect those things fixed with preannounced changes to 
pop-up layer?

This should address the table and disable issues raised above. WRT 
other issues:

stack overflow return
 ... could not duplicate this.
One can only select one table at a time

 ... select = focus, and yes, as focus shifts so to does the "selected" 
 row
And it seems tha I can send more than 1 line at the time now

 ... not sure I understand what the issue is here.Are we saying 'multi 
 is always on now?
hidden column

 ...I plan to properly support hidden columns ... if column width 
 is zero the face iterator will not create a face and it will not 
 otherwise be treated as a "column"
button widths

 ... the width sizing algorithm changed for button, label, heading, 
 etc (basically anything that appears on a single line)

 - previously you had to use -1 (or larger widths) to accomodate larger 
 text as the width was fixed

 - now it is fixed to the greater of it's specified width and it's 
 natural text width; and -1 sizes to the maximum of text width and 
 a line

 - there is no checking for button height (as it is assumed you would 
 either leave it at default 5 or have it larger

- scrollbars are behing a little weirdly. When you press mouse button 
down, and you go away from scrollbar (or not), the content starts 
scrolling even before the scroller is visually moved. Nicely visible 
with RebDoc for e.g.

About my previous musing...

stack overflow return

 ... This is my fault as I  put ctx-rebgui/behaviors/tabbed: [... 
 (no table in)] in my little program. Need another safe way to do 
 that.
one can only select one table at a time
 ... not tabbable table is the only way
hidden column
 ... will use 0.01
button width

 ... basically when one specify [button 100] one get old [button 103] 
 but that's ok if we know it.

More about stack overflow and tables.

When taking 'table from ctx/behaviors/tabbed it still works any extra 
tabbable widget like so

>> [table options ["A" left 1.0] data [1] table options ["B" left 
1.0] data [1] button]

but selecting from one table deselects the other. All tables selection 
was possible with previous incarnation of RebGUI. I hope somebody 
else was using this feature so it's not only me using before and 
wanting it.

title-group and image RebDoc section depend upon image ...
 Fixed in next build
scrollbars are behing a little weirdly
 ... noted

basically when one specify [button 100] one get old [button 103] 
but that's ok if we know it
 ... ah, I understand the issue now. Fixed in next build.

I hope somebody else was using this feature so it's not only me using 
before and wanting it.

 ... don't worry, I think the issue is that table needs to differentiate 
 between a selected row and a row that has focus. This was not an 
 issue in previous versions as table was not a tabbable widget. Will 
 be fixed in a future build.

Drop-list and edit-list cannot be closed by clicking elswhere but 
this is still to be fixed, isn'i it.
 ... on the list to fix
Another little observation.

 ... that's an interesting bug and I have no idea at this stage why 
 the 2nd case doesn't work. Needs further investigation.


Good work marek (and others) ... we're slowly but surely ironing 
out the issues.

A small example of using the new request-error function to handle 
errors in a user-friendly fashion:

	do %rebgui.r
	if error? set/any 'err try [
		display "Main" [
			button 100x50 "Sub" [
				display "Sub" [button 50x25 "Error" [1 / 0]]
			]
		]
	]  [request-error err]

Build 204
- Fixed old refs to %images in anim, image & title-group
- Moved stock images into a new images object
- Changed refs to above
- Fixed button size bug
- Reverted wait [] behaviour

I've reverted the wait [] (do-events) behaviour back to what it was 
prior to build#203 ... so the logic is:

RebGUI v1
	display
		show face
		do-events
		attach window feel
		show face
		if dialog do-events
	do-events

RebGUI v2
	display
		attach window feel
		show face
		if dialog do-events
	do-events

which means the sample code above should now be written as:

	do %rebgui.r
	display "Main" [
		button 100x50 "Sub" [
			display "Sub" [button 50x25 "Error" [1 / 0]]
		]
	]
	if error? set/any 'err try [wait []] [request-error err]


In fact, that last idiom (wrapping the main event loop around a 'try 
/ request-error) is so basic I think I'll redfine it as a self-contained 
func (redefine do-events?).

Slider "feels" better but still has a minor known issue ... face/data 
"jumps" too quickly to 0/1 at the ends.

All fixed in latest build. Ignore my previous comment on memoty usage 
(it was incorrectly measured as a 50% reduction).

With gradients, I have a bit difficulcy to imediatelly distinguis, 
what is the active part of the scroller, and what is the background. 
Couldn't the background be somehow "more relaxed"?

Other than that (and pop-up bugs), it really looks as a polished 
system ...

I have a zero-divide error with  tour.r when i click on the scroller 
of the area widget. I'm using  REBOL/View 2.7.6.3.1 14-Mar-2008.

LED design is absolutly terrible
 ... please provide a link/image of a better design

Why horizontal scroller shows different dragger symbol than vertical 
one?

 ... vertical uses "=", horizontal wasa "||" but those characters 
 don't center to well

what is the active part of the scroller, and what is the background
 ... you mean the dragger is hard to distinguish from the gutter?
Other than that (and pop-up bugs)
 ... table, text-list and tree still need a lot of work
zero-divide error with  tour.r
 ... thanks, added to the list of bugs to fix

pop-ups ... e.g. menu allowing you to enter all three menus at once, 
looks a bit weird, but it is enough for me, that the rework is planned 
:-) The only thing I want for menu and lists, is, being able to close 
them clicking elsewhere ...

Tabbing thru tables when inside panel ends in crash (205/206). Right 
gap inside changes when scroller appears (small worry).

>> [table options ["A" right 1.0] data [1] panel data [table options 
["B" right 1.0] data [1 2 3 4 5 6]]]

Yeah, my major insight over the last year concerning UI design is 
that it's not a question of "great graphics" but simple attention 
to numerous small details ... get the details right and the whole 
lot comes together.

Try using a window title ...instead of ""

nothing pops up when clicking the button, why?

 ... the display function exits if it hits a duplicate window title 
 (before calling layout) ... this means you don't have to worry about 
 the user hitting a button that calls a display multiple times and 
 getting multiple (near identical) windows popping up!

tree widget could benefit from row coloring too?

 ... it will, once I've rewritten it to use the same face-iterator 
 func that table and text-list use (which means it'll get all the 
 extra goodies like auto-slider support as well!

I remember that a previous tour had the tree inside a scroll panel 
and as you expanded the tree, sliders appeared in the scrollpanel. 
 Sometimes you can now display all elements of a tree without that 
functionality.

Note the reworked tree widget only has one option [only], and currently 
defaults to expanded mode with no leading graphics. It accepts input 
in either nested block or file/path notation. Selected items are 
now fully qualified by default. Due to it's use of face-iterator, 
it no longer has practical data limits (previous version created 
a face for each item).

Face iterator - a native R2 View thing?

Now I do seem to understand, what still feels kind of wrong with 
scroller:


- normally, scroller has arrows. One arrow press scrolls data upon 
some number of items

- in regards to above, when you click anywhere else on the scroller, 
it should not jump directly under the mouse pointer, but only once 
again it should move by defined amount of data


... and it is not the case with our scroller. I should note that 
the "wrong feel" is just of a cosmetic nature, nothing annoying ...

Thanks Ashley.

Two more little bugs, not in a hurry:-

>>display "" [button [display/dialog "Tab me" [field field]]] do-events 
 ;; not movement

>>display "" [button [display/dialog "pop" [field field]]] do-events 
 ;; panel not resizing

Build 209
- Fixed #LV span options for
	- button
	- group-box
	- panel
	- pill
- Fixed tab-panel tabbing
- Removed redundant scroll-panel from request-dir
- Reworked on-resize handling for most widgets
- Removed #O span option (made redundant by on-resize)
- Renamed span-size to span-init
- Improved popup handling (drop-list, menu, etc)


Note that this build has [temporarily] broken dialog modality (you 
can click outside of a dialog) and tab-panel action blocks.

You're on the right track. I'm trying to get an image in there without 
creating another face. The 3 places you can have an image in an existing 
face are: image, effect and edge. The first image I want to get in 
there is a folder icon so request-dir looks a bit better! ;)

Thanks a lot Ashley. It worked for me with on-key, but proper way 
is always better. Ta again.

Not that I miss it, just a question :-)

- tooltips - nice, but mouse pointer almost everytime covers first 
letter of tooltip itself ... maybe a bit of spacing/shifting would 
help ...

It's actually a feature a number of users have asked for ... so I'm 
going to make it a behavior flag choice in the next build (hide-popup-on-click? 
... defaulting to true, otherwise current behaviour).

RebDOC bug ... thanks, let me fix that while I'm here ...

My requestor comments, mostly cosmetic issues:

- request-error - crashes ....
- request-font - proportionally tall, should be wider imo
- request-menu - does not work, at least in terms of RebDOC
- requestor icons - imo a little big

- request-password - "strange" - needs more spacing when separator 
line is applied imo.


Take my comments easy. It is just that I was able to find 1px difference 
on our company website - 14 vs 15 pixel in one paragraph :-)

there was a rebdoc error on the requestors as well when I was testing.

I got a crash on using cursor keys on drop list.  The error requestor 
doesn't allow me to copy the text :(

wake-event error near i: 1 + last face/picked

( isn't picked a block normally ? )

Is anybody using append-widget function a lot, or is it only me - 
hobby programmer only?

Any suggestions for  a replacement for the VID toggle ?

above is a result of trying to mix vid and rebgui in the same script 
.. can no longer do this.

hence no further ability to mix VID with RebGUI. I am not sure Ashley 
did not oversimplified it :-) Because - there was a promise of "much 
lower" memory requirements, but the opposite is true, even if RebGUI 
gets optimised. Older version consumed some 11600 memory, new versions 
do consume over 12megs ...

re append-widget; close to ditto Graham, but I now use append-widget 
when I need to link RebGUI fields to persistent RebDB store.  Well 
it's a general purpose data-field widget that can stash code in the 
data (RebGUI keyword) attribute of the gui widget.   See http://www.rebol.org/view-script.r?script=rebdbgui.r
for a (very ineffficient) sample I posted way back when when someone 
asked for a way of getting persistent RebGUI fields.   Used to be 
the same for an overlay panel, but Ashley put in the 'no-tabs option 
for tab-panel and my copy was sent to a shallow grave as the hack 
it was deserved.

just that I was able to find 1px difference on our company website 
- 14 vs 15 pixel in one paragraph

 NP, I've actually been using DigitalColor Meter on my Mac to find 
 both pixel and RGB discrepancies ... so when you see something like 
 "pad 0x-1" in request-edit you now know its because I wanted to collapse 
 two 1 pixel edge borders into a single shared 1 pixel border. As 
 I mentioned elsewhere, its attention to trivial aesthetic details 
 like this that make the overall UI "look good".

I only get the 'load-stock error using the latest rebgui.r

 & "rebgui.r is doing something funny to VID" ... yes, it sure is. 
 The guilty lines of code are in %ctx-rebgui.r:

	view*: system/view
	screen*: view*/screen-face

 screen*/color: screen*/edge: screen*/font: screen*/para: screen*/feel: 
 none
	view*/VID:
	view*/popface-feel:
	view*/popface-feel-nobtn:
	view*/popface-feel-away:
	view*/popface-feel-away-nobtn:
	view*/popface-feel-win:
	view*/popface-feel-win-nobtn:
	view*/popface-feel-win-away:
	view*/popface-feel-win-away-nobtn: none


There's a long explanation for this, but the short explanation is 
that previously RebGUI could co-exist with VID (and I was careful 
not to redefine existing VID words/functions), this made sense so 
long as RebGUI shared some of the same basic View/VID mezz code (in 
particular the popface-feel-* functions, hide-popup and show-popup). 
Once RebGUI v2 went down the path of using its own, simpler, popface 
code then the need to maintain "Chinese walls" between VID and RebGUI 
lessened ... and the option to reuse/redefine View's basic objects 
(instead of creating parallel RebGUI objects) made sense. Once I'd 
made the decision to cut with VID support it made other decisions 
like redefining standard VID requestors (alert, confirm, etc) a lot 
easier. RebGUI can now be developed without worrying about VID compatibility 
or "breaking" VID.

Any suggestions for a replacement for the VID toggle?

 ... isn't the toggle just a drop-list less the drop component? It's 
 a fairly trivial widget to add to RebGUI, but it's not a widget I've 
 seen in any Windows or Mac apps. What do folks think about this widget 
 from a UI POV?

I use them in a forever loop so that the user can start or stop  
People also use them for playing movies ... it changes from a start 
to a pause button.

For instance I use VID to do a print preview ... using a draw dialect. 
 Never tried it with rebgui

Yep, windows media player has a play button that toggles to a pause 
button.

hence no further ability to mix VID with RebGUI
 ... correct.
promise of 

much lower" memory requirements, but the opposite is true" ... not 
quite. A lot has been added, in particular 4 inline images, without 
noticeably increasing memory. Also remember that many of the improvements 
(reduced dependency on View/VID mezz code) will only be apparent 
when using RebGUI with enface/rebface (tour.r uses 13,817Kb under 
rebview here, and 11,223Kb under rebface). Lastly, reduced memory 
usage is not apparent with tour.r as it doesn't reuse a lot of the 
same widgets (i.e. tour.r is a good reflection of "base" memory usage 
not runtime memory usage). If I find the time I'll knock up an example 
that demonstrate runtime memory differences.

I'd like to see an option to use a vertical layout for request-value

Enter the url for your website here. It looks like this http://www.rebol.com/
 [ .......]
is a pretty long requester.

there were somethings I could not do in rebgui so I would switch 
to using ViD in the same application

 ... there shouldn't be any. Both VID are RebGUI are just "face factories" 
 ... feed them a spec and they produce a face object. All other functionality 
 is neither VID nor RebGUI specific. I get a lot of emails asking 
 "how do I do x in RebGUI", but 99% of them are really "how do I do 
 x in REBOL", or, "how do I use the SDK to do x" type questions.

I use VID to do a print preview ... using a draw dialect

 ...RebGUI's use of the effect facet (and hence draw) is no different 
 to VID's. Also note that 'draw is available as a native from the 
 console (i.e. you don't event need VID or RebGUI to use it).

And toggle?

 ... does it need to support more than two states? Does it need to 
 support text (like a button) and images (like icon)?

more than two states is a rotary widget ...

I've been looking at the jqGrid ... http://www.trirand.com/jqgrid/jqgrid.html
and many of these grids use a data source instead of a static block 
of data.

with a data source you can let the pagination occur within the widget

What I do at present is use a tab-panel and have the loading gif 
in one, and then replace that panel with the table once the data 
arrives

Having pagination would really help a lot ... sometimes i have tables 
full of hundreds of items.

why not just ... set-enable f true/false
 ... makes sense, I'll think on that one
use a data source instead of a static block of data
 ... live data?

What do you mean by pagination in the context of a table?

say you have 1000 rows... but you only want to display 20 at a time

better to feed the table from a sql query, or another function that 
holds all the data

The slow-down is from the query side not the RebGUI/table side. Table 
uses an iterator function so whether the table has 10 rows or 1,000,000 
it should be the same speed ... fetching 10 rows or 1,000,000 across 
a network is another story.

I presume altme uses an iterator function as well... I just switched 
from 1000 to 4000 in preferences and now scrolling is a dog.

Try this on 10, 100 and 1,000 rows:

d: copy []
loop 20 [insert tail d reduce [random 10 random 10]]
s: now/time/precise
display "A" [
	table 20x100 options ["A" left .5 "B" left .5] data d
]
print now/time/precise - s

seems to scale pretty well here (on a Mac).

In my app, I have 24 rows, and there is a definite lag belween the 
scroller and what I see on screen.

Even with only 50 items there is a noticeable lag with the older 
table.

Back to your request-value prompt wrap issue ... I just tried it 
under WinXP with build#212 and I get 3 wrapped lines of text. Does 
your requestor have a big blue question mark icon in the top-left 
corner?

Looks like the scroller issue goes back a while .. I tested the version 
where you had the color changes and that is also fast.

My main screen was ViD based as it used a toggle widget .. and then 
the rest was rebgui

So, the improved scroller code was from quite a while ago.

All that for a toggle, you should have said something earlier! ;) 
BTW, the screencast shows a build#1nn widget (pre-gradient buttons).

It was written a few years ago and just recently revamped

Example usage of new in-widget func and toggle widget:

display "Sample" [
	field
	field

 button [set-text second in-widget face/parent-face 'field "Hello"]
	toggle green data ["A" "B"] [print face/data]
	toggle data ["AA" "BB"] options [on] [print face/data]
]

Toggle effect a bit mild.If there would not be 2 buttons on screen, 
I would not easily mean, if it represent pushed status, or let's-pus-me 
status, even if on/off text is available ....

Ashle - changed your code above to allow disable. Try pressing first 
button twice. It crashes RebGUI:

do %rebgui.r

display "Sample" [
	field
	f: field

 button [set-text second in-widget face/parent-face 'field "Hello" 
 disable f]
	toggle green data ["A" "B"] [print face/data]
	toggle data ["AA" "BB"] options [on] [print face/data]
]

do-events