GNOME Bugzilla – Bug 562244
Containers should be list-like
Last modified: 2013-08-13 22:54:14 UTC
See this mail: http://mail.gnome.org/archives/gtk-devel-list/2008-October/msg00034.html By updating the documentation to guarantee that GtkContainers are list-like, we make fixing bugs like #550345 easier. In practice, they already are because tons of code depends on it. But it is still good to state it explicitly.
Created attachment 123374 [details] [review] Describe containers child ordering
s/Iteration of the containers/Iteration of the container's/
"That means that subsequent invocations of for example <function>gtk_container_get_children()</function> return identical lists unless the order has been rearranged explicitly." Note s/returns/return since 'invocations' is the subject in plural. Note further more the removal of commata and moving 'explicitly' to the end of the sentence. "Iterations of the children of a container always start with the first widget in the container, then the second, third and so on." Note the explicit 'children of a container' wording saying 'Iterations'. "Subclasses of <structname>GtkContainer</structname> must not violate these two constraints otherwise they might not work properly." I'm not sure about the usage of 'might' here, it implies an uncertainty to me. What about this: "Subclasses of <structname>GtkContainer</structname> which don't adhere to these two constraints are not guaranteed to work properly.
I'm not entirely favourable to add this specification to the contract. suppose I have a "paged" GtkContainer, using a hash-table to store its children which are uniquely identified by a string. right now, I can just call g_hash_table_get_values() when getting the children - but that function is not guaranteed to respect any order (how could it). so, instead of using a single hash table, I'd have to create two structures: a list, holding all widgets in insertion order, and an hash-table for lookup purposes. this would complicate the code (keep the two data structures in sync) and would introduce potential slow operations (removal would move from being O(1) to being O(n)). if this whole idea is to have a guarantee on the stacking/drawing order, then API should be added to GtkContainer.
To fix 550345 you don't need any generic guarantees about the order. The order there is all right. The problem there is tooltip code not respecting the order, not absence of the order.
Created attachment 123425 [details] [review] Fixes grammatical issues with previous patch
(In reply to comment #4) > I'm not entirely favourable to add this specification to the contract. > > suppose I have a "paged" GtkContainer, using a hash-table to store its children > which are uniquely identified by a string. right now, I can just call > g_hash_table_get_values() when getting the children - but that function is not > guaranteed to respect any order (how could it). Can you provide some code example of such a container? I can't imagine how it would work. Supposedly the pages in the "paged" GtkContainer would still need some kind of (deterministic) order, right? How would the container be able to correctly size allocate its children? How would introspective tools like glade deal with the container? The order of the childs displayed in the widget tree would be random. > so, instead of using a single hash table, I'd have to create two structures: a > list, holding all widgets in insertion order, and an hash-table for lookup > purposes. this would complicate the code (keep the two data structures in sync) > and would introduce potential slow operations (removal would move from being > O(1) to being O(n)). Probably you would use an ordered hash-table instead, but yes, removal time would decrease to O(n) while lookup would still be constant O(1). I've my doubts about using big-O notation to measure algorithms in gtk because most of the time, n < ~10. GList for example has O(n) lookup time which would be O(1) instead if it was implemented as a GArray instead but that hasn't hurt anyone. :) > if this whole idea is to have a guarantee on the stacking/drawing order, then > API should be added to GtkContainer. Why? The whole point is that new API isn't needed.
> I'm not entirely favourable to add this specification to the contract. Me neither. You don't get to change the rules of the game 6 years into it.
It sounds to me like we already have code depending on list-like behaviour in GtkContainer. So any purely hashtable-based implementation "out there" would be subtly or openly broken anyway, right ? So in that case, it's better to document this expectation cleary, in the hope that somebody "out there" will notice this bit of advice. So, +1 in case such a hidden assumbtion can be shown, +0 otherwise. +1 in any case for using something like GeeList in 3.0.
didn't happen