[GNC-dev] GncCombott Widget

[Geert Janssens]

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