[GNC-dev] GncCombott Widget

Tue Feb 16 12:12:58 EST 2021

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