World: r3wp

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).

= RebGUI

Graham, re your tab-panel question:

display "" [
	t: tab-panel data [
		"P1" [field]
		"P2" [field]
	]
	button [
		d: 1
		var: t/pane
		var/:d: ctx-rebgui/layout/only [field red]
		var/:d/offset: as-pair 0 ctx-rebgui/sizes/line
		var/:d/edge: ctx-rebgui/widgets/default-edge
		var/:d/color: ctx-rebgui/colors/widget
		either t/data = d [show t] [var/:d/show?: false]
	]
]

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.

Uploaded build#111.
	- Split requestors off into %rebgui-requestors.r 

 - Requestors and functions now appear in their respective parent 
 objects 
	- Added new on-resize handler 
	- tab-panel.r and chat.r fixes 
	- RebDOC.r enhancements

Graham, new tab-panel accessor is used as follows:

display "" [
	t: tab-panel data [
		"P1" [field]
		"P2" [field]
	]
	button [
		t/replace-tab 1 [field red]
	]
	button [
		t/replace-tab/title 1 [field blue] "Blue"
	]
]

great stuff.

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

man, RebDOC looks so cool! It reminds me of word browser but has 
already wider capabilities ...

one things regarding various widgets. Are we sure widgets should 
"remember" their state? I mean especially tabs/areas. When I click 
item in left part of rebdoc, it displays its content/description 
in the right part (area), but scroller remembers previous state. 
Is there possibility to reset the scroller?

could support scroller too ...

Should be both, no?  Has the ability to remember, but defaults to 
what most people expect, with the ability to override.

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.

less choice is better

well, that is supposed to be mantra of guis

Maybe toggle into some type of expert mode and noobie mode

There is no "expert" mode though... I'm thinking of this as already 
some "mode" that almost all people will never see or know about.
So I guess you could think of it that way.


It is simply this "super cool" feature that magically is available.

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

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