World: r3wp

Henrik, the link above state exaclty what you say: The NIB (stands 
for NeXTStep Interface Builder) file is a loosely coupled, standalone, 
user interface definition. It wouldn't make sense to double-click 
a button and immediately be taken to a code-behind. Instead, you 
have to create a controller class, and then ctrl-drag from the button 
to the controller and then pick the outlet you're going to use (something 
like click: or calculate:). To me, as a huge fan of the MVC pattern, 
this makes perfect sense. And it seems so elegant in its simplicity, 
and so incredibly cool in the fact that it is truly enforcing good 
design simply by the way the IDE works.

yes, the guidelines are in fact inherent to Cocoa itself. I didn't 
think of it that way :-)

well, listening to raising requests to be tight to os-native widgets 
(not only windows behavior), I start to think that it would be better 
to scrap View altogether, and to go with some other UI toolkits, 
as gtk, qt, or simply to wrap OS ones ;-)

why? it's simply adding a layer above VID to guide how to handle 
certain dialogs and multiple groups of widgets. it doesn't have to 
be more than a few kb's of code in total.

think of it as a layer above VID as VID is a layer above View. imagine 
how it would be to code layouts without having VID in REBOL...

layer about VID ... maybe the thing is, I can't imagine it. Kind 
of 'View function dialect? e.g. view/custom, or view/specific custom 
block configuration?

no, just advanced styles with many single faces grouped into one. 
just like you said yourself.

ok then ...

so, now what? We wait for Gabriele to come out with some prototype?

yes, I think we should see how that works out. if it will be as extensible 
as it's claimed to be, then this can easily be done.

I wonder about one thing - will layout be changed to grid model?

.... and ... not sure it is possible or if it would be vital, but 
Chris requested future VID being CSS like, simply put that widgets 
would be separate from styling. But not sure it is possible. The 
trouble is, that once layout is decomposed into view objects, there 
is no way back. There is nothing like DOM ....

so - would anyone else find the ability to get back to layout usable? 
I don't remember, what exactly Chris had in mind with that ...

well, I wouldn't mind seeing a way to store UI skins centrally, so 
there would be a way for the user to customize it, like you can with 
MUI on a per application basis.

Between Cyphre, Geomol, and Christian, we have three solid menuing 
systems to analyze as prototypes. If someone wants to write an interface 
to native OS menus, that can probably be written as an extension 
to R3. The only critical thing would seem to be the ability to attach 
an OS menu to a REBOL window.

Four
do http://anton.wildit.net.au/rebol/gui/demo-menu.r

Christian's menu-system-demo is showing some interesting memory-eating 
behaviour on my system. I'll try to isolate that tomorrow.

Petr, just to be clear, system menus are OS neutral.  Every platform 
that View runs on has a menu system that is essentially the same. 
 The mode of access may be different platform to platform, but how 
different in function is a Windows menu to an OS X menu to an Amiga 
menu?  All I would like is a standard way to utilise them.

Sorry, forgot yours Anton; so much chat here lately.

Let's specify menus with a dialect that does not assume where they 
will be put, and then implement that dialect in a platform-specific 
way, with a cross-platform REBOL native fallback.

Agreed Brian, though I would probably make the choice explicit, with 
REBOL native style being the default.

This seems to me a similar issue to using native file requesters. 
 Why reinvent a complex pattern in a way that is substandard and 
unfamiliar to users?

(and 'substandard' is not meant as offence to those that have developed 
such styles in View, but when you replicate a WinXP menu, then deploy 
on OS X, it looks substandard)

I would only have the REBOL native style be the default on platforms 
that don't have a decent native style. That means platform-by-default 
on OS X but perhaps REBOL-by-default on Windows - there's a reason 
that MS uses custom controls on Windows. Let the platform implementor 
decide the default.

It's not just View apps that suffer in this way -- Inkscape is a 
formiddable application that looks at home on Linux, looks patchy 
on Windows and looks like an emulator window on OS X.

Because trying to do it in a cross-platform way can be very complicated 
and force you into a lowest common denominator scenario. The question 
for me comes back to whether you're trying to emulate a native OS 
look in general or not. If you are, then the menus should match; 
if not, the menus won't match your app. And given that every web 
site seems to have a different nav system and menu look these days--and 
people seem OK with that, even if it's not good UI, and doesn't leverage 
existing knowledge--it's not a problem.

If you create a slick OSX look for your app, do you want a W2K menu 
attached to it?

How low can the lowest common denominator for menu systems be?

Ok, I don't think we have the same model in mind.

Text description and a hot-key?

Submenus?  On-off?

Breaks?  Which applications exploit more than these and how much 
of a benefit does that bring?

I actually like the Office 2007 model: No menus. At least on platforms 
that don't have menus on the top of the screen - I haven't thought 
about how to integrate this model into the OS X UI.

But then I prefer a mouse to a keyboard (hand injury).

Office 2007 does have some rudimentary menus.  Just not a menu strip.

Still, if you are going to roll your own, why not go all out?

Yes, Brian, I agree; or at least plan to go all out, even if you 
keep it simple to start with.

I'm in the camp against rolling your own :)

I think this chat also applies to the general interface to apps, 
and how you expose commands. e.g. how you would programmatically 
control an app; think ARexx.

It wouldn't work on my cell phone though - no mouse, no touchscreen, 
just a keyboard, action keys and a navigational pad.

By rolling your own vs platform, I mean on the GUI toolkit level. 
We shouldn't require individual developers to implement their own 
menus, but we should allow it if they want to. That's why you would 
seperate the specification of the menus from their implementation.

At one point I started working on a generic app framework, and may 
revive it at some point.. On the menuing front, the idea is that 
an app has various "actions" you can trigger, and which may be represented 
on a menu. e.g. 


browse-hq [id: 'browse-hq text: "REBOL" action: [browse http://www.rebol.com]]

run-core  [id: 'run-core  text: "Core"  action: [call-str %/c/rebol/core/rebol]]

run-view  [id: 'run-view  text: "View"  action: [call-str %/c/rebol/view/rebol-link]]
run-shell [id: 'run-shell text: "Shell" action: [call "cmd.exe"]]

quit      [id: 'quit      text: "Quit"  action: [quit]  hot-key: 
#"^q"]


Then creating a menu is basically just listing the actions that should 
be on it.

run-menu-v [
    browse-hq
    -
    run-core
    run-view
    -
    run-shell
    -
    quit
]


Commands (actions) could be loaded in contexts, and you can reference 
them specifically if you want.

run-menu-h [
    [horz]

    browse-hq | run-core run-view | test/run-shell | test-2/nested-obj/quit
]

A menu dialect is more the REBOL way, anyways.

Again, what I propose is a way to manage system menus as a core part 
of View.  Effectively it'd be view/menu layout [...] [... menu spec 
...].  On Windows, this would attach a OS menu bar to your window 
(as optional as having a window title bar).  On OS X, it would enable 
functionality on the OS menu bar specific to the viewed window.  
This way, you have a familiar, cross-platform though native-integrated 
menu system.

If you are going for lowest common denominator for your dialect, 
look to OS X first. All of the other platforms can do more than that.

Yep.  And if something more complex is required, roll-your-own.

We're talking about 2 different things here. The dialect would be 
the same cross-platform - the implementations would be different. 
You could roll your own implementation of the standard dialect. You 
could even ignore the parts of the dialect that have no equivalent 
on your platform, so lowest common denominator can be set pretty 
high, particularly if some features are declared to be optional. 
You could even embrace-and-extend the standard dialect with your 
own extras in your implementation.


Or you could go the Office 2007 route and change the paradigm - new 
dialect.

Of course -- you can reinterpret any dialect in Rebol.  But priority 
would be on a dialect that works with native menus.

I'm more thinking of a way to register a standard dialect (I believe 
R3 has such a thing - implied by Carl's slides). Then let the platform 
implementor register the default dialect implementation, and let 
the developer register their own alternative for their app if they 
like.

Or the developer could ignore the menus altogether and go with something 
completely different, not menus at all.