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?
On Tue, 2009-05-12 at 14:05 +0300, Claudio Saavedra wrote:
> 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.
Matthias Clasen wrote:
On Tue, May 12, 2009 at 9:50 AM, Ryan Lortie 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
On Tue, May 12, 2009 at 9:50 AM, Ryan Lortie 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 part of
Gtk
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 situation
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 :
> >
> > > 2009/5/12 Matthias Clasen :
> > > >>
> > > >> I should have been slightly more clear: I
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 :
>
> > 2009/5/12 Matthias Clasen :
> > >>
> > >> I should have been slightly more clear: I am interested in being
> > >> able to provide a GtkTreeModel for those peo
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: GtkTreeVie
Am Tue, 12 May 2009 08:10:11 +0200
schrieb Mikkel Kamstrup Erlandsen :
> 2009/5/12 Matthias Clasen :
> >>
> >> 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.
> >
2009/5/12 Matthias Clasen :
>>
>> 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 wh
>
> 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 eage
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 wit
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, 2009-05-
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
http://mail.gn
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
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.
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,
Tim Janik wrote:
did you, or anyone else for that matter, investigate yet whether it'd
be worth
keeping the warnings for *some* of the functions?
I did go through the list, and all the warnings may or may not be bogus
depending
on situation.
gtk_tree_model_get_iter_from_string may look sus
On Tue, 21 Mar 2006, Yevgen Muntyan wrote:
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:
These warn
On 3/21/06, Yevgen Muntyan <[EMAIL PROTECTED]> wrote:
2) When you get path/iterator somehow, with error checking, and thenconvert itto iterator/path. E.g. you can get a path from a row reference, and ifit's not NULL,you know it's a valid path, so you don't need to check return value of
gtk_tree_mod
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 forg
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 e
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 r
nice. It may create a few warnings for code that knows
> >> that certain operations will succeed, but better help the rest of the
> >> world :)
> >
> > Can we see some examples of code that was broken and what it should be
> > doing?
>
> this sounds a bit l
arnings to be seldomly triggered.
This seems a little similar to making 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
u
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
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 ni
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 c
29 matches
Mail list logo
