GNOME Bugzilla – Bug 162531
GtkComboBox 'popup' signal missing
Last modified: 2011-02-04 16:10:23 UTC
1. Have a combobox model read from some slow source, i. e. a database, a internet source.. 2. Thus want the combobox only to refresh on 'opening the dropdown' (and look for additional entries then) 3. hmm O_o no signal for that
*** Bug 162802 has been marked as a duplicate of this bug. ***
I don't think you would want the whole UI to block on a slow database connection when someone clicks on a ComboBox. Why can't you update the list in the background, as soon as you get enough information? This signal might be needed, but this doesn't sound like the necessary use case yet.
Mine was just an example but as you said there are a lot of situations where this can be really useful.
Actually, compared to the alternatives, its prefered to block the UI on a slow database connection when someone clicks on a combobox rather than populate all the data. The main Account screen for my software has 14 combobox type fields. Binding all these fields to the database when opening the form would slow everthing down a lot. Most of the time, 14 queries to the DB would be executed for no reason as the user is just viewing the data, not changing it.
Well said. And note that one can always fine tune the populating: - connect "clicked", to a handler clicked_cb - in clicked_cb, check if timer a (or thread a, doesnt matter) is running, and if not, start it, handler timer_cb - in timer_cb, read the data chunkwise when finished remove timer a This has the effect that when the user clicks on the combo, the data is started to be read (note that the combo dropdown is open now). As the read advances, entries get added (with a "..." node advancing at the end to signal that). When the read finished, the "..." node is removed. The user can, at any stage, select an entry from the combo (which doesnt stop the read because it may need it either way) How does that sound ?
Created attachment 50995 [details] [review] add "popup-show" and "popup-hide" signals Reasoning for adding signals for both showing and hiding is that if you are interested in knowing when the menu pops up, you probably also want to know when it goes away. The patch as such needs work as it's breaking binary compatibility and has minor cosmetic issues as well.
just remove some of the padding for future expansion and it will be binary compatible ;)
I'm not worried about binary compatibility, fixing it is trivial. The devil is in the details, should it be two signals, one signal with boolean parameter, one signal with no parameters but getter function, read-only property, ...?
I've been told "grab-notify" signal could be used instead in some case at least.
*** Bug 318514 has been marked as a duplicate of this bug. ***
*** Bug 318826 has been marked as a duplicate of this bug. ***
2005-11-10 Matthias Clasen <mclasen@redhat.com> * gtk/gtkcombobox.c: Add show-popup and hide-popup signals and emit them when the popup is shown or hidden. (#162531, Tommi Komulainen)
I think this should be redone using a property instead: with signals, you have to track both show and hide and store the state yourself, if you want to access it later; and it wouldn't use 2 reserved slots. If I wrote a patch making this use a property instead, would it be accepted?
It would be considered
Created attachment 57677 [details] [review] implement property instead Things to consider: - make it readonly property maybe? - I didn't add a public getter, and there's already gtk_combo_box_popup and _popdown available, so a public setter doesn't make sense either, probably.
Yes, I think a readonly property is better, and not having a getter is probably fine. You might want to point out in the docs that the property is mostly useful for listening for change notification. It looks slightly odd to me that the property is named "-popup", but the docs speak about a "dropdown".
2006-03-09 Matthias Clasen <mclasen@redhat.com> * gtk/gtkcombobox.c (gtk_combo_box_class_init): Replace the popup-show and popup-hide signals with a readonly popup-shown property. (#162531, Christian Persch)