World: r3wp

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

ahh... seems to be sp/panel/pane

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.

Ashley...again...exactly.


I hate always agreeing with you...for one thing it is out of character 
for me, and second it sends the wrong message to others : )

Ashley, I would like to know how can I change the selected-unselect 
colors of tabs.
I wish tabs as:
http://en.wikipedia.org/wiki/Image:Vertical_tabs_sample.png 
or at least:
http://www.useit.com/alertbox/tabs.html

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, you know, we all know your real soul already. So don't 
be afraid ;-)

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.

Try to set rounding to 0 in ui-config part. It looks much better 
...

http://www.xidys.com/rebol-screenshots/rebgui-config.jpg

Thanks Pekr, but it still looks un-refined to me.

I was agreeding with more than just the "state" issue, but all the 
philosphy about branching RebUI as well.

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)

I don't like defaults because you don't know if the user made that 
selection, or forgot to make one.

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.

users to forget to make the choice and accept the default

So, forinstance, take the windows xp installation, there is no default 
for accepting or declining the MS license.

You have to make an active choice

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

although I do use it :)

But I'm happy for it to go.

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.

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.