[GNC-dev] GncCombott Widget

John Ralls jralls at ceridwen.us
Tue Feb 16 11:37:21 EST 2021

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.

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

More information about the gnucash-devel mailing list