World: r3wp
[!REBOL3-OLD1]
older newer | first last |
Henrik 28-May-2007 [2782x2] | 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... | |
Will 28-May-2007 [2784] | 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. |
Henrik 28-May-2007 [2785] | yes, the guidelines are in fact inherent to Cocoa itself. I didn't think of it that way :-) |
Pekr 28-May-2007 [2786] | 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 ;-) |
Henrik 28-May-2007 [2787x2] | 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... | |
Pekr 28-May-2007 [2789] | 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? |
Henrik 28-May-2007 [2790] | no, just advanced styles with many single faces grouped into one. just like you said yourself. |
Pekr 28-May-2007 [2791x2] | ok then ... |
so, now what? We wait for Gabriele to come out with some prototype? | |
Henrik 28-May-2007 [2793] | 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. |
Pekr 28-May-2007 [2794x3] | 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 ... | |
Henrik 28-May-2007 [2797] | 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. |
Gregg 28-May-2007 [2798] | 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. |
Anton 28-May-2007 [2799x2] | 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. | |
Chris 28-May-2007 [2801] | 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. |
Gregg 28-May-2007 [2802] | Sorry, forgot yours Anton; so much chat here lately. |
BrianH 28-May-2007 [2803] | 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. |
Gregg 28-May-2007 [2804] | Agreed Brian, though I would probably make the choice explicit, with REBOL native style being the default. |
Chris 28-May-2007 [2805x2] | 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) | |
BrianH 28-May-2007 [2807] | 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. |
Chris 28-May-2007 [2808] | 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. |
Gregg 28-May-2007 [2809x2] | 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? | |
Chris 28-May-2007 [2811x2] | How low can the lowest common denominator for menu systems be? |
Ok, I don't think we have the same model in mind. | |
Gregg 28-May-2007 [2813] | Text description and a hot-key? |
Chris 28-May-2007 [2814x2] | Submenus? On-off? |
Breaks? Which applications exploit more than these and how much of a benefit does that bring? | |
BrianH 28-May-2007 [2816x2] | 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). | |
Chris 28-May-2007 [2818] | Office 2007 does have some rudimentary menus. Just not a menu strip. |
BrianH 28-May-2007 [2819] | Still, if you are going to roll your own, why not go all out? |
Gregg 28-May-2007 [2820] | Yes, Brian, I agree; or at least plan to go all out, even if you keep it simple to start with. |
Chris 28-May-2007 [2821] | I'm in the camp against rolling your own :) |
Gregg 28-May-2007 [2822] | 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. |
BrianH 28-May-2007 [2823x2] | 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. | |
Gregg 28-May-2007 [2825] | 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 ] |
BrianH 28-May-2007 [2826] | A menu dialect is more the REBOL way, anyways. |
Chris 28-May-2007 [2827] | 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. |
BrianH 28-May-2007 [2828] | 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. |
Chris 28-May-2007 [2829] | Yep. And if something more complex is required, roll-your-own. |
BrianH 28-May-2007 [2830] | 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. |
Chris 28-May-2007 [2831] | Of course -- you can reinterpret any dialect in Rebol. But priority would be on a dialect that works with native menus. |
older newer | first last |