World: r3wp

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.

Perhaps, but the shortest route should be to system menus.

On platforms with decent system menus, yes. That should be deicded 
on a per-platform basis. This dialect would be for specifying what 
to put into the menus, not how to do it. The dialect implementation 
would be doing the work.

Don't get me wrong, I'm all for choice.  But the shortest route should 
bring you to the most intuitive features first.  Imagine downloading 
Rebol and in a one liner create a UI that utilises system menus/requesters.

I can type -- request-file -- on any fresh View installation and 
have a fully-featured file requester that a user of that system would 
be familiar with.  I want the same with menus.

That's nice, unless the system menus/requestors are no good at all 
(like on Unix clones or Windows until recently), or if the standard 
is not really standardized (like on Unix clones or Windows).

Unix clone platforms have many UI platforms. The Windows platform 
has changed so much that you might as well consider different versions 
to be different platforms. Some other platforms aren't that well 
developed at all - many don't even have windowing managers unless 
you roll your own.

But for write-once, run-anywhere, I don't really want to have to 
consider that.

No, you are the developer. The platform implementor has to consider 
this though.

That's RT's problem, not mine.  (figuratively)

Well, once R3 comes out, the community will be helping with the platform 
implementation - RT will be focusing on the core of REBOL, and that 
has no UI at all, just an API. Remember which group you are asking 
this question in.

I'm more in the platform implementor camp. I rarely need to write 
UIs, but I need to write UI toolkits on occasion.

I understand that, and that's a good thing.  But try advocating the 
Rebol language with these nuances.  "It's write-once, run-anywhere, 
except that feature, you're going to have to build that yourself 
on this Linux distro"

No, I'm saying that for end developers REBOL will be write-once run-everywhere-applicable, 
but to make that happen the platform implementors will need to do 
a lot of planning and work. If you, as an end developer, still want 
to roll your own menus or have none, then the platform implementors 
need to take that into account as well and not hard-code their menu 
implementations.

And if you want to run some Linux distro that is not running Gnome 
or KDE, or even X, then you may have to come to terms with the fact 
that Linux doesn't have standard system menus, or any UI at all. 
All that is provided by the toolkits, and if you are not running 
one of the toolkits that REBOL has been ported to already, then you 
will either need to switch platforms or become a platform implementor.

You don't get me to system menu, never. That will be absolutly ugly. 
I would agree to that only in a sense of REBOL-as-a-tool menu, kind 
of menu as REBOL console has. Can you imagine general VID UI design, 
or even RebGUI design (which is much more OS-look friendly), to have 
system native menu? That would destroy look of an app imo. And as 
I said - many new apps go for more free-form UI ....

And that doesn't even take my cell phone or bootable REBOL into account. 
I will run REBOL on my cell phone if I have to port it myself.

Petr, yes I can imagine it.  A system menu would be more appealing 
to me eg. on a RebGUI app than a RebGUI custom menu.

See, Pekr's in the roll-your-own camp. I'm in the make-the-ui-fit-the-platform 
camp, even if that means changing the paradigm altogether.

those of you who want OS native look, go and link Core to OS, easy 
as that imo. REBOL should have its own style, cross platform. IMO 
slight difference to OS is exagerrated, if substystem works in compatible 
enough way - common shortcuts, etc. And those who say otherwise, 
are exagerrating too. And if MacOS-X ppl are refusive to slightly 
different apps, then those are intolerant freaks.

I will run REBOL on my cell phone if I have to port it myself.
 - that should be my sig :)

Brian, I'm not sure how many View apps would work on a cell phone 
anyhow.  View is so literal that I've had problems running apps on 
800x600 screens because the author has a bigger screen.

Petr, it isn't about OS X users being intolerant, rather it is about 
production quality.  Most roll-your-owns are inferior to the OS default.

And that reflects on the impression an app makes.

Differences in operating systems may not be much, but differences 
in modes of interaction between different platforms can be immense. 
It would be inappropriate to run View at all on my cell phone - no 
mouse, no touch screen. But you can still do UIs, just different.

Then why are you suggesting that my Views apps be limited by that?

Chris - OK, but where do we end? Mozilla uses XUL, IIRC Firefox linked 
to native widgets. Then let's scrap View - what is it good for? Just 
use Core, link to OS, fair enough - no custome styles? Why those, 
if target OS does not provide them? What comes next? Someone shooting 
fields looks ugly too? Look at html forms - 1 think line fields are 
modern. Non shadowed. We will end with hybrid.

Regardless, I've made an argument in the past that View be less literal, 
and open to interpretation by different media.  Hence a 'CSS approach'.

1 pixel thin line ...