After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 562244 - Containers should be list-like
Containers should be list-like
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Documentation
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-11-25 16:52 UTC by Björn Lindqvist
Modified: 2013-08-13 22:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Describe containers child ordering (1.09 KB, patch)
2008-11-25 16:54 UTC, Björn Lindqvist
none Details | Review
Fixes grammatical issues with previous patch (1.09 KB, patch)
2008-11-26 14:56 UTC, Björn Lindqvist
none Details | Review

Description Björn Lindqvist 2008-11-25 16:52:22 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.
Comment 1 Björn Lindqvist 2008-11-25 16:54:10 UTC
Created attachment 123374 [details] [review]
Describe containers child ordering
Comment 2 Philip Withnall 2008-11-25 22:06:57 UTC
s/Iteration of the containers/Iteration of the container's/
Comment 3 Christian Dywan 2008-11-26 08:11:59 UTC
"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.
Comment 4 Emmanuele Bassi (:ebassi) 2008-11-26 13:01:09 UTC
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.
Comment 5 Yevgen Muntyan 2008-11-26 14:21:06 UTC
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.
Comment 6 Björn Lindqvist 2008-11-26 14:56:00 UTC
Created attachment 123425 [details] [review]
Fixes grammatical issues with previous patch
Comment 7 Björn Lindqvist 2008-11-26 15:32:01 UTC
(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.

Comment 8 Matthias Clasen 2008-11-26 19:17:56 UTC
> 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.
Comment 9 Philipp 2008-12-07 11:58:29 UTC
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.
Comment 10 Matthias Clasen 2013-08-13 22:54:14 UTC
didn't happen