[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Group premium quotes: UI
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] Group premium quotes: UI |
Date: |
Thu, 27 Aug 2015 23:35:04 +0200 |
On Tue, 18 Aug 2015 19:29:08 +0000 Greg Chicares <address@hidden> wrote:
GC> On 2015-07-16 21:36, Vadim Zeitlin wrote:
GC> > On Mon, 22 Jun 2015 01:34:50 +0000 Greg Chicares <address@hidden> wrote:
GC> >
GC> > GC> > GC> - GUI: The existing "Print roster to spreadsheet" command could
become
GC> > GC> > GC> "Print roster..." with a submenu, with its toolbar button
perhaps
GC> > GC> > GC> becoming a combobox (which I suppose wx can put in a toolbar).
GC> > GC> >
GC> > GC> > (it can put a button with a drop down menu, which is the more
standard UI
GC> > GC> > for this kind of things)
GC> > GC>
GC> > GC> Good. Then it'll be like this:
GC> > GC>
http://virt-tools.org/learning/start-vm-with-virt-manager/force-off.png
GC> >
GC> > Just a note: this is implemented now, but we need at least the new icon
GC> > for the new "Print group premium quotes" menu item for consistency with
the
GC> > "Print roster to spreadsheet" item in the same submenu
GC>
GC> The lack of consistency there doesn't bother me so much, now that I look at
it;
GC> and creating new icons isn't my greatest talent or my most burning desire,
so
GC> I'm thinking of just leaving this alone.
I still think that the inconsistency is jarring but OTOH I'm not going to
volunteer to create the icon neither. The best I might be able to do would
be to combine the existing "print group roster" icon with the "PDF" emblem
that is already used in another icon. I think this actually might not look
too bad (well, relatively speaking, anyhow...), but I'm afraid it could be
misleading because these entries don't output exactly the same information
as the similar icons might lead the users to believe.
GC> > - The drop down toolbar button doesn't get disabled even if both of the
GC> > items in its submenu are disabled, which is a bit strange (although non
GC> > fatal as pressing it still doesn't do anything). This one could actually
GC> > be a bug in wxMSW and I'll look at whether it really is one if we decide
GC> > to keep this UI.
GC>
GC> The lack of disablement is kind of ugly, so would you please look into
GC> whether it's a fixable problem?
We actually can disable it easily enough if we just do it explicitly for
the tool itself, please see the attached patch. I am not sure if wxWidgets
should be doing it automatically or not, to be honest. On one hand, it
would make sense to disable the main button if all its subcommands are
inapplicable, but perhaps in some strange use cases it's possible for the
main command still work when subcommands are not available? I have trouble
thinking of a realistic situation in which this would be useful, but this
could be just a proof of my lack of imagination and not of the fact that
this can't happen. So for now I suggest that we just use this patch.
Regards,
VZ
0001-Disable-the-Print-roster-toolbar-button-if-it-s-not-.patch
Description: Text document