Re: tree model
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? 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.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:07 -0400, Havoc Pennington wrote: Hi, On Wed, Aug 20, 2008 at 8:47 PM, Yu Feng [EMAIL PROTECTED] wrote: First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. If we think of GLib features as either for C, or for language bindings in general, or for vala, this particular feature seems like it would be *only* for vala - refcounted strings would be pretty strange in plain C, and just overhead for other language bindings that already have native string types they have to convert gchar* to. Putting only-useful-for-vala features in GLib would seem odd to me. Just one opinion, though. Can't vala do the same optimizations a C programmer would do by hand in most cases - avoiding a copy for a const char* that is only stored temporarily in local scope, for example? For other cases, a plain C program would have the same inefficiencies as vala it seems like, and they are not fatal inefficiencies... What about a libvala? I guess vala is supposed to have this property that it doesn't create dependencies in distributed tarballs, but that design goal has brought us autoconf and libtool in the past... not sure I'm sold on it. Or then, embedding it in the compiler does not seem like a very big deal - it's just two operations ref and unref, both of which are trivial and can just be inlined... Havoc I think we are confusing issues here Its GString and not char * which needs the ref counting Other languages (C++ and Delphi) both use ref counting for their strings and they are invaluable to C devs too who do multi-threaded stuff. This is clearly not vala specific as a result (ever tried to free a string correctly where its used in multiple threads?) At the moment there is an inconsistent split between glib structures like GHashTable which use ref counting and the others (GList, GString et all) which dont. I do hope GLib 3 will fix this jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:18 -0400, Colin Walters wrote: On Wed, Aug 20, 2008 at 9:07 PM, Havoc Pennington [EMAIL PROTECTED] wrote: What about a libvala? I guess vala is supposed to have this property that it doesn't create dependencies in distributed tarballs, but that design goal has brought us autoconf and libtool in the past... not sure I'm sold on it. Another nail in the no-libvala idea's coffin is that it seems to me[1] it's a violation of the GPL to distribute code that doesn't build using the preferred form of the work for making modifications to it (GPL sec 3). In other words, generated .c files are no different from .jars and the like, and free OS vendors should not allow software which includes them. [1] IANAL etc. Thats obviously not the case Are you saying Yacc/Bison and lex/flex source files which generate c files are also incompatible with GPL? if so a whole load of software is in violation (including gcc) jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:49 -0400, Colin Walters wrote: On Wed, Aug 20, 2008 at 9:39 PM, Jamie McCracken [EMAIL PROTECTED] wrote: Are you saying Yacc/Bison and lex/flex source files which generate c files are also incompatible with GPL? Of course not; it's perfectly valid in general to have code generate code. But if your build process doesn't invoke yacc or bison but just relies on the shipped generated .c files, that is a problem. not a problem if the vala source and means to build them using valac and makefiles are publically available. GPL only affects distribution so if you also make the original vala source distributable (separately or in the same package with the same terms) then it should not be an issue In any case, distros can always use valac to build anything written in vala (or genie) so im not sure why any of this matters? jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Qt vs. Gtk+ holy war Was: Steps to get to GTK+ 3.0
On Thu, 2008-06-05 at 15:55 +0100, Ross Burton wrote: On Thu, 2008-06-05 at 16:16 +0200, Christian Dywan wrote: What about Genie even? [indent=4] uses Glib class Foo : Object init var bar = 0 That doesn't define a property. This does: class Foo : Object prop bar : int init _bar = 0 jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
