lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Ellipses in menus


From: Vadim Zeitlin
Subject: Re: [lmi] Ellipses in menus
Date: Sun, 18 Oct 2015 21:34:16 +0200

On Sun, 18 Oct 2015 16:56:36 +0000 Greg Chicares <address@hidden> wrote:

GC>   20151018T1612Z Refactor
GC> Removed irregularities: two File menus used as <object_ref> without
GC> explanation, and a third written inline with explanation.
GC> 
GC> Is there a more tasteful way to do this? Ideally we'd code "File | Open"
GC> once and only once.

 I think the best way to do this would be to have a single file menu, with
all the items, and then remove those that we don't need after loading it.
As usual, patches doing this could be made available if there is any
interest in them.

GC> I speculate that I could write this once:
GC> 
GC>     <object class="wxMenuItem" name="wxID_OPEN">
GC>         <label>_Open...\tCtrl-O</label>
GC>         <bitmap platform="win" stock_id="wxART_FILE_OPEN"/>
GC>         <help>Open an existing document</help>
GC>     </object>
GC> 
GC> and use it by <object_ref> in three places, assuming that all <object>s
GC> are equal.

 Yes, this should work, but I'm not really sure if it would be better.

GC> I don't see a simple way to write a group of menuitems and
GC> include the group--i.e., there seems to be no <multiple_object_ref>.

 No, there isn't anything currently and I think it might be not that simple
to implement as <object_ref> is still a (single) node and so dealing with
it is almost as simple as dealing with the <object> nodes themselves, you
just need to dereference it. Allowing a single node to stand for multiple
nodes risks being trickier.

GC> >  OTOH "Preferences..." or "Options..." menu item has always used and still
GC> > continues to everywhere and lack of it in lmi was a bit jarring, so adding
GC> > it there is even more important than removing it from "About".
GC> 
GC> Is it jarring that three "Census | Edit" commands and "Illustration | Edit 
cell"
GC> still lack ellipses? I think so.

 Yes, I agree. It's actually slightly less noticeable because no other item
in this menu has ellipses neither, so they stand out less. But they still
should have them.

GC> The same answer should apply to all other document types, wherever a
GC> magnifying-glass-with-dancing-m[ae]n icon appears.

 Yes, definitely.

GC> Should "Census | Print" have an ellipsis? I suspect not

 As currently implemented, it indeed shouldn't, and its absence should be
seen as a warning. Whether it should be implemented like this is another
question but I believe we discussed it already and it was decided that it
should because this is what the real users expect, even if it does result
in collateral damage in the form of accidental printing for the testers
such as me sometimes (as you can guess, I had forgotten about this earlier
discussion until I just printed out a nice illustration again).

GC> If a census is the currently active child document, should we enable the
GC> "File | Page setup..." menu command? I think this should be answered the 
same
GC> way as the preceding question, for the same reason.

 Sorry, I don't really understand this one. In theory "Page setup..."
should be enabled if it is taken into account by printing. I am not sure if
it is, but I'd expect it to be, and then the command to be enabled.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]