World: r3wp

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

during first run, I would welcome to have trouble free and extensible 
VID replacement, with most (all) of limitations/defficiencies of 
current model being fixed. For the july release, that is. It would 
not even have to fix them all with first release, but engine should 
be designed so it will allow us to finish it later in a good way, 
no hacks ...

if R3 is to take advantage of OSX GUI, it would have to be made compatible 
with .nib files, the file in which menus are stored. The GUI is a 
separate file in the application bundle.

..is there anything better/easier/welll-thought  than Interface Builder 
3.0 (Leopard os x) ? that is the only thing that make great looking 
apps for a programmer, qurtz composer, core image and now core video 
8-)

http://chanson.livejournal.com/tag/interface+builderand http://rubycocoa.sourceforge.net/Documentation

We cannot move forward until we can stop reinventing.


I kinda second that. My problem is, that I want a 'pure', simple 
and well thought out foundation to work from. I often find myself 
reinventing, because what's already there isn't good enough. A positive 
thing is, that REBOL is such a nice language to reinvent in, because 
there's a short way from idea to solution.


There was talk about menus. For Canvas RPaint, I built a menu-system 
from scratch. It's 5-6 k of REBOL source and means, that I don't 
have to reinvent menus any longer. Unless some customer wants menus, 
that looks and feels 100% as hosting OS. That's the downside.


When is something good enough, so we don't have to reinvent? Maybe 
progress comes from reinventing to some degree?

The question is whether we want to integrate into the OS or not? 
Almost each OS does menus, systray notifications and window handling 
differently.

In compressed source, the Canvas RPaint menu-system is 1468 bytes.

geomol, is it made so it can be generalized for other programs?

If the idea of REBOL in the long run is an OS (or virtual OS or whatever 
it's called), it might be a good idea to separate as most as possible 
from host OS.

Henrik, yes it's easy to implement the menu-system in other programs. 
You give it a datafile with a format like:
[
	"Picture" [
		"Load..." [off "^^L" []]
		"Save..." [on "^^S" [RPproc/save-picture]]
		separator []
		"Flip" [on menu [
			"Horizontal" [on action [proc/flip-bitmap-horiz]]
			"Vertical" [on action [proc/flip-bitmap-vert]]
		]]
...
and you have a menu.

nice and simple. are you going to publish it?

Yes, that's the idea, when I can release Canvas for all versions 
of View. I plan to release info about developing such a monster in 
some way, maybe as a book, not sure.

Maybe it will be a good idea to do it as a book with a CD with all 
the building blocks for developers to use.

The format of the datafile is string - block, string - block, ..., 
as you can see. For menu-lines, the block holds
on/off - whether the menuitem can be selected or not (ghosting)

menu/action/string - king of menu-item. If a string, it's the keyboard 
shortcut.

block - for actions, it holds the name of the function to call. For 
menus, it holds the sub-menu.