World: r3wp

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?).

Build 205
- Added request-list
- Added request-email
- Added do-events
- Updated request-spellcheck (added image)
- Updated request-error
- Updated request-value
- Label size now defaults to 25x5 (was -1x5)
- Replaced "attempt" logic tests with "error? try"
- Memory footprint drastically reduced
- Added no-wait to display func
- Updated request-progress to use display/dialog/no-wait
- Fixed button over state bug
- Fixed slider jerkiness

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

Memory footprint reduced? RebGUI tour.r always showed 11something, 
now it starts over 12MB usage ....

RebDoc request-error ends RebDoc - missing argument, ditto request-list, 
request-value crashes RebDoc (populated after request-speellcheck)

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

Build 206
- Fixed slider
- Fixed request-char
- Updated request-error
- Updated request-email
- Cosmetic changes to:
	- scroll-panel
	- led
	- led-group
	- radio-group
	- menu
	- sheet

I still insist, that LED design is absolutly terrible - the circle 
is way too big and it really imo ruins the feel of the design :-)

Why horizontal scroller shows different dragger symbol than vertical 
one?

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

yes, dragger is hard to distinguish from the "gutter", whatever gutter 
means :-)

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 ...

LED design - I don't mind how LED is represented, I do mind its proportional 
size. IMO LED (and maybe even radio) circle is way too big.

Zero divide with tour.r - mine works ok here ....

dragger symbol .... maybe I preferred not so well centered "||" instead 
of "+", but I don't mind plus sign - it is just that I think that 
it might cause some questions from users ....

Just click on the scroller without  any text in the area

Ashley - what about my memory consumption note? Should tour.r show 
less memory usage? As for me, it is quite opposite, but not by much.

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]]]

It seems to apply to any tabbable widgets inside panel.

Build 207
- Fixed slider bug (zero divide error when ratio = 1)
- Added find-key-face to needed funcs when not using view.r
- Added undisplay (does what unview/only does, but better)
- request-error now accepts string
- Removed gui-error (obsoleted by request-error)
- Removed find-face func
- Cosmetic changes to:
	- led
	- led-group
	- radio-group
	- chat
- Removed tip & over? attributes
- Made init, options & old-color attributes optional
- Made action & feel objects optional

- Replaced rebface, subface, gradface & btnface with baseface & gradface
- Added over? function
- icon changed to accept file name directly

- Added action/on-time event (used in conjunction with rate - see 
anim)
- Added table & text-list alternate row coloring

Looks nicer and polished. The only note to UI from my side - button 
gradient - makes white text badly readable ... but other than that 
it looks good. Nice addition with row-coloring for table and text-list 
- such small detail and it looks much more pleasant ...

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.

I agree .. it's all about the detail

display "" [button [display/dialog "" [field]]] do-events ;; nothing 
pops up when clicking the button, why? only me?

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

Maybe tree widget could benefit from row coloring too? Would look 
consistent with table and text-list.

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!

.... sounds cool!

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.

Build 208
- Fixed unfocus bug
- Fixed table focus bug
- Enhanced request-verify (auto-calc label widths)
- Reworked tree to use face-iterator
- Reworked request-dir

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?

How can I collapse nodes in new Tree? Tree without graphically distinguished 
nodes looks strange :-)

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 ...

Graham and Ashley - thanks for window title hint, so simple...


The other big problem I'm still having is crash when tabbing. It 
worked with 204 and  before. I doesn't work with 205 - 208 .

>>display "" [panel data [field]]   ;; click on field and press <TAB> 
button - bingo!?

Group-box and scroll-panel seem to have the same problem.

Uploaded some more focus bug fixes ... should solve these issues.

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

no resizing unless you add the resizing #WHXY etc

I'm sorry, I copied wrong code.

>>display "" [panel #H data [field #H]] do-events ;; panel doesn't 
resize at all

>>display "" [group-box #W "" data [field #W]] do-events  ;; group-box 
resizes and looks like panel, why both?

Disregard >why both?< part. There are more attributes with group-box, 
I just found.

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.

Menus - good first step, but menu should not close upon mouse-away 
... it should close upon ESC, or click-away ...

Slight problem with hilighting in Toolbar widget ... try randomly 
moving away from icon, sometimes it stays hilighted, so you can get 
multiple icon hilighted ...

The over effect is mild too, and without Tooltip, I would not probably 
use toolbar in my app ...

Build 210
- Fixed dialog modality bug
- Fixed tab-panel actions
- Enhanced radio-group (auto-size label widths)

- Added back #R and #O span directives to handle imbedded reverse 
widgets

- Moved window-feel out of display func and share across all displays

The #R and #O directives handle this case:

display "Test" [
	panel #L data [
		field #L
		reverse
		button #R "Cancel"
		button #O "OK"
	]
	return
	bar 75
]