Re: Object[s] and menu -- Re: help wanted, trying out a few ideas for post 0.94

[Luc Pionchon <luc handhelds org>]

long time later...

Hi,

On Sat, 2004-07-17 at 10:14, Lars Clausen wrote:
> On Fri, 2004-07-16 at 20:32, Luc Pionchon wrote:
> > On Fri, 2004-07-16 at 02:00, Alan Horkan wrote:
> >
> > [SNIP]
> >
> > > [2] I renamed Objects to just Object because that seems to be the
> > > convention when naming menus (File not Files, Image not Images, Layer not
> > > Layers).
> >
> > I think "ObjectS" was "right".
> > Menus should be, as much as possible, organized as phrases:
> > object + verb, or
> > verb + object
> >
> > Insert + this
> > Select + that
> > Layer  + do this (on the (current) layer)
> >
> > In our case, most of actions are applied to all selected objectS (group,
> > align, send to back, ...) so IMHO "ObjectS".
>
> Checking through Gimp, Abiword, Sodipodi, GnuCash, Galeon, Glade, I find
> nothing supporting that reasoning.  But then, there's few that have
> menus with similar properties:  Two of the menu items and an entire
> submenu only makes sense when multiple objects are selected.

actually all actions apply to a selection of objects (eventually a
single), except "Properties" (but not for long time, isn't it?).

> > While you are experiencing with menus, you may play with that:
> >
> > In the diagram window, "File" could be renamed to "Diagram":
>
> It kinda makes sense, but also breaks with standard menu setup.
>
> > Diagram /
> >   New
> >   Open...
> >   (...)
> >   Print...
> >   Properties...   (from the current "Diagram" menu)
> >   Close.          (no "quit"!)
>
> Why wouldn't you want to be able to quit from a Diagram window?  

Well if you want to respect some "standard" like GNOME HIG, then you
should have "Quit" also in this menu (see 4.1).

However, the explaination given is based on "historical" reasons (...)
and secondly on the fact that document and application are merged (some
kind of "meta document"). This last one does not really apply to dia.

My own idea about the historical reason is that there was no other place
to put the "Quit" item. Logically it should go on an "application" menu,
with "preferences" and "help". I do not know if there was much
"preferences" nor "help" by that time. Later "help" was brought to the
top level, so the user see it without manipulation. Then the "Quit" item
was left alone and went in the File menu, as a best compromise.

And the "preferences" item? You can find it in many places (File, Edit,
View, Tools, Options) and under many names (preferences, settings,
options, customize).

HIG suggests "Menu: Edit > Preferences" (without "...") But again dia
may be a bit special, and I think the current place is a good one!

> > About the main application window,
> >
> > the "File" menu "traditionaly" includes actions related to both the
> > opened file, and the application itself (some kind of metaphore "the
> > file is an hyper-document with tools integrated into itself"), which I
> > do not like vey much, moreover it does not apply to dia: one window is
> > the application, the others are the documents (files).
> >
> > MacOS has an "application" menu (named as the application itself)
> > including application related entries, like "preferences", etc. and...
> > "quit".
>
> That's a very different cup of fish.  Following that would make us
> weirdly different from all other GTK programs.

isn't it already? :)


[snip]
> > "Diagram tree" could be moved into  "Diagram / Diagram tree..."
>
> I wouldn't think so, the diagram tree is not just for one diagram, but
> shows all diagrams.

Oooops Right.
I never opened it with several diagrams.

>   If somebody would update it to show
> parenting/grouping and layers, it would be somewhat more useful.

indeed.

regards,
luc
-- 
`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.´¯`·.¸¸.´