Kristian Rietveld wrote:
Hi,
On Sun, Jul 26, 2009 at 8:22 PM, Thomas Stovertho...@wsinnovations.com wrote:
While working on a custom tree model (thanks to Tim-Philipp Müller for the
tutorial), I needed more pointers in my iter structure than the user_data,
user_data2, and user_data3. So I
Hi,
On Sun, Jul 26, 2009 at 8:22 PM, Thomas Stovertho...@wsinnovations.com wrote:
While working on a custom tree model (thanks to Tim-Philipp Müller for the
tutorial), I needed more pointers in my iter structure than the user_data,
user_data2, and user_data3. So I defined a new structure
While working on a custom tree model (thanks to Tim-Philipp Müller for
the tutorial), I needed more pointers in my iter structure than the
user_data, user_data2, and user_data3. So I defined a new structure and
stored that in user_data. For the model's _get_iter(), _iter_children
Here's a GLib with a collection API
http://git.codethink.co.uk/?p=glib;a=shortlog;h=collections
On Mon, 2009-05-11 at 13:27 -0400, Jamie McCracken wrote:
I would hope iterators and models will be part of glib 3.0 to avoid 3rd
party duplication as well as all other Libgee functionality
I would hope iterators and models will be part of glib 3.0 to avoid 3rd
party duplication as well as all other Libgee functionality
this would also make it more vala friendly
jamie
On Mon, 2009-05-11 at 19:16 +0200, Szilárd Pfeiffer wrote:
What do you want to do with that? What about GNode?
2009/5/12 Matthias Clasen matthias.cla...@gmail.com:
I should have been slightly more clear: I am interested in being able to
provide a GtkTreeModel for those people who wish to use it without having to
link to libgtk myself.
So the problem with using GNode: GtkTreeView doesn't use it.
I
Am Tue, 12 May 2009 08:10:11 +0200
schrieb Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com:
2009/5/12 Matthias Clasen matthias.cla...@gmail.com:
I should have been slightly more clear: I am interested in being
able to provide a GtkTreeModel for those people who wish to use it
On Mon, 2009-05-11 at 21:10 -0400, Matthias Clasen wrote:
I should have been slightly more clear: I am interested in being able to
provide a GtkTreeModel for those people who wish to use it without having to
link to libgtk myself.
So the problem with using GNode: GtkTreeView doesn't
On Tue, 2009-05-12 at 10:47 +0200, Christian Dywan wrote:
Am Tue, 12 May 2009 08:10:11 +0200
schrieb Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com:
2009/5/12 Matthias Clasen matthias.cla...@gmail.com:
I should have been slightly more clear: I am interested in being
able to
On Tue, 2009-05-12 at 12:50 +0200, Alexander Larsson wrote:
On Tue, 2009-05-12 at 10:47 +0200, Christian Dywan wrote:
Am Tue, 12 May 2009 08:10:11 +0200
schrieb Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com:
2009/5/12 Matthias Clasen matthias.cla...@gmail.com:
I should
Thomas Wood wrote:
I think the Clutter project has it's own model implementation only
because there isn't one in glib. There isn't actually a consumer in
Clutter for ClutterModel, but other libraries built on top of Clutter
use it.
Yes. It's exactly about libraries.
I have a similar
On Tue, May 12, 2009 at 9:50 AM, Ryan Lortie de...@desrt.ca wrote:
Since GtkTreeModel also has no
reason to depend on (the rest of) GTK, it seems logical to move it into
glib.
It is not that GtkTreeModel depends on the rest of GTK+, it is more
that GtkTreeModel is designed for being the model
Matthias Clasen wrote:
On Tue, May 12, 2009 at 9:50 AM, Ryan Lortie de...@desrt.ca wrote:
Since GtkTreeModel also has no
reason to depend on (the rest of) GTK, it seems logical to move it into
glib.
It is not that GtkTreeModel depends on the rest of GTK+, it is more
that GtkTreeModel is
On Tue, 2009-05-12 at 14:05 +0300, Claudio Saavedra wrote:
snip
totem-pl-parser is using GtkTreeModel as well. IIRC, tracker uses
totem-pl-parser to parse playlists, but I guess they are not interested
on GtkTreeView.
It uses a GtkTreeModel, not a GtkTreeView, and only for the saving bits.
are there any 3ish plans for GtkTreeModel - GTreeModel?
cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
What do you want to do with that? What about GNode? Isn't it good for you?
regards,
Szilárd
Ryan Lortie wrote:
are there any 3ish plans for GtkTreeModel - GTreeModel?
cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
I see. In this case unfortunately I am the person who can help you.
Jamie McCracken wrote:
I would hope iterators and models will be part of glib 3.0 to avoid 3rd
party duplication as well as all other Libgee functionality
this would also make it more vala friendly
jamie
On Mon,
Szilárd Pfeiffer wrote:
What do you want to do with that? What about GNode? Isn't it good for you?
I should have been slightly more clear: I am interested in being able
to provide a GtkTreeModel for those people who wish to use it without
having to link to libgtk myself.
So the problem
I should have been slightly more clear: I am interested in being able to
provide a GtkTreeModel for those people who wish to use it without having to
link to libgtk myself.
So the problem with using GNode: GtkTreeView doesn't use it.
I don't see why this is something we should be eager to
On Thu, Mar 23, 2006 at 03:22:13PM +0100, Tim Janik wrote:
disabling G_GNUC_WARN_UNUSED_RESULT globally is not what anyone of us had
in mind i think. i agree with you that the patch should simply be backed
out where it generates too many warnings.
did you, or anyone else for that matter,
On Fri, 24 Mar 2006, Kristian Rietveld wrote:
On Thu, Mar 23, 2006 at 03:22:13PM +0100, Tim Janik wrote:
disabling G_GNUC_WARN_UNUSED_RESULT globally is not what anyone of us had
in mind i think. i agree with you that the patch should simply be backed
out where it generates too many warnings.
Tim Janik wrote:
tree model iterators are easily advanced/setup/created in a way that
yields
an invalid iterator, because the denoted location doesn't exist
(anymore).
to cath those cases, the tree model API returns booleans indicating
success,
but testing those booleans is easily forgotton
Tim Janik wrote:
hi all.
tree model iterators are easily advanced/setup/created in a way that
yields
an invalid iterator, because the denoted location doesn't exist
(anymore).
to cath those cases, the tree model API returns booleans indicating
success,
but testing those booleans is easily
On Sat, 18 Feb 2006, Owen Taylor wrote:
On Fri, 2006-02-17 at 19:52 +0100, Tim Janik wrote:
i admit that artificial cases where checking the return value is not
required are easily created, but the actual harm involved is just a
mild annoyance. that is in contrast to forgetting to check the
of the
world :)
Can we see some examples of code that was broken and what it should be
doing?
this sounds a bit like you're questioning the iter functions returning a
boolean rather than void...
Most of the tree model functions return boolean because you can
use them to iterate over collections
hi all.
tree model iterators are easily advanced/setup/created in a way that yields
an invalid iterator, because the denoted location doesn't exist (anymore).
to cath those cases, the tree model API returns booleans indicating success,
but testing those booleans is easily forgotton and a common
On Fri, 2006-02-17 at 14:29 +0100, Tim Janik wrote:
to help the compiler catch these mistakes, i've prepared a patch that adds
G_GNUC_WARN_UNUSED_RESULT to all relevant iterator functions, and intend
to commit that next week unless objections pop up. in principle it does:
This is pretty
On Fri, 2006-02-17 at 11:01 -0600, Federico Mena Quintero wrote:
On Fri, 2006-02-17 at 14:29 +0100, Tim Janik wrote:
to help the compiler catch these mistakes, i've prepared a patch that adds
G_GNUC_WARN_UNUSED_RESULT to all relevant iterator functions, and intend
to commit that next
gtk_widget_show() return
a boolean value that you are supposed to check because you might
have passed in a NULL pointer for the widget.
i don't quite see the parallel. while i've never missed a return value when
using gtk_widget_show(), with tree model iterators you will want to check
the return
29 matches
Mail list logo
