World: r3wp

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

both have their merits in different circumstances.

keep in mind that R2 already supports the system tray in windows, 
and the way it does could be easily used for the same thing on linux 
kde or gnome.

a similar way to support system level menus could be added. then 
you can decide if you want to use that or create your own with gobs 
(we should provide them as a default style/whatever, but maybe it's 
something that can be left out of the initial july release... dunno)

Umm, I'm all for whatever gives us menus the quickest.  Apps without 
them suck.  :)

hmm, difficult decision. IMO we have to start with new VID and its 
design first. Then we can hook platform specific things. E.g. I am 
curious, what you think how rebol uses native OS dialog windows for 
each "view/new" .... that e.g. becomes trouble with plug-in. Would 
anyone welcome rebol (VID) level windowing?

nothing forces the plugin to open new windows instead of opening 
them inside the browser window.

the R2 plugin was limited because the R2 code is not flexible enough.

in R3 you can completely replace the rendering system.

there are various level of os-neutral... look at how java looks java 
and behaves java everywhere (and that's not always a nice thing)

java is extremely slow at gui...an application I used which used 
their layout engine and graphics would take 2 second on my computer 
when resizing the applicaiton.  just for fun, I built the same layout 
in glayout (VID) and it would resize in .1 seconds (on the same computer).

so java really sucks at GUIs.

Gabriele - but that is the exact problem, no? There was plan to limit 
amount of opened dialog windows to e.g. 5 of them. And then - it 
looks ugly, if your app is placed in browser container and suddenly 
there is dialog window popping up, which is added to your OS app 
bar, and what is worse, it can be catched by ad-block tools. That 
is what could be imo solved by VID level windowing ...

I would suggest, to not overcomplicate things from the very beginning, 
to simply stick to what we have - cross platform UI behavior. I know 
there are OS specific things - installers, control panel icon, systray 
icon, OS-X (Amiga) system menu, etc., those should be possible as 
an option ... (e.g. view/new/os could use OS dialog box ... or view/specs 
layout [layout here] [spec-block configuring how the same layout 
should map to OS features ... .e.g. already mentioned menu)])