World: r3wp

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!  ?

gob (graphical object) reminds me of blob (blitter object) on Amiga. 
It's not a bad name, with atom or cell, the name is open do different 
interpretations, with gob, there's no confusion, you just have to 
learn it's graphical object. Maybe it's not self-evident but still 
good name I think.

blobs are binary large objects where I come from...but I like gob 
too.  My nerd brain

immediately thinks graphical object seeing gob!  And from an end-user 
perspective,

like showing code to a construction boss (or a new developer), they 
won't be dealing

in gob! until they are ready anyway.  (I don't think..same as struct! 
or bitset!).

OS menus? why that? It imo completly breaks View way of being a free 
form compositing engine. I don't agree with the idea at all ... Later 
on, such abstraction can be created ....

menus: may i propose that we keep menus out of vid in the first release 
(unless we can get to an agreement on them) and then we try to form 
a group in the community to propose a change to View to support them 
natively? Then RT can evaluate the change and decide what to do.

Petr: the reason is that in OSX (for eg.) the menu is separated from 
the window.

think amiga - right click gives the menu on the screen bar

that kind of thing can't be just emulated with gobs inside the window.

Chris - re gob! - it is short, but really feels weird :-) IMO it 
could be called face! - we were used to it. It could just be considered 
as faces are now a datatype and that those are organised in different 
internal way ... but imo there is no place for such change, the decision 
was made ...

ah, OS-X does it too?

i'm all for platform neutral uis. however, not all developers can 
afford to do that (users may not like it at all)

that would require another level of abstraction, to simply create 
OS friendly apps.

that's the big split for me.

OS vs non OS guis