World: r3wp

next time, it should start with:  "what do you guys thinkg about 
XXXXX"  then you will get real insight.

next time, it should start with:  "what do you guys thinkg about 
XXXXX"  then you will get real insight.

max, i have already copied your 6 points :)

I got Max's summary, and will watch this group for more. If you want 
me to collect yours, please post it in this color so I can find them 
easily.

See Max, we care. :-)

max, well, i wasn't looking for input today, since we have nothing 
to comment on yet. i just stated that i wanted to have input on vid 
as soon as i could show something to give input on... and this is 
the reaction i got :)

If you're color blind (as some of you may be), the color is called 
Request in the AltME color picker.

hehe, well exactly, you got comments on what we don't have yet  ;-)

I know you guys care.  which is why I took the time to write out 
the collection of points... you know it takes time to summarise such 
a discussion  ;-)

See, this is the kind of discussion that happens when I'm busy working 
:(

I would like to be a part of the early access group, but not for 
VID. My GUI experience is founded in quite different environments 
and my input about GUIs would be more along the lines of API cleanup 
and other low-level stuff. For the major design issues, I defer to 
Carl, Gabriele, Cyphre and the other capable people here - I trust 
your judgement.


I would like to help with some of the other parts of REBOL 3 though. 
My main interests are in language design, interoperability issues 
and platform integration, particularly Windows platforms and derivatives 
since that's what I need to use most of the time.

And rebcode? ;)

language design
 :)

as long as the GOBs in R3 allow event trapping and event redirection 
ill be happy :)  Also some info on the planned / implemented? Richtext 
layer would be appreciated

I am sure Gabriele will do a fine job of VID.

And I look forward to trying it out.

Gabriele, where is the document you've written on the new design 
of VID?

Do we need a GUI designer to join us with regards to the next VID 
implementation?  Would Carl be willing to pay for the services of 
a designer?  I know a few guys who work for the local office of Adobe 
and do interface design for their products.

remember there is also a difference between skinning and actual GUI 
design, e.g. the layout of elements on screen. One can have a beautiful 
skin on an annoying interface. The same goes the other way around.

I'm just thinking about making sure we have identified the current 
use cases and have a way to build them.  I personally have no idea 
what is involved in building the GUI engine so if I am speaking out 
of line, I apologize.

I would focus more on behavior, as Pekr always requests. I have no 
problems switching between different looks, but if some key keys 
behave different (copypaste, close window, refresh) i am heavily 
interupted.

would prefer skinnable hotkeys over skinnable look :)

About the new VID widgets look&feel, Carl stated at the DevCon that 
he would like to have something between Windows and OSX widgets look. 
So, I think that we could submit our own graphic design propositions 
to RT. A big image with a static example of each class of widgets 
would be enough I guess, "live demo" would be even greater. For the 
VID engine design, I'm trusting Gabriele's skills and his ability 
to gather the best ideas and feedbacks from the community. Anyway, 
if you don't like the upcoming new VID, nothing is stopping you to 
make your own one ;-).

I agree with most of Pekr's points about the lacks of current VID. 
I'd like to see these points summarized somewhere, just to keep them 
in mind.

Anton: http://www.colellachiara.com/soft/Misc/r3-gui.html

note that Carl does not necessarily like / want all of that.

Henrik, that's one of the reason i'd want to have automatic layout 
- most programmers are so bad at layout that even a program can do 
better if it follows good rules.

We should get someone to formulate some formal design rules into 
the engine of a layout dialect.

reflective user interfaces, that is, ones that are able to edit themselves
 ... are such changes able to be saved, and if so where?

yes, where would probably depend on the application. note that when 
i say long term in that doc i mean 1-2 years, so there's plenty of 
time to discuss that stuff.

Doc, I agree, the VID engine is easier to change.

Gabriele, how high level would you carry auto-layout? I have myself 
thought about creating standard layouts, certain combinations of 
faces that are common, not just for yes/no dialogs, but, say, a two-pane 
or three-pane layout. Something that strongly encourages you to put 
a menu at the top, generic content in the middle and buttons at the 
bottom, where for example OK/Cancel/Retry buttons also are laid out 
in a specific sequence. Never got around to it though.

Silly example:

view layout [
  three-panel [
    menu [File Project Edit Show History]
  ] [
    ordinary VID code here
  ] [
    buttons [OK Cancel]
  ]
]

Good example.

Hmm.. however, how is that different from:
view layout [
	vertical-panel [
		menu [File Project ...]
	][
		ordinary VID code ...
	][
		buttons [OK Cancel]
	]
]

for now it seems that VID is just a bucket to randomly throw widgets 
in at your own whim. this should of course not go away, but higher 
level structures would be nice to have. there could be Dialog, Two-pane, 
Three-pane, Preferences (which provides a list in the left side and 
switchable pane in the right side).

anton, it's the same, just different wording. perhaps it would be 
better to say that several grouped panes would be a specific level, 
but a pane with menu/content/bottom button-panel could be an even 
higher level.

perhaps move to VID+?

Oops I missed a level of nesting. Oh well, we agree on the basic 
idea.

Aren't those just another kind of styles?

in a sense, yes, but they are more complex than those currently defined 
in VID

It's a shame that menus have to be reinvented -- every system View 
runs on has a menu structure built in, and I'd rather use that than 
rolling our own.  Especially on OS X.  Our interface could be eg. 
a dialect attached to a window containing features common in menu 
systems: view/menu layout [...]["File" ["New" ["Document" "Template"] 
"Open" ctrl #"O" (does this) "Open Recent" get-recent-docs]]

Henrik: another way to put it is to have several layout patterns 
available by default.

Which and how many patterns?  Can we create patterns without low-level 
code, and are the layouts managed after the point of composition?

Agreed!

We cannot move forward until we can stop reinventing.

I'd buy into hooking into native OS menus.  Ashley's menu widget 
is working out ok

in my small test passes so far.  But it was a fairly long wait and 
I did waste a good

week trying to track down a menu system before sticking with tabs 
for the FirM app.

And it presumes RebGUI will be an easy include for R3, and using 
RebGUI...

Java does a good job of making platform-specific menus with a cross-platform 
API that requires no changes. It may be good to look at.

The trouble is that it'd require an abstraction of the key features 
of all menu systems -- another excuse for delaying a new View.  Perhaps 
our representation is a dialect, though it might also be an involved 
object hierarchy, as faces/gobs are.  However, any effort to get 
this right will benefit every View application immeasurably thereafter.

gob! is such an unfortunate datatype name.  Is there no other word 
-- cell! atom! -- however innapropriate (I know Carl gives words 
careful consideration) that would make sense and be taken seriously 
in a verbal discussion?

graph!  ?