World: r3wp

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.

I didn't actually have one widget in the scroll-panel - this was 
just a test :)

How about a 'clear-values accessor?

Use set-values ;)


The problem with clear is that it is context dependant, and could 
be:

	""
	0
	none
	true
	false


quite often the definition of 'clear-values would be more akin to 
a reset function; "restore these widgets to my app-defined set of 
defaults" ... far better to make it explicit with 'set-values then.

That's what I did .. used set-values :)

I never clicked on Luis' second link in his post http://www.useit.com/alertbox/tabs.html
Jakob Nielsen's Alertbox, September 17, 2007: Tabs, Used Right.

Cool stuff, the good news is we do every single item correctly in 
Quilt.

Vertical tabs - What are anyone's thoughts on vertical tabs?  They 
look cool, and I can see their use, but they strike me as...well...annoying, 
similar to my issue with Rotary (spinner).  Rotating or obscuring 
information just seems not worth it.

Here is an image of vertical tabs 
http://en.wikipedia.org/wiki/Image:Vertical_tabs_sample.png


Coloured tabs - As to colouring tabs, interesting.  I'm a big opponent 
of colours generally.  One of the most common requests we get on 
our Calendar is to be able to colour meetings.  We ARE indeed going 
to allow this, but I think it is better to keep things neutral.  
On the Mac, meetings are "categorized" into things like Work and 
Personal, each of which are given colour.  This works well in "personal 
calendar systems", but this breaks down very quickly when working 
in a "collaborative calendar system".  

Who gets to decide the colour of something?

What is "something"?  As in, is it by project, by who is in it? By 
what it is (a meeting, a flight, a memo, a call, or other things 
people can put on a calendar now).

All very tricky.

Whe nI say Mac, I'm speaking of iCal.  An applicaiton on the Mac. 
 Which is very nice looking, but breaks down with REAL use.

My points of view is founded in usability, so

Vertical tabs: They're not good, when the text is rotated, because 
it requres too much to read it then. Vertical tabs are good in a 
telephone book e.g., where each tab only has one letter: A, B, C, 
etc.

Colours: I like colours, when it doesn't look like a painters palette. 
Done right, colours are very good to give info, so you don't have 
to read the text to understand.

Jakob Nielsen does write many interesting things, like this about 
web functionality, he wrote in 2000: http://www.useit.com/alertbox/20000625.html

Read it in general (and not so much about .NET, that's just one technology). 
It takes time to move the technology and people's behaviour, but 
I think, he has many valid points.

I wonder if even ABC is too hard on the eyes.   Perhaps that is the 
limit (one letter or number).

set-values seems to require a 'show after this to update the display.

I'll add a show to it, along with a no-show refinement, next build.

My first impression on the tabs is I would prefer the color effects 
of unselected and mouse over to be reversed.  It seems backwards 
to have it go from the bold green to the faint green when you mouse 
over.

I've got some drop down lists that are inside a scroll panel, but 
the bottom of the drop list goes beyond the bottom of the scroll 
panel.  this means that I can not see the bottom of the list and 
because there's no keyboard navigation of the drop list, I can't 
choose the bottom choices.

http://synapse-images.s3.amazonaws.com/drop-list-display-problem.png

Got this on clicking on the tree

make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [pane/1/offset/y: pos 
        pos: pos +
    ]
    where: 'show-node

Nothing appeared in rebgui.log

I hope it's not because I've been adding to the tree/data ....!

That would be it. Unlike other list widgets, which use a face iterator 
to only display visible faces, tree takes a brute-force approach 
and pre-builds the entire tree based on face/data. At runtime it 
uses face/data to work out where to position faces.

Can you point me to some screen shots of the newest RebGUI, perhaps 
a few examples from some applications using it?  Anyone...

Also, I will be finishing those logo examples today.

I'm not sure if the latest is intended to be the latest as it were. 
 A large number of graphic changes were made.

Correct, the look and feel is a work in progress at the moment.

screen shots of the newest RebGUI

 ... I've created a snapshot release here: http://www.dobeash.com/RebGUI/rebgui112.zip


Just unzip and run %tour.r and %RebDOC.r to get a feel for where 
things are at.

How's your resize support? The tour and RebDOC were too big for my 
screen resolution (1024x768) and the windows weren't resizable.

Resize works, but only %tour.r uses it at present. If resizing is 
enabled then the *minimum* screen size is set to starting screen 
size unless explicitly set via a refinement. Problem in this case 
is %tour.r has "grown" to 696x785 and %RebDOC.r is 800x829 (and I've 
not used 1024x768 for a couple of years now). I'll fix this for the 
next build though.