Re: [cairo] gobject boxed types

Am 15.09.08, 13:46 +0200 schrieb Alexander Larsson: > On Sat, 2008-09-13 at 15:05 -0400, Havoc Pennington wrote: > > Hi, > > > > On Sat, Sep 13, 2008 at 1:38 PM, Colin Walters <[EMAIL PROTECTED]> wrote: > > > Actually I just had a random thought - what about putting this code > > > into pangocairo

svn prop for .svg images

Hey all, We were browsing the stock icons from viewvc today and noticed that the mime type is wrong. Behdad said you all are the folks I should ask before committing this: [EMAIL PROTECTED]:/usr/src/svn/gnome/gtk+/trunk$ svn propset svn:mime-type image/svg+xml `find ./gtk/stock-icons -name '*.s

Re: string return result conventions

> ok - can i ask people a favour? could you kindly review e.g this: > http://lkcl.net/webkit/DerivedSources/GdomAttr.cpp > just looking at it myself, i think where i use fromUTF8 i have a > memory leak, ... but after looking at it again i don't think i have.. > there, but key question:

Re: string return result conventions

On Mon, Sep 15, 2008 at 3:48 PM, Owen Taylor <[EMAIL PROTECTED]> wrote: > On Mon, 2008-09-15 at 08:59 +, Luke Kenneth Casson Leighton wrote: >> tim, thank you for responding. >> >> >> therefore it's important for me to find out what glib / gobject memory >> >> conventions are, for strings. >> >

Re: string return result conventions

On Mon, 2008-09-15 at 08:59 +, Luke Kenneth Casson Leighton wrote: > tim, thank you for responding. > > >> therefore it's important for me to find out what glib / gobject memory > >> conventions are, for strings. > > > > Strings querried through the property interfacem e.g.: > > > > gchar *str

Re: string return result conventions

>> it was recommended to me that i create a string pool system, to keep a >> record of strings created, and, at convenient times, destroy them all >> (reminds me of apache pools and samba talloc). exactly when is >> "convenient" is yet to be determined, which is the bit i'm not too >> keen on :) >

GtkAssistant: feature request

I'm thinking of filing a feature request for GtkAssistant, but I'd like to post it here first to see if I'm missing something. In a non-trivial "wizard"-type process, it's possible that the user reaches a dead end: a situation where progress is not possible given the data supplied so far -- but

Re: [cairo] gobject boxed types

Behdad Esfahbod wrote: Colin Walters wrote: Here is a patch, should apply to the latest git. I also like to see gobject enum types for cairo. Also, should the type names be CairoContext-like or simply cairo_t? If this is going to be used by introspection stuff, CairoContext sounds correct.

Re: [cairo] gobject boxed types

Hi, On Sun, Sep 14, 2008 at 9:45 PM, Vladimir Vukicevic <[EMAIL PROTECTED]> wrote: > I don't understand the concern about "doesn't mess up the dependency graph" > -- there are already a dozen libraries that get linked to any glib-using app > -- why does one more hurt, especially when it would be a

gdk_cairo_set_source_pixmap API misleadingly using GdkPixmap*?

Hi, I've opened a bug on gdk_cairo_set_source_pixmap API apparently misleadingly using GdkPixmap* on 2008-04-08: http://bugzilla.gnome.org/show_bug.cgi?id=526965 Can it be examined sometime please? -- Guillaume Cottenceau - http://zarb.org/~gc/ ___ g

Re: [cairo] gobject boxed types

On Sun, Sep 14, 2008 at 11:49 PM, Behdad Esfahbod <[EMAIL PROTECTED]> wrote: > Kai-Uwe Behrmann wrote: >> Making each application, using Cairo, practical dependent to Glib, appears >> not nice for non Gtk applications. A Cairo package would nearly always >> depend on glib, which makes things like t

Re: [cairo] gobject boxed types

On Sep 14, 2008, at 7:09 AM, Havoc Pennington wrote: Hi, Johan suggested on IRC that the patch to cairo could be changed to use dlopen to grab the copy/free functions lazily, to avoid a compile-time dependency on glib (and also avoid a runtime dependency, if running in an app that doesn't link

Re: [cairo] gobject boxed types

On Sat, 2008-09-13 at 15:05 -0400, Havoc Pennington wrote: > Hi, > > On Sat, Sep 13, 2008 at 1:38 PM, Colin Walters <[EMAIL PROTECTED]> wrote: > > Actually I just had a random thought - what about putting this code > > into pangocairo? All of Gtk+, GooCanvas, HippoCanvas and Clutter > > depend on

Re: string return result conventions

Am Mon, 15 Sep 2008 11:20:41 +0200 (CEST) schrieb Tim Janik <[EMAIL PROTECTED]>: > On Mon, 15 Sep 2008, Luke Kenneth Casson Leighton wrote: > > > clearly, the best overall thing would be to actually return the > > unicode strings themselves rather than convert them (needlessly?) to > > utf-8. >

Re: string return result conventions

On Mon, 15 Sep 2008, Luke Kenneth Casson Leighton wrote: ok - in this situation, fortunately we have control over that. the property getter is entirely auto-generated. the code review of the new webkit glib/gobject bindings brought to light the webkit convention of not imposing any "memory fre

Re: string return result conventions

tim, thank you for responding. >> therefore it's important for me to find out what glib / gobject memory >> conventions are, for strings. > > Strings querried through the property interfacem e.g.: > > gchar *string = NULL; > g_object_get (label, "label", &string, NULL); > > is always duplicated an