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 50795 - iterating over a range in a GTree
iterating over a range in a GTree
Status: RESOLVED WONTFIX
Product: glib
Classification: Platform
Component: general
1.2.x
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2001-02-12 10:20 UTC by Maciej Stachowiak
Modified: 2011-02-18 16:13 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Patch (4.23 KB, patch)
2001-02-12 10:23 UTC, Maciej Stachowiak
none Details | Review

Description Maciej Stachowiak 2001-02-12 10:20:04 UTC
I have uploaded glib-sandmann-990808-0.patch.gz to
ftp.gtk.org/incoming.

This patch implements a g_tree_lookup_range for the GTrees in GLib. As
the name says, it implements a way to retrieve ranges from a
GTree. Currently it is impossible to do this.

The function g_tree_node_lookup_range does more comparisons than is
actually needed; it would be more efficient but more difficult to read
if subtrees that are known to be in the range were just added to list
instead of comparing every node to the from_- and to_keys.

Søren Sandmann (sandmann@daimi.au.dk)
Comment 1 Maciej Stachowiak 2001-02-12 10:23:48 UTC
Created attachment 229 [details] [review]
Patch
Comment 2 Owen Taylor 2001-03-16 19:33:17 UTC
Although I can see where, in some applications, the 
ability to fetch all keys n a range of a GTree is
useful, I don't think this is quite the right interface;
introducing the list and memory management is not what
you would always want; I think an iteration is probably
more what you want.

The right interface, I believe, is is g_tree_foreach_range().
(And actually, along with, g_tree_foreach() should
be added, because g_tree_traverse with anything other
that G_IN_ORDER is completely useless.)

I consider this pretty low priority because, basically,
people don't use GTree very much.
Comment 3 Soren Sandmann Pedersen 2003-06-30 19:36:31 UTC
I'm WONTFIX'ing this. I think GSequence (see bug 115664) is a better
approach to solving this problem.