World: r3wp

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.

king of = kind of

A separator in a menu is made with
separator []

I think, this basic design can cope with all my needs for a menu 
system. The visual layout of it can differ. So far, I've made two 
versions, AmigaMenu.r which show it as original menus seen on the 
Amiga, and CanvasMenu.r, which is maybe a little nicer look.

Henrik - were you at older IOS? Cyphre did very nic menu, OS-like. 
That was so good, that I would not search for any other functionality 
- translucent, automatic alignment when close to window border, context 
menu, floating menu, etc.

my preference is to have general enough VID ... and I don't agree 
to e.g. separate multi-pane window, menu, etc., into another layer 
... it is not imo necessary ...

pekr, no I didn't see that one

uh, will look for some screenshot, but not sure I made one :-(

Not sure I have IOS developer's connection still active. I will look 
at my home's pc ...

found it ...

pekr, I find it highly necessary, because of the aforementioned lack 
of high level structure. It's not a luxury, but meant as a guideline 
to how to make your program look and act. I've changed the structure 
of my programs over the years too many times, because there was no 
real way to standardize this. Every REBOL programmer must come up 
with his own standard for this, which IMHO is a lot of unnecessary 
work.

You can see the whole menu datafile for Canvas RPaint by doing:

>> print decompress read/binary http://home.tiscali.dk/john.niclasen/canvas/modules/menu.dat

http://www.xidys.com/rebol-view/cyphre-menu1.jpg
http://www.xidys.com/rebol-view/cyphre-menu2.jpg

It is part of Cyphre's stylepack, which is freely available from 
rebol.cz somewhere :-)

well freely...the license is very confusing :)

Henrik - but I can imagine more than 10 such styles, how you build/divide 
canvas for your app :-( And last years, we have apps appearing, which 
simply don't adhere to some system rules anymore ...

Henrik - who not let it just be a style? Just like tab-view is container 
for other stuff? You could start the hierarchy with - view layout 
[app-window split-window 3 [list-box .......]]

This is also nice menu: 

do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=menu-system-demo.r

hey, that is cool ;-)

Pekr, it's highly likely that people will settle for a guide, if 
one is provided with REBOL and it's made in a reasonable way. There 
is a reason why most OS'es have interface guidelines, namely to encourage 
consistency. The good thing with a guide is that you are not forced 
to use it, and it's not meant to restrict you, but help you develop 
your software faster, since all those design decisions are already 
made for you. If you want to build a custom dialog, it would be very 
nice if you have the basic arrangement already available, so you 
can settle for creating content for the dialog.

pekr, it _is_ a style. maybe we are just naming them differently 
and we agree after all. :-)

Henrik - I just don't believe it will not push its usage style on 
me ...

but the truth is, that maybe we shold decide, if it is better to 
have them, or not ...

pekr, it probably depends on what type of UIs you develop. Is it 
large programs or just smaller scripts with a GUI slapped on? I see 
guides only as beneficial, when developing larger programs.

I think that kind of general split window with settable (resize yes 
or no) panes, auto-scrollers, could be suitable?

I do understand you properly, Henrik. My dilemma is different. Last 
4 or so years, I see BIG diversification in how companies aproach 
UI, even MS themselves!

Should I do a screenshot of MS Outlook? And then some other app, 
using their dev. tool? Those look different in that respect! So, 
what I just said is - the trend is towards moving away from traditional 
looks, more so with inclination to web based like apps ...

but I think we just want the same ;-) My intention is just to have 
it available as nested styles, no new concept, if we can make it 
that way. But some aspects of certain look & behavior could be rebol 
specific and cross platform imo.

Yes. And I don't agree with those design philosophies. :-) It may 
have something to do with those programs being so amazingly huge 
and have 2-digit sized development teams, so the program itself will 
reflect what the team is doing. MS is known to reinvent the wheel 
for each product. This is a bad trend.

Look at some of Office 2007 screenshots. I am still not used to it. 
There is NO menu - it is replaced by tabs plus big icons/configuration 
sections ...

I've seen it, and I hate it.

What I will accept - containers, where I can put whatever inside. 
I will not accept anything specific, which will be more than general 
pane box, because it will push certain usage scenario on me. I want 
to decide, if I place Cyphre's menu there, or yours toolbar ...

And when we talk about split-window (app-window), we can even talk 
about native VID windowing :-)

Do you remember the so called MDI or SDI app guidelines? I am not 
sure I agree with any of them :-)

that should be discussed in VID group probably :-)

If I try to make a MacOSX program in Cocoa, I'm actually pretty restricted 
in what I can do in terms of UI guidelines. I have to follow their 
menu system and structure. I have to follow their windowing system 
behaviour. I have to have an icon in the dock and I can do certain 
specific things with the icon. If I choose to, I can even let MacOSX 
handle loading and saving of data and preferences for me and handle 
the aspect of multiple documents for me.

I could probably code my own stuff, but since Apple have spent years 
designing these UI elements and guidelines, I see no reason to do 
that, since it provides a high amount of consistency. It's actually 
pretty hard to make something that looks shoddy or amateurish, unless 
you start drawing up your own graphics elements and ignore existing 
guidelines, which would be a huge waste of time. MacOSX is exactly 
being touted as being a fast environment to develop in, because many 
of the tough design decisions have already been made.

moving to VID...