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.gnuc...@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.gnuc...@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@gnucash.org > > >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > > > > _______________________________________________ > > > gnucash-devel mailing list > > > gnucash-devel@gnucash.org > > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
