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