Minutes of the GTK+ Team Meeting - 2008-08-26
= minutes for the 2008-08-26 meeting = * 2.14 release - filechooser sizing/positioning regressions still blockers * non-X11 backends readiness - no blockers for win32 - quartz developers were not available * 2.90/3.0 plan - mclasen prepared an initial draft for the 2.90 plan - when 2.14 is released the plan is to be sent to the mailing list - gtk.org will have a gtk3 section with the plan (expanded) ACTION: mclasen to prepare another draft for internal comments before 2.14 relase * advisory board meeting - there has been a small (30min) talk about gtk+ 3.0 at the advisory board meeting at GUADEC 2008 - unfortunately, there were no technical representatives - the board wants to organize a conference call on 2008-09-10 with technical representatives and ISVs/ISDs - the official gtk+ 3.x plan should be out before that date - possibly have timj, kris, mitch to attend the call and give a technical presentation about the plan - vuntz trying to involve ISVs/ISDs in contributing upstream and helping to achieve the gtk+ 3.x goals ACTION: mclasen, timj will attend. possibly kris and mitch as well irc log available at: http://live.gnome.org/GTK+/Meetings next meeting: 2008-09-09, 20:00 UTC ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ 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.
2008/8/23 Havoc Pennington <[EMAIL PROTECTED]>: >> How much more complicated is it for bindings (most of which use ref-counted >> strings themselves) to wrap a reference to a >> string instead of wrapping a whole new copy of the string. > > This one I can answer: most bindings would have to copy the strings > into a native string type just as they do now. A few, maybe Vala and > C++, could conceivably avoid the copy. So refcounted strings would not > matter much for bindings in general but might help the C-like > bindings. Naturally, they wouldn't have to copy the actual string data and you are forgetting all these "The returned string is owned by the $something object and should not be freed. " All that just magically disappears with ref-counted strings. The bindings become one step simpler because there is one bit less information that they need to account for. -- mvh Björn ___ 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 25/08/2008, "Paul LeoNerd Evans" wrote:
> On Sat, 23 Aug 2008 "Havoc Pennington" wrote:
>> If you're talking about converting existing APIs to refcounted
>> strings, that's a very different proposal from just adding some kind
>> of refcounted string feature. It would break thousands of apps, or
>> else duplicate hundreds of API entry points ...
> Personally, I didn't have in mind a change of existing API;
> simply an addition of something new:
While moderately handy, GString is nowhere near as useful as it could be, so
I'd say if you're going to add ref-counted strings than it's safe to just add
ref-count directly to GString. I doubt it'll have a notable impact even in
apps where it's not needed. I can't think of any occasion when I've actually
used a bare GString, it just doesn't do anything that can't be done better.
> typedef struct {
> gchar *str;
> gsize len;
> gint refcount;
> } GCString;
Your GCString, like my ZString below, is somewhat more useful due to the
ref-counting. But until it's supported in a useful way by GLib and GTK
natively, it may as well just be a chunk of text on a wiki page somewhere for
people to copy and paste verbatim into their own projects.
What I generally do is use a very simple GString wrapper;
typedef struct {
GString str;
gint refcount;
} ZString;
and then a bunch of #defines to wrap most of the GString functions with
appropriate type-casting back and forth. The only functions that actually need
re-implementing are the new/free ones. It ain't pretty, but it works.
> GCString *g_cstring_new_static(gchar *static_data);
> GCString *g_cstring_new_from_gstring(GString *clone);
> GCString *g_cstring_ref(GCString *str);
> void g_cstring_unref(GCstring *str);
GCString *g_cstring_new(gchar *dynamic_data);
which takes over ownership of an already-allocated string. len and
allocated_len are both set from strlen().
With an allocated_len field you can also indicate static string data by leaving
it at zero. (is_static = str && ! allocated_len) That also makes this useful:
GCString *g_cstring_new_full(gchar *dynamic_data, gint len, gint
allocated_len);
which does everything that all three of them do. If len is -ve, it's set from
strlen(), likewise if allocated_len is -ve, it's set from len. _new and
_new_static could then simply be wrappers to _new_full(), although being as
simple as they are it'd probably be better to keep them as discrete functions.
Fredderic
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
