World: r3wp

tabbing is very suspect

I think I've mentioned it before :(

spinner arrows too large .. can only see the top one.

I only updated spinner and tab-panel though ..

ahh.. rebgui-ctx also has changed

Need arrow as well.

rebgui-ctx has to be updated each build as that is where the build 
number is set (displayed in %tour.r).

Ok, got it.

tabbing is very suspect

 Agree, it used to be simple and work well ... then folks started 
 wanting stuff like full keyboard navigation. ;)

keyboard navigation is however the only way to drive a gui at full 
speed .. by ignoring the gui!

Use REBOL/Core and an ASCII interface then! ;)

can the increment value in a spinner widget be changed dynamically?

I was watching the girls at the office drive an EMR ... all done 
by keyboard navigation.

very quick.

but of course there is a lot of training required to learn all the 
keys ( shift, control, alt on every key )

Yep, as can min and max (e.g. s/options/3: val).

ok

all done by keyboard navigation.

 as long as the widgets don't require much internal navigation. There's 
 a world of difference between a screen with 12 fields and one with 
 drop-downs, tables, scrollable areas, check boxes and radio buttons 
 (to name a few).

I suggest that for spinners, allow users to start with a blank spinner 
so that they can type in their own initial values.

the value can then be co-erced to the same type as the max/min

when I tried this using an empty string as the initial value in the 
example above, I got this

** Script Error: Expected one of: string! - not: time!
** Where: unfocus-action
** Near: face/text: form face/data: min max

since the spinner is editable by the user, any values not entered 
of the correct type will presumably crash the app.

No, type conversion is wrapped within an attempt and defaults to 
previous value on failure.

And the type is determined by the initial value?

No, by current type of options/1

this is currently not possible:

spinner options [ 9:00 24:00 0:30] data ""

Agreed, the assumption is that data must start with a valid default. 
I'm looking at how to enable data to default to none and text to 
"" ...

Thanks

Group-boxes, for me, have a visual anomaly now where the left edge 
eats into the label text of group-box

build#57 committed to SVN. spinner and group-box fixes as above.

Looking good!

I'll look at the tabbing issues later in the afternoon.

build#58 committed to SVN. Fixes 2 major tabbing issues:


 1) tab-on-enter now fires *after* calculation of next field (so works 
 correctly with show-focus)

 2) tabbing within tab-panel fixed (next field is prevented from looking 
 at non-displayed tabs)

How exactly are tooltips used?

Check %tour.r for an example.

Ahh.. never noticed them before!

So, tooltips are only used with the toolbar?

Try moving your mouse over the big RebGUI logo in %tour.r ... then 
look at the very first line of the display block! ;)

They can be used with any widget as follows:

	display "Test" [
		field tool-tip "Some help text"
	]

Ok, pretty much the only thing I have changed is to use the latest 
rebgui .. and my app which normally used 0% of cpu, is now running 
0 - 20%, and sometimes 99% .. even when doing nothing.

Has anyone else seen this??

Linked in an old version of rebgui and the cpu eating problem disappears.

Reverted to 0.4.2

I've re-encapped all my apps with the latest build and they all idle 
at 0-1%. %tour.exe idles at 50-75% though! Hmm, I might cut widgets 
out one at a time to see if it's a particular widget (e.g. anim or 
a timer) or just the number of widgets/events that's the problem. 
Good catch (I've been more concerned about optimizing for memory 
use of late, not CPU).

typing felt a little sluggish and I was exploring why!

Found the culprit! Set rebgui-ctx/effects/tooltips: false and things 
should return to normal. Next build will default to off unless I 
can fix this.

ok.

tool-tips or tooltips ?

tooltips

Some crude benchmarks with %tour.r

	tooltips: true		60-70% CPU
	tooltips: false		3%


Heavy optimization cuts the first one by 5% and the second by 1%, 
but the base cause of the problem is this line in rebgui-display.r:

	find-face event/offset event/face ctx-rebgui/tooltip-sensitive


which is needed to get around the View detect bug described here: 
http://www.rebol.com/docs/view-system.html#section-5.7