World: r3wp

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.

For good, free icons I go here: http://tango.freedesktop.org/Tango_Desktop_Project

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.

www.famfamfam.com

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

That is recent...(and good to hear from you)

Good to see you're back here too. I had about the most busiest months 
in my life with studies and work. It's not healthy to be so busy. 
"More REBOL programming" should be my new year wish (or promise) 
no. 1. :)

I'll second Reichart's words.  Nice to see some of the newer big 
names in Rebol appear here again.  Maybe we'll see some of the original 
big names come back when R3 is made public.

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

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.