On Sun, 2005-06-05 at 01:25 -0500, Jesse Ross wrote: > > Second image: > > http://stefan.agentfarms.net/Download/GNUstep/Prototypes/Etoile/ > > Desktop-layout-prototype-2.png > > > > Shows "menu shortcuts". The menu commands can be dragged and dropped > > into dedicated panel. The panel can be docked too. So I can D&D > > frequently used commands. Again, menu contents is not going to be > > duscussed here ;) > > > > I really like this idea. This is similar to what I was trying to go for > with the "buffer" in this image: > > http://jesseross.com/clients/gnustep/ui/concepts/01/ui.png > > The "buffer" is the location where you see "Google", "The Linux > Desk..." and "Jesse Ross". A lot of people thought that this was a > taskbar-like area and that those were minimized windows, but that's not > the case. I imagined that area to be more like a clipboard where you > could drag and drop _anything_. For example, the one marked "Google" is > the result of dragging a URL to the "buffer". Single clicking on it > would treat it like a shortcut and open a browser to Google. The second > one and third one are both text snippets which, when clicked, would > insert the content of the text snippet into whatever text field had > focus. I imagine exactly the same thing could be done with color > swatches, people, documents, or, as you suggest, menu items. >
The functionality you have described is a funcitonality of one panel, therefore of one docked thingy (part of the dock). However, I thought of such functionality of putting things a side while working to be a functionality of the shelf. The shelf should contain adventure game like inventory tab(s). The dock shold be rather for actions, switchers, indicators, inspectors... People are already used to that functionality of docked windows: from MS Windows MDI applications. In KDE/GNOME they are just not-so-good replications. Problem with docks in the MDI apps was, that they were part of a window. That felt strange. Here the dock is part of the desktop. Also think that you have those panels open anyway, so they are taking your screen. Dock only helps you to place a window at easy-to-find place on the screen. On the other hand, there are several unsolved issues with the dock: - how should a "persistent" part (the one visible always) look like and what should it contain? - how can be context sensitivity handled? Also remember that everything except the persistent area should be detached to a window. > The only place where I could see problems with this is that we > currently have a "standard" that when someone presses down on a menu > item, but pulls the mouse away and releases outside of the menu item, > that action is not activated. In your case, doing that same sequence of > events may not activate the action, but it might make a duplicate of > the menu item outside of the root menu. We may want to detail how we > would compensate for that. Having a single dedicated "shortcut menu" > might be the fix, but it might also be handy to be able to create > tear-off menus items, not just tear off menus. > What is a menu item? In general it is a localised label and an action selector. The target is a "first responder". Therefore I see no problem of moving menu items around as far as the menu is handled globally. Modifiers for pick and drop can be used for dragging menu items from menu to shortcut area or for reordering the menu. Menu is a place for presenting context sensitive actions. Be it global context, project context or object context. Each context provides a list of actions, the desktop creates default presentation of those actions - a menu. Then it should be up to the user how he rearranges those actions Look at the OO.org or any MS Office application. There is that very clumsy way of changing menu structure. However, with this approach, we can offer more menu structures. I have seen this very nice idea in an old vector drawing application on Atari ST, unfortunately I do not remember it's name. There was a menu editing dialog box. Besides rearranging the menu structure one was able to pick between default presets: "Beginner", "Advanced" and "Expert". This was very excellent idea for an application with millions of functions. I would go mad if I were using the "Expert" menu at the beginning, also I would not be able to do all things when I were expert and hat the "Beginner" menu.(*) Anyway, this is an issue that should be refined :) So any ideas, disagreements, suggestions are welcome. Stefan Urbanek (*) This is another issue that should be introduced: user level. The environment should respond to the user level and the level should be definable in prefereces.app. The environment should not treat me as an idiot when I am expert and vice-versa. -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
