World: r3wp

Noted.

Dunno if something changed for Sheet widget, but cell borders are 
somehow too bright here, almost invisible. Can that be set? Hmm, 
in rebdoc it is a bit darker or maybe my eyes are too tired already 
:-) What color does it use for borders?

Ashley - will sheet and tree-view support at least keyboard basics?

What color does it use for borders?
 ... none, it's transparent.

will sheet and tree-view support at least keyboard basics?

 sheet already supports tab, tree at present has no keyboard support. 
 These are on the "things I'd like to improve one day if I have nothing 
 better to do" list. ;)

none? transparent? Aha, so if I see "grid lines", it means it comes 
from background color, right?

You know, Ashley, there are several measures to UI and its usability. 
I noticed that ppl really warry, some do most of the things using 
mouse, and then RebGUI is 98% correct (no scroll-wheel support here 
or there, area not being able to auto-scroll when hiliting). But 
those used to keyboard, are suffering much more pain. And believe 
me - although I can understand minimalistic aproach to RebGUI (and 
it really feels better than VID2 in almost all aspects), in the end, 
if widget "missbehaves", I really don't care that, if it is 6KB or 
12KB - all I care is - does it behave as expected?

well, I believe some of the small details can be fixed. I could easily 
name them, list them here, if it would help to answer us, what is 
fixable, and what is not (e.g. due to View inefficiency in particular 
area)

Providing keyboard support for inherently graphical controls (e.g. 
radio-group, spinner, etc) is IMHO a waste of time. All the main 
input widgets (field, edit-list, area, sheet, etc) should and do 
have proper keyboard support. If you're designing an application 
for fast data entry then you should confine your widgets to those 
that accept keyboard input (i.e. data entry forms). If you want a 
rich GUI with a full set of graphical widgets then I don't think 
it's too much to ask that users have a pointing device. I mean, you 
don't expect users to use Windows without a mouse? Or Office type 
applications?


But, list away as I'm currently doing major code fixes (better scroll-wheel 
support for one) anyway; if it's relatively straight-forward to do 
I'll do it.

List of some inefficiencies of RebGUI - decide what could be fixed 
with no significatn effort (e.g. widget redesign or particular subsystem 
redesign (tabbing))

1) no keyboard navigation to swith between the tabs (ctrl + tab)

2) no default focus on page? (maybe just not defined in tour.r), 
but if there is e.g. table, I would expect it being in-focus, so 
that keyboard immediatelly works without the need to click the table

3) are othere elements tabbable? I noticed that e.g. on tab with 
sheet demo, buttons are tabbable. IMO there should be also one primary 
element selected as being "in-focus", it should be reflected in UI, 
or I regard it being faulty.

4) sheet widget - define ENTER action doing the same as TAB action. 
Enhancement request (not necessarily needed) - ability to define 
tab/enter movement direction - vertical vs horizontal.

5) menu - when mouse moves, menu should collapse/expand upon the 
movement, not needing 2 clicks (to collapse old position menu, and 
another click to open one - please reduce at least to one click)
6) tree-view - add arrow support
7) area - hilite by mouse or keyboard should auto-scroll area

8) state elements - add tabbing support with visual reflection - 
imo you are wrongly assuming, that users might not use keyboard here 
(space selects)

btw - what is the graphing widget you liked from Robert's distro? 
Is it any different from what is in tour.r? Is there any screenshot? 
:-)

As to my above requests - those don't add features, but fixing them 
would greatly enhance usability. Users are imo forgivable to how 
app looks, but not how app behaves ...

i would like to be able to use a tab as a tab inside an area widget.

And not tab to the next widget.

Should RebUI do anything that Windows and Mac don't?  Seems there 
are going to be places where a cool widget would save space, or allow 
for a neat trick, but............it also means something most people 
won't know or understand.

For example, radio buttons are the core of:

Radio buttons - O Apple  | O Pear | O Banana


Tabs - Are just radio buttons where the selection IS the card /Apple\ 
/Pear\ /Banana\

Combo-box - [_Apple_[^v]


Then there was a button on the Amiga which was really cool (spinner?), 
but never caught on.  Every time you clicked on it cycled to the 
next option in the list.

Spinner - [_Apple_[O] 


This widget is very useful for toggles, and perhaps even up to three 
states, but after that is loses its value.

ROTARY is the VID equivalent of spinner. 

	view layout [rotary data [a b c]]

Gregg, what are your thoughts on this widget even existing?

I rarely use it. Because you can't see all the values it's not as 
user friendly IMO, though it is space efficient. For small displays 
I can see it being better than a drop-down in some cases.

it would be more efficient, if you could use the mouse to drag left 
and right with mouse button held down to browse between many values.

If there is a big delay selecting elements then combo-box is better 
because you don't have to move through all intermediate elements. 
If there is no delay then the spinner is good too.

Is the original data block for a tree available?  I wish to traverse 
the tree and prevent users from adding duplicate leaves

there are no accessors to add leaves?  
Does set-data work?

Nope.

Is the original data block for a tree available?
 yes, as face/data
there are no accessors to add leaves?
 correct, it's a very basic widget at this stage
Does set-data work?
 ... only from within init at present

face/data just gives the currently selected node

Hmm.  Anyway of refreshing the tree to show a new node/leaf??

Not at present. When I said face/data before I meant widget/data.

So, I have to recreate the whole layout for tab in order to refresh 
the tree ?

i would like to be able to use a tab as a tab inside an area widget.

 That would be kind of confusing. Imagine a display with a couple 
 of fields and an area ... I hold down the tab key and suddenly I've 
 navigated to the area *and* inserted a couple of tabs. Wouldn't a 
 "special" key combination suchh as CTRL-Tab be better?

well, I think I would more often use a tab inside an area, then tab 
thru one.

So, I would prefer ctrl-tab to exit an area ....

I think it's un-natural to use cntrol-tab inside an area to get a 
tab.

what do other gui's do?

ctrl+tab can work in linux but not in Windows.

(unless you find some way to capture ctrl+tab in Windows)

shift tab?

For edit-panel, I thought ctrl+tab would be ideal for jumping out 
to other widgets and then can continue to tab as normal.

but the question is how to capture it on Windows.

shift-tab taken for tab backwards

I would avoid shift tab because it's typically used for ... exactly, 
tab backwards.

Uploaded build#112 with extensive changes.


1) scroll-wheel support added to scroll-panel (CTRL+Scroll to scroll 
the horizontal scroller)

2) set-values and get-values fixed (added support for scroll-panel 
and fixed a few bugs)

3) Added a new widget, pill, that is basically a box with rounded 
corners

4) Changed the look of tab-panel so that the current tab is same 
as page background and remaining tabs have a solid color

5) splash requestor now accepts a file! or image! (so you're not 
forced to provide a spec block if you already have an image)
6) Experimental new logo

7) Color management is being totally overhauled (I'll post separately 
on this topic)


*** Do not sync this build if you want to retain the "old" look & 
feel ***

RebGUI color management.


The "old" RebGUI color management system evolved by adding new colors 
to ctx-rebgui/colors as and when a new color was selected. Many of 
these colors (e.g. button, tooltip*, btn*) were widget specific. 
In all, 15 colors were defined. In addition to this, a number of 
hard-coded colors such as white, black, coal, red and blue were scattered 
throughout the system.


The effect of all this was to provide a means whereby *most* colors 
could be changed, but the design of a "theme" other than the default 
WinXP scheme was problematic.


The new color management system rationalizes these colors down to 
a base set of 8, being:

	page
	text
	theme-light
	theme-dark
	state-light
	state-dark
	outline-light
	outline-dark


with all existing "old" color references being converted to the "new" 
ones. page and text will usually be white and black (high contrast), 
with outlines being grey, and theme and state being variations on 
the same color. The updated request-ui shows how these themes can 
more easily be chosen (there is a drop-list beneath each of the theme 
and state groups that sets both light and dark to a similar color).


This is still a work in progress, and I am basing the model (and 
color selections) largely on those described in the "Quilt design 
style guide"; and colors / ideas from:

	http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines

 http://library.gnome.org/devel/gtk/unstable/gtk-Resource-Files.html
 (styles section)

A number of things have to come together to make this work:


 1) Conceptual model: do we have the right tokens to reflect all color 
 configurable aspects of the UI (e.g. is there a color word appropriate 
 for a highlight selection, a heading, etc)

 2) Are they named appropriately (e.g. is selected better than state-light?)
	3) What colors should be used in what context?


This last one is very tough. As a general rule I've followed the 
Quilt model and used outline-light for non-edit edges, theme-dark 
for edit edges and heading backgrounds, etc (you can find a crude 
list of usage cases under the new "Colors" tab of RebDOC).


But what about a widget like button? It potentially has the following 
color states:

	Unselected	theme-dark
	Focus		theme-light
	Button-down	?

and widgets such as sheet which might have:

	Headings	theme-dark with page font/color text
	Cells		page
	Edges		outline-light
	Selected cell	theme-light
	Forumla cell	theme-light
	Cell that cursor is currently over

and there are a number of ways of denoting this with color:

	as a background color change
	as a font color change
	as an edge color change
	as a combination of the above


In short, there are a lot of ways of implementing this. What I want 
needs to be simple and consistent with as few colors as possible. 
Any suggestions (including links to good color management techniques 
/ approaches) greatly appreciated.

That's a very positive development.

A nice set of global named colours, which can be used by every widget.

I think each widget should have its own named colours for its different 
parts, like "edge-unselected", "edge-selected".

These can be set directly to the global named colours, like colour-themes/light/outline-unselected

or to a function of that, eg:  button/named-colour/edge-selected: 
does [desaturate 0.9 colour-themes/light/outline-selected]
then button just redraws itself using its own named-colours.

why is there any need to make it Quilt or web-anything like? Changes 
are fine, if those don't ruin overall design. I can't see anything 
what happened to button positively - it is now flat, one color box 
with not difference to box widget itself.

Also - why the change to coloring all tabs?

latest checkout


>> display "" [ sp: scroll-panel data [ field 10 "Hello" ] button 
"get values" [ probe get-values sp
]] do-events
** Script Error: foreach expected data argument of type: series
** Where: get-values
** Near: foreach widget face/pane [
    if find [

        area check check-group drop-list edit-list field group-box password 
        rad...
>>

Tab coloring - see Luis's comments from Thursday 25th above.

get-values expects a grouping widget; so:

	scroll-panel data [field field]
	scroll-panel data [tab-panel data ...]

work. For scroll-panel with a single non-grouping widget use:

	s: scroll-panel data [field]
	button [print s/pane/1/text


A pain I know, but using scroll-panel for a single non-grouping widget 
would be pretty rare I'd think.

OK.