[GNC-dev] GncCombott Widget

Robert Fewell 14ubobit at gmail.com
Thu Feb 18 13:11:42 EST 2021


Thanks for the feedback, I have created PR 917 to replace the GncCombott
with a GtkComboBox.

Regards,
Bob

On Tue, 16 Feb 2021 at 17:13, Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> Thanks. I'm fine with the dropping value listings in tooltips as well. The
> only reason I considered them was for the cases where per-value extra info
> would be needed. In my quick evaluation of a number of them that doesn't
> really seem necessary.
>
> Regards,
>
> Geert
>
> Op dinsdag 16 februari 2021 17:37:21 CET schreef John Ralls:
> > I generally agree, but I think that there's no great benefit to listing
> the
> > available options in most cases. The user can easily enough click the
> > revealer to see them. I also don't think that we want dissertation-length
> > tooltips. If that much verbiage is required then it should be in the help
> > document,but that presents other issues that I'll address in a new
> thread.
> >
> > We should relabel sort selectors from the overly geeky "primary key" and
> > "secondary key" to something like "Sort first by:" and "Then sort by:".
> > That's sufficiently descriptive that a tool tip isn't necessary.
> >
> > Regards,
> > John Ralls
> >
> > > On Feb 16, 2021, at 7:11 AM, Geert Janssens <
> geert.gnucash at kobaltwit.be>
> > > wrote:
> > >
> > > Hi Bob,
> > >
> > > I did some experiments and I agree with you it would be hard to
> implement
> > > this in Gtk3 because the tooltips should be added to the internal
> > > GtkMenu. The GtkCombobox interface does not provide access to that
> > > widget.
> > >
> > > So there is a trade-off to make here between maintenance burden and
> added
> > > value.
> > >
> > > Personally I'm clearly in favor of restrict our specialized widgets to
> > > only
> > > where absolutely necessary.
> > >
> > > In this case my suggestion would be to rethink our tooltip strategy in
> the
> > > context of the GtkComboBoxes. Clearly Gtk didn't intend for each entry
> in
> > > the menu to have a separate tooltip. I don't know their motivation
> (lack
> > > of time, UX considerations,...)
> > >
> > > What we can do with the GtkComboBox as is could be to use the single
> > > tooltip it currently supports and be smarter on what we put in there.
> > >
> > > For the remainder of this text, I'll focus on the comboboxes in report
> > > options, but I think the reasoning remains the same for other
> locations.
> > >
> > > Currently the comboboxes in report options will always show the tooltip
> > > that relates to the selected combo menu item. For example for the
> > > Stylesheet option, with "Default" being selected, the tooltip for the
> > > combobox will be "Default stylesheet". Again, I'm talking about the
> > > situation where the popup menu is hidden.
> > >
> > > A few things to note:
> > > * This tooltip doesn't really explain what the Stylesheet option is
> for.
> > > It
> > > explains what the selected value is. That's already inconsistent with
> > > other
> > > options - the tooltip on a text entry field will explain you what
> input is
> > > expected from you. This information is not given for combobox tooltips.
> > > That only gives a tip on what's currently selected.
> > >
> > > * The tooltip "Default stylesheet" adds very little extra useful
> > > information compared to the option name being "Stylesheet" and the
> option
> > > value being "Default".
> > >
> > > So there's little reason to add tooltips in this case to start with.
> > >
> > > Next, given the limitations of a normal GtkComboBox, we could also
> build
> > > tooltips for such combos as follows:
> > >
> > > * Begin with an explanation of what the option is for (not what each
> value
> > > represents)
> > > * Then add a list of possible values, and for each value an
> explanation of
> > > what it represents. I actually think if the explanation of the option
> is
> > > well done, it's unlikely each value itself still needs an explanation,
> > > just listing the possible options may be enough.
> > >
> > > The advantage of this way of working is that a user gets a complete
> > > overview by hovering the combobox even before clicking and navigating
> > > through the popup menu. And there's an overarching overall tooltip to
> add
> > > context to the possible choices. Something we currently are lacking.
> > >
> > > This can still be done in code, though we need to add sensible
> explaining
> > > tooltips for the options that are using a combobox widget. I don't
> think
> > > we
> > > currently have those.
> > >
> > > Note you can still do smart things like highlight the selected value in
> > > the
> > > big tooltip using markup so more attention is drawn to the currently
> > > selected value (and its possible explanation).
> > >
> > > As an exercise I went through all the comboboxes in the transaction
> > > report's options. From my estimate with a decent description of what
> the
> > > option does, the actual option values are self-explanatory in 99% of
> the
> > > cases. Only in very few situations a per value tooltip can add some
> > > additional information. And even there it's usually only for one of two
> > > values in the whole value list.
> > >
> > > For example, there's the "Primary Key" option. That in itself is a very
> > > technical and unfortunate option name, but that's what we have now. If
> a
> > > general tooltip was added to explain this sets the column to sort on
> > > first,
> > > there's no need for any of the tooltips on the possible values. It's
> > > pretty
> > > clear those are column names.
> > >
> > > Another example: Void Transactions.
> > > If a tooltip explains this option allows to filter transactions based
> on
> > > their voided status, that would already explain all the possible
> values.
> > > One could add a note/warning in that tooltip that if void transactions
> > > are selected, their values will be added to the totals as well. With
> that
> > > everything that's currently presented via the per-value tooltips is
> > > available in the general tooltip and more.
> > >
> > > The same worked for me for each and every of the other options.
> > >
> > > So while you are free to fix this as you see fit, I'm a strong
> proponent
> > > of
> > > revisiting our decision to continue to use per value tooltips.
> > >
> > > Regards,
> > >
> > > Geert
> > >
> > > Op dinsdag 16 februari 2021 12:10:56 CET schreef Robert Fewell:
> > >> Hi,
> > >>
> > >> In bug 798109 it was highlighted that the widget I wrote back in 2012
> > >> does
> > >> not respond to keyboard use well which I think would be relatively
> easy
> > >> to
> > >> fix and maybe a couple of tweaks.
> > >>
> > >> Geert suggested that it could be dropped in favour of a traditional
> > >> GtkComboBox.
> > >>
> > >> The reason I wrote it was to match the GTK2 version at that time which
> > >> allowed you to have tooltips on the popped up menu items as well as
> when
> > >> the item was selected and the popup removed. This can not be done in
> the
> > >> GTK3 version as I can see no way of getting to the used GtkMenu. The
> GTK3
> > >> version only supports a tooltip when there is no popup displayed. This
> > >> tooltip can still be specific to the selected item with the use of a
> > >> 'query-tooltip' call back.
> > >>
> > >> I think the widget is mainly used in dialog options for reports.
> > >>
> > >> I am fine with fixing the widget or replacing it, just asking if
> there is
> > >> a
> > >> preference.
> > >>
> > >> Regards,
> > >> Bob
> > >> _______________________________________________
> > >> gnucash-devel mailing list
> > >> gnucash-devel at gnucash.org
> > >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > >
> > > _______________________________________________
> > > gnucash-devel mailing list
> > > gnucash-devel at gnucash.org
> > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


More information about the gnucash-devel mailing list