lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Ellipses in menus


From: Greg Chicares
Subject: Re: [lmi] Ellipses in menus
Date: Mon, 19 Oct 2015 03:36:00 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2015-10-18 19:34, Vadim Zeitlin wrote:
> 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.

Yes, please: I'm definitely interested. Or, more precisely, I will become
interested after Halloween. Skeleton::AdjustMenus() already does something
similar.

[...snip some distinctly poorer suggestions that I had made...]

> 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.

Committed 20151019T0224Z, revision 6364.

> 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).

Make sure you never do "Census | Print case" with a large census, because,
as the user manual dryly understates:

http://lmi.nongnu.org/menu_commands.html#menu_census_print
| This may use a lot of paper.

Me, I just don't define a printer in my msw VM.

It would be really nice to renounce xsl-fo in favor of wxPdfDoc. Then we
could lose java, probably speed up printing dramatically, and incidentally
add a "Print" dialog.

> 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.

Exactly.

> I am not sure if
> it is, but I'd expect it to be, and then the command to be enabled.

I think it works exactly as you expect.




reply via email to

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