AltME groups: search

Uploaded build#108.

1) Fixed UI quirks with tree widget

2) Renamed vid widget to style

3) Added a new scroll-panel widget

	USAGE:
		scroll-panel data [calendar]
		scroll-panel data [field field]

	DESCRIPTION:
		A panel used to group widgets within a scrollable container.

4) Added a new sheet widget

	USAGE:
		sheet
		sheet options [size 3x3 width 2]
		sheet data [A1 1 A2 2 A3 "=A1 + A2"]

	DESCRIPTION:

  Simple spreadsheet, based on rebocalc.r, with formulas calculated 
  left to right, top to bottom.

  A cell is either a scalar value, string, or a formula starting with 
  "=".

  Scalar values are automatically right-justified, series values left-justified.

  Remember to put spaces between each item in a formula and use () 
  where needed.

	OPTIONS:
		'size specifies number of columns and rows
		'width specifies cell width in relation to cell height


5) Updated %tour.r to incorporate examples of tree (List), scroll-panel 
(Grouping) and sheet (List) usage.

Enjoy!

Ashley, Is there a simple way to get this version, or do I have to 
download & install a SVN client?

Print support - how about a button that will turn the face/parent-face 
into a PNG, save to drive and invoke the browser on it?

this is for rebgui screens .. or perhaps better still, a way to capture 
the shift-print scr on any rebgui window

Ashley, I read that request-dir uses the new tree-view, but when 
I tried it out on a few checkout, and clicked on the "Home" button, 
rebgui froze on me. Reproducibly.

Ah, I had to revert request-dir but forgot to revert read-dir in 
%rebgui-functions.r ... will fix this later tonight.


re: Print support ... I'll look at adding a handler that you can 
assign to an FKey of your choice.

Uploaded build#109 with above fix. Handler is as simple as:

ctx-rebgui/on-fkey/f3: make function! [face event] [
	save/png %screen.png to image! face
	browse %screen.png
]


Just click on the window you wish to print and press F3. I'll add 
this as a cookbook entry.

Just wondering if the tree might return more information than just 
the face text. Say you want to retrieve stuff from a database but 
only want to do so if it is a level below a node.  At present you 
don't know if you're at a node of a leaf.

or a leaf.

So, you have to traverse the data of the widget to find out where 
you are .. and if a node and leaf both have the same name ... then 
you're stuck.

Ahsley, did you took a look at my TREE widget? It's quite matured, 
so why reinvet the wheel?

Robert, can you post a screenshot of your tree widget.  Remember 
there's also the drop-tree widget too.

Robert, yes. Your tree-view widget is a superset of what I need / 
want (and is 21Kb vs my 3Kb).


Ideally, I'd like every widget to be 5kb or under, with 10kb a max. 
After developing and merging over 40 widgets I've come to the following 
conclusions:

1) 90% of the basic usage cases can be coded in under 5kb
2) Double the code size to increase this to 95%
3) Quadruple this size to get it to 99%

4) Time required to maintain / fix and document a widget increases 
exponentially as code size increases

5) A widget that tries to do many things is no longer a widget ... 
it is an app (list-view and grid fall into this category)

6) While developing the sheet and tree widgets I came to the realization 
that the scroller logic could be externalized in another widget (scroll-panel) 
thus removing much of the duplicated scroller handing code found 
in a number of widgets


Where does this leave grid? Near as I can figure it's a combination 
of table and sheet, but supporting cell types other than plain old 
field. I can see how folks want to pull data from a DB and put it 
into a grid, so does that mean we have 'typed' columns or can every 
cell be different. If the later, then aren't we just talking about 
a sheet with support for more datatypes?


And now for the accessors. We obviously want functions to load and 
save data, put and get cells, and add / delete rows; but do we really 
need functions to move columns around? Or hide and reveal columns? 
It's very easy (and tempting) to over-engineer ... but keeping things 
as simple as possible (but no simpler) makes for a stable system 
that is easily fixed, extended, maintained and documented.

I see your point and I totally agree. On the other hand doing a real-life 
full-fledged application requires most of the time more than just 
a basic widget.


What I found out is, that most simple widgets are ok from a GUI POV 
but not in these areas:
- storing / saving widget state and user-data

- be programmatically controlable (like setting a tree to a specific 
state, hiding stuff, setting sort-oder etc.)

- implement always returning usage patterns in a more programmer 
convinient way

- using a common approach for specification (nested blocks, key/value 
pairs etc.)

Yep, a lot of that code is app / context specific; although the widget 
should allow you to extend its functionality via APIs rather than 
having to "roll your own" every time you need a bit of extra functionality. 
scroll-panel is a move in that direction; "I'd like a spreadsheet 
here, and I'll put that in a scroll-panel because I want to scroll 
a large sheet; and I'll add left-click and right-click handlers to 
handle load and save; and assign a screen dump routine to F3, etc". 
All that is currently possible. "I'd like to move this cell from 
here to here" is not currently possible, and I doubt anyone could 
create an API that could let you do *everything*. (take something 
simple like alternating row colors; I had someone ask if the *number* 
of alternating colors could also be specified!)

Uploaded build#110.

1) Improved scroll-panel and tree widgets


2) Replaced request-dir with a simpler tree-based version (WARNING: 
it reads the entire tree from the path given so don't use it to browse 
a root directory)


3) Added a new heading widget (basically text at twice the font size)


4) Added prototype of new RebDOC app (still needs to be generalized, 
and the code / data that drives it still needs to be cleaned up a 
bit - but it shows the direction I'm heading with regards to "self-documenting" 
apps / code)


5) Removed a number of unmaintained widgets (due to growing incompatibilities)

BTW Robert, please don't feel any of the work you and Cyphre have 
done is wasted or unappreciated. You created a solid fork early on 
that meets your requirements. The chart widget in particular just 
blows me away whenever I see it (you should post an image of %test-chart.r 
somewhere, it's one of the most beautiful displays I've seen). Even 
though none, or only a few, of the widgets you sent me may ever make 
it into the standard distro; they have proven invaluable as a source 
of ideas, coding techniques and motivation. Many specific things 
you did (e.g. tool-tips) have slowly but steadily migrated across.

What is table? Are you really serious? It is so much of a joke it 
is not even funny. And I don't care much about in-line editing, I 
never provided any such facility with any of ISes I collaborated 
on. If someone wants to edit, there is screen for that. But - grid 
without horizontal scroll? Without programtic navigation? Ability 
to hide, show columns? Come on ...

This is a GUI framework, not an app. You have to add code to a framework 
to make an app anyways - it's not any different to add other GUI 
controls. I realize that intregration is a process in itself, but 
it can be done, and sometimes it is simpler than rewriting the code 
yourself.

Sometimes the code that you integrate bears little resemblance to 
what it was before, but it still helps to have a starting point.

Petr, simplification can be a feature in projects like this.

This is a philosophical dispute ... but there is nothing to stop 
Robert uploading his tree widget etc under another name to the svn, 
and we can optionally choose to use it.

Agreed, and it seems time (and a good move) to simply offer RebGUI 
Core, and RebGUI Robust, no?

There is something nice though about making it clear in the name 
what you have, and why it is where it is.

I agree with Ashley completely in that RebGUI should remain small, 
and simple.
This seems like a way that everyone can be pretty happy.

the request-dir function has lost the "home" button so there's no 
way of backing upwards in  a directory tree.

was it deliberate decision to remove the functions tab from tour.r

 Yes, RebDOC now covers the same ground. My goal is to pull the content 
 across from %tour.r into RebDOC and then obsolete it (%tour.r that 
 is). In RebDOC the examples will become stand-alone scripts.

RebGUI Core

 ... I like it, and it means we can distinguish general RebGUI app 
 issues from RebGUI Core issues (e.g. keyboard navigation is a core 
 issue, lack of a domain specific "bells & whistle" widget a RebGUI 
 app issue). For me the line is quite simple: if it is an issue that 
 can be fixed by creating a new widget (either from scratch or based 
 on an existing one) then it is probably an app issue; if it is an 
 issue that effects most if not all widgets and / or the fix is to 
 the RebGUI engine itself (e.g. a %rebgui-* script) then it is probably 
 a core issue.

request-dir function has lost the 

home" button" ... yep. The old request-dir function was dynamic and 
only read dirs as needed. The new one, due to the "static" nature 
of tree, pre-reads all dirs. It's also lost the "make dir" button. 
These features maybe important to us as developers, but if users 
need to navigate the entire file system or create dirs to use an 
app then the native request-file is probably a better choice. The 
[new] request-dir is really intended for the simple "which of these 
directories or sub-directories do you want to use" case, and assumes 
the developer will use the /path refinement to start in the relevant 
directory. These changes were requested by one of my clients who 
didn't want their staff "seeing stuff they shouldn't and creating 
directories everywhere".

neat scroll-panel now means I can have enormously wide tab-panels

 ... I had that in mind when I created it! Note that the horizontal 
 and vertical sliders only appear as needed and the space they occupy 
 is given back to the child widget. Also note that the button on the 
 extreme bottom right of scroll-panel toggles between "home" and "end".

Maybe we need a "reading ..." flash for the request-dir as it reads 
it's data

Also, would it feasible to include in rebgui/core a way to size check 
boxes ?  I am trying to overlay some widgets on a PNG of a PDF so 
that users can take existing PDF forms and overlay the correct widgets 
for data entry.

I've got a couple of check boxes over the first two check boxes of 
the PNG.

I've had to do something similar and you really need pixel-level 
precision with a domain specific app (or widget). Isn't that hard 
as the number of form elements is limited. The version I was doing 
was trying to automatically place and size fields after filtering 
the form to create a B&W image (for element placement purposes). 
Another approach might be to create a widget that lets you easily 
move and size boxes, then save the face offsets and sizes and apply 
them to a RebGUI display that has the same number of widgets in the 
same order.


I'll take a look at check, led and radio-group sizing later this 
week. All these widgets *should* be able to scale without a problem 
(much like symbol does). In fact I was contemplating using webding 
symbols (for the tick and cross) in lieu of draw.

Would be cool if you think of it in terms of simply clicking inside 
the center of a printed checkbox, and the widget-checkbox simply 
scales (expands) until it hits the edges, and then some (several 
more pixels).


In theory you could do the same thing for areas where you are meant 
to fill in hand written items as well.  Basically looking at where 
the cursor was clicked, "falling" down until you hit a line, then 
expanding left and right until you hit stuff.


I designed a cool tool about 20 years ago called Snarfit that allowed 
artist to just draw where ever they wanted, and then it would grab 
everything on the page and save them out as separate objects.  It 
basically looked for blank space, and sucked up to the objects.


~ sad when we have to be compatible with printed technology.  We 
are about to undertake a huge project of making Qtask a Content Management 
system for scanned images.  I plan to make it just like Google maps, 
where the images are scalable (in chunks) and then you can draw on 
them, add tasks (as PostIts), etc.

My plan ( provisional ) was to turn the PDF into a PNG, and map the 
widgets to the PNG.  With that in mind, I know the relative displacements 
to the pdf which I would then turn into an EPS.  I can then turn 
my widget content into postscript and write that onto of the eps 
to give me perfect printouts.

RebGUI/Core - Forking: I agree with you. I have talked about this 
with Cyphre too. I think developing a simple but layerable toolkit 
is the way to go. But it's hard, because there are a lot of different 
requirements coming up when doing an appplication.


I think I will provide my RebGUI fork on my web-site and try to document 
all the differences.

pixel perfect

 ... not so much perfect, but more the fact that RebGUI deals in units 
 (default of 4 pixels per unit) which probably is a bit course if 
 you're just going to use straight displays without manually setting 
 offsets and sizes.

Normaly I'm not a big forking-fan, because it wastes ressources. 
I preferr to help the mainstream distribution by contributing my 
stuff too.

Much in the spirit of the once discussed RPC (Rebol Professional 
Community). Focusing our efforts should help us all to move forward 
much faster. And since RebGUI is really a nice piece I'm more than 
commited to help it evolve.

Hmm, I don't know that I have a "phone" number for him...I did talk 
to him on Skype, but don't see his contact now that I look...I have 
a LOT of people in my skyp

Anyway, it's only $5 a month to get an account on geekisp.com

I'm having a brain blockage .. :(

Ashley, a gift if you want it http://www.qtask.com/files.cgi/ForAshley?tab=get&uuid=9GDW7JPA1J8M822FQ5PD2RYC45QT&filename=For Ashley


Also, if you want any changes it should take seconds.  I did this 
because while looking at all the polished logos for Ruby I looked 
at the RegGUI logo and...well...

I looked at the RegGUI logo and...well

 ... yeah, I'm not a graphics guy and there is only so much you can 
 do with MS Comic font ;)


New one looks polished and I'd like to adopt something new for 2008 
as I plan to release Beta 3 (last one prior to a 1.0 release) soon. 
I'm open to suggestions on color (my preference is for red but I 
think that's taken by ruby :( ) ... also, I'm not sure about the 
X-Internet bit; REBOL and various RebGUI apps may be, but RebGUI 
itself isn't. Perhaps the word "Core" instead.


Let's get a few suggestions / comments in before you do another one.

I'm open in all ways.  Meaning, when you have some feedback, I will 
do up a bunch (differnt colours, etc.), use or don't use what you 
like.  It takes me just minutes to pop one out.  I have a system 
set up to make such art...

The X-Internet bit did get me thinking again about RebGUI server 
applications. Here's my basic thoughts.


We create a server-side RebGUI engine (branded as, say, "RebGUI Server") 
which accepts events other than mouse movements from a RebGUI client. 
The server is responsible for generating displays (as a face object) 
and "running" the app, whilst the client merely displays the faces 
it receives and sends events back.


Is there any value in this idea? (and, "so and so already does this 
so why bother" is a fair call).

Yeah, I was thinking about adding or not adding that (X-Internet), 
but it really is nice to tie them together, since otherwise (in an 
era of Web 2.0) it is not clear what this GUI is actually used for. 
 We suffer this a lot in the Rebol community, assuming people know 
what the hell is going on, and what something "is"

What you are describing is…er, well, Quilt.

Again, this is why we have to slowly move towards each other.

Is the Quilt client REBOL or a browser? (both today and planned)

Today, browser, tomorrow, it might be one source (like RebUI) that 
generates both (this is a concept I keep mentioning, but I'm not 
sure everyone, or anyone really gets this, other than Gabrielle).

Hmm.. bit complicated.  Is there a way we can construct a layout 
and point the existing layout to the new one?  this is how panels 
are done in Vid I think.

Don't worry, I've added it as an accessor func to tab-panel and will 
upload with the next build later tonight. I've also finally nailed 
the chat refresh bug as part of implementing a new action handler 
... on-resize.

are we replacing the tab, or the panel?   Just a naming question 
...

Should have a way to reset the scroller.

Altme has the same problem ..  you set the scroller to a point in 
one channel, move to another, and then switch back to the first. 
 The scroller has altered to the bottom.

Exactly.  There is also the concept of having widgets remember from 
session to session.  We are working on this for tabs in Qtask (we 
already do some of it).  

Each person wants something different, so we focus on it first doing 
what you expect it to do.


I have an idea for something that could be really cool, or really 
suck.  The good news is it is completely passive, so it won't annoy 
anyone.  The concept is this:


A magic mode you can jump into on any application or service (ASP).


In this mode, everything does NOT behave as expected, but rather 
become more abstract and detached.  So if you click on a button, 
for example the [Send] button here in AltME, a menu pops up:

---------------
Send
What is this?
Options
Rename
Translate
Shortcut key(s)
---------------

For each of these


Send - simply does what ever the button is actually meant to do (in 
this case "Send"

What is this? - Jumps to help, and has a bi-directional unique ID.

Options - Things you can set about the behavior of this button, for 
example, with "Send", you might want to know about the multi-line 
feature.
Rename - Rename this button in the current language.

Translate - Change or give this a name in another language (superset 
of Rename)

Shortcut key(s) - Se the shortcut for this, and also see all the 
others so there are no conflicts.  Allows for mode hierarchy of keys.



Would be really cool to make this a framework of its own, so that 
it is automatic.

hold down the F1 key and click on a button

Ashley, how does one iterate thru all the widgets of a scroll-panel?

this doesn't work ...

foreach widget sp/pane [ print widget/type ] 

just gives me 'face

are we replacing the tab, or the panel?

 We're replacing the panel, which in this context is refereed to as 
 a tab. Same logic applies to the 'select-tab accessor.

Are we sure widgets should 

remember" their state?" ... with regards to the RHS of the display; 
it can be argued either way. If I want to look at the usage text 
of each widget then it's nice to be able to scroll to the bottom 
and then remember this state as I click on each new widget ... but 
then again, if I want to "start afresh" with each entry it'd be nice 
if the scroller reset. As discussed, I'll add this as an option.


re: Magic modes. In one of my apps I had "programmable" buttons that 
you could right-click to bring up a menu of what the button should 
say (it's text) and what it should do (it's functionality). Only 
a small number of these buttons existed and they were colored differently. 
This one simple feature saved a lot of screen real-estate, was easy 
to explain to end-users; and most importantly, was the "killer" feature 
for those using the app.

The current tab is connected to the content area, just as it would 
be if we were shuffling several physical index cards that had tabs 
stuck to them. This emphasizes which panel is being shown, and also 
helps tell users which tab is selected when there are only 2 tabs. 
Having the same color for the selected tab and the panel area reinforces 
the connection between the two and is a reason to support the use 
of reverse highlighting. 

Reichart - there is nothing special to agree with here. It is just 
right. In fact when I requested ability to reset the position, I 
also had in mind that current behavior should stay too. On a related 
note :-) http://advice.cio.com/uisins

Luis, I agree. It just dos not look "right". I uses cyphre's tab 
panel for a few projects and it just has a slicker look to it.

OK, a couple of items of business first.


New logo - I like the new logo Reichart proposed (including the X-Internet 
text) and given I've heard nothing to the contrary I'd ask Reichart 
to prepare a few different color samples and we can vote for the 
one we like best ... and then I'll choose the one I like best anyway. 
;)


UI Look - The RebGUI look is too Windozy and is starting to show 
its age. I've decided to try for a simpler, whiter web look with 
fewer colors (I experimented with a B&W look but that's too harsh). 
My first thoughts are, with Reichart's permission, to revisit Quilt 
and mimic its look; but if someone has a link to an extensive set 
of online widgets (with a unified look) that they feel is appropriate 
then post away.


Radio-group - And now a minor implementation question (mostly for 
Graham I suspect). After looking at http://www.useit.com/alertbox/20040927.html
I note their comments in point 9:


Always offer a default selection for radio button lists. By definition, 
radio buttons always have exactly one option selected, and you therefore 
shouldn't display them without a default selection. (Checkboxes, 
in contrast, often default to having none of the options selected.)

If 
users might need to refrain from making a selection, you should provide 
a radio button for this choice, such as one labeled 

None." Offering users an explicit, neutral option to click is better 
than requiring the implicit act of not selecting from the list, especially 
because doing the latter violates the rule of always having exactly 
one option chosen."


Is it time to disallow null radio-group selections? (at present radio-group 
allows a 0 or none! selection)

So, I have a male female radio button - I flag an error if a choice 
isn't made ... but it's so easy for users to make the choice and 
accept the default which may be inappropriate.

This sounds similar to the way I implemented check-box; a tri-state 
widget (unselected, tick and cross mapping to none!, true and false) 
... which also raises the question whether it's time for check-box 
to go bi-state (unselected and selected mapping to false and true).

I don't see a need for tristate

perhaps an option to use a X or a tick though ... for true

I will prep up some logos, and a few alternative treatments.


You can actually simply take anything you like from Quilt.  The art 
is not complete, let alone finished.  Meaning, I have to go clean 
everything up in the next 30 days.  The art is being designed to 
allow several concepts:

-	Faster rendering through HTML.

-	Ability to change the colour theme with nothing more than a few 
simple CSS changes (o art changes).


For example, the Search icon is really a white magnifying glass, 
with a Knock out (alpha channel).  This way, the Search input and 
button are nothing more than a table with a cell with a green outline, 
and a box that is solid green.  Add the small image and presto, custom 
widget.  One can simply change the colour for a new look.

radio-group: Ashley, take a look at my version. It has a default 
option.

Icons: At least for icons you can take a look at www.istockphoto.com. 
I use this services to get high-quality pictures for presentations 
etc. There are a lot of artists doing icon-sets etc.

Costs are $1 or $2 for a download.

I use famfamfam.com for all the small icons.  Hard to beat them. 
 I tried sending him money, but he never responded.  The icons are 
free, but I wanted to give him a gift.

Reichart, I see a "Make A Donation" button near the bottom of http://www.famfamfam.com/lab/icons/silk/
Did you try that?

Can get-values be made to work on the contents of a scroll-panel?

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?

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.

i would like to be able to use a tab as a tab inside an area 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]]

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.

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

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.