Re: Where is Glib::strfreev()?
I think it means g_strfreev, where it frees an array of null terminated strings. See http://library.gnome.org/devel/glib/stable/glib-String-Utility-Functions.html Cheers Johnson Message: 1 Date: Fri, 1 May 2009 22:34:48 +0300 From: sledge hammer sledgehammer_...@hotmail.com Subject: Where is Glib::strfreev()? To: gtk-app-devel-list@gnome.org Message-ID: blu122-w418df7831e7a7544f62c9eab...@phx.gbl Content-Type: text/plain; charset=iso-8859-7 Hello, I use Gtk::SelectionData::get_uris() and in the docs says that if I get a non-0 result I should use Glib::strfreev() to free it. The problem is there is no documentation about Glib::strfreev() and I don't know how to use it. I cant even find an example that uses it. So can you show me how to use it to free the result and have mem leaks? Sidenote: I use std::vectorGlib::ustring as container. Thanks in advance. _ ? Messenger; ? ??? Windows Live. ?? ???. http://www.microsoft.com/windows/windowslive ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: .gitignore files
Am Freitag, den 01.05.2009, 14:10 -0400 schrieb Behdad Esfahbod: git.mk. What's this git.mk? -- Mathias Hasselmann mathias.hasselm...@gmx.de Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: .gitignore files
Le samedi 02 mai 2009, à 14:14 +0200, Mathias Hasselmann a écrit : Am Freitag, den 01.05.2009, 14:10 -0400 schrieb Behdad Esfahbod: git.mk. What's this git.mk? http://git.gnome.org/cgit/pango/tree/git.mk Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: .gitignore files
Am Samstag, den 02.05.2009, 14:25 +0200 schrieb Vincent Untz: Le samedi 02 mai 2009, à 14:14 +0200, Mathias Hasselmann a écrit : Am Freitag, den 01.05.2009, 14:10 -0400 schrieb Behdad Esfahbod: git.mk. What's this git.mk? http://git.gnome.org/cgit/pango/tree/git.mk Vincent Oh, fancy! Nice! +1 Why isn't this brilliant logic part of automake already? :-D Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: .gitignore files
On 05/02/2009 08:38 AM, Mathias Hasselmann wrote: Am Samstag, den 02.05.2009, 14:25 +0200 schrieb Vincent Untz: Le samedi 02 mai 2009, à 14:14 +0200, Mathias Hasselmann a écrit : Am Freitag, den 01.05.2009, 14:10 -0400 schrieb Behdad Esfahbod: git.mk. What's this git.mk? http://git.gnome.org/cgit/pango/tree/git.mk Vincent Oh, fancy! Nice! +1 Why isn't this brilliant logic part of automake already? :-D I'm proposing that. behdad Ciao, Mathias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: .gitignore files
At 01.05.2009 20:10, Behdad Esfahbod wrote: On 05/01/2009 04:18 AM, Davyd Madeley wrote: .gitignore files, to improve switching between branches easily. I'd rather add my git.mk. Matthias, want me to go ahead and do that? How is it supposed to work for people building with a different shell/buildsystem? (But maybe it is just me where neither bash nor auto* is in use). Hans Hans at Breuer dot Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
Hey Ryan,
I took a closer look at GVariant today so here are some more comments,
take them, leave them or do whatever you want with them ;-)
Most of these comments are general but, for other readers, it might help
to also read the conversations in
http://bugzilla.gnome.org/show_bug.cgi?id=579571
(GVariant discussion starts around comment 70)
to see where I'm coming from.
o In general, I think GVariant is a very useful data type since
you can serialize instances to disk and send them over the
network or to different processes or whatever.
Especially for something like replacing GConf, this is extremely
useful - no doubt we want to avoid IPC overhead where possible (e.g.
read from shared memory or files or whatever) and use IPC where it
makes sense (for transactions involving writes). It's nice here to be
able to use the same data type, no doubt about it.
o Any particular reason this is not based on the base object class?
There's a bunch of useful things in GObject such as
- Subclassing
- Data associations (e.g. g_object_set|get_data())
- GInterface support
- Weak references
and when bug 557100 is resolved it seems the cost of basing GVariant
on the base object class shouldn't matter.
o It seems like you (or Simon or both) expect GVariant to be the only
container type in town for C bindings for D-Bus (as per the D-Bus
library bug report). E.g. you expect the C programmers to deal with
a{ss} as a GVariant instead of the more natural type GHashTable.
My view is that it's not really realistic to do this, I think it's
a convenient thing that I can get/pass well-known data-types like
GHashTable or GPtrArray from/to remote objects. This allows adding
D-Bus support to existing programs without fundamentally changing
how their data is represented and not having to deal with a vararg
based API should you choose to generate code.
It also seems particularly awkward to not map D-Bus APIs to native
APIs (in GLib, GptrArray, GArray and GHashTable are considered native
APIs for collections) - by the same token, would you expect Python
users to use GVariant? No, they'd want to use the native types so
they have things like hash table literals etc.
Specifically, there is no equivalent of g_hash_table_lookup() etc.
right now on GVariant but I suppose you can add that.
(Btw, if GVariant was based on GObject and we added collection
interfaces to the GLib stack (like some people want, cf. bug
560061), then you'd just make GVariant implement the these
interfaces and that would solve the there is no
g_hash_table_lookup() equivalent complaint.)
I realize that some people are not opposed to the GVariant type
of programming. E.g. build your data up basically using an iterator,
much like the way you build a DBusMessage. Obviously, I can't speak
for others, but I personally don't like that kind of API unless I'm
tooling around with simple D-Bus services. YMMV.
That said, if we were to add the GDBus stuff I'm working on, I don't
think we should antagonize users that want this. Not so much because
choice of what collection API to use is great (as a general
sentiment), more because there are legitimate reasons for why you
want this cf. the GSettings example.
(There's also the concern that GLib is so low in the stack and it's
generally not wise to force too many dogmas on people - e.g. for
D-Bus support, force people into using GPtrArray, GArray, GHashtable
_or_ force people into using GVariant. We also want to be careful
not to paint ourselves into any corners from which we can't escape.)
o I'm worried that GVariant supports a superset of the D-Bus
protocol.
o I don't see any tests cases at all (or am I looking in the wrong
place) - this worries me.
o I don't really like the name, I don't think it adequately
describes what GVariant is: a serialization format with an API
to access and build the value. So, I'd call it GDBusValue instead
since that really is what it is.
A concrete plan for landing the GVariant (which, as the douche I am, is
referring to as GDBusValue in the following) could be to make it part of
the GDBus work I'm doing
o Probably we'd switch GDBus from using DBusMessage to GDBusValue for
building messages.
- maybe we'd want a dbus_message_demarshal() that didn't validate
the data (since we'd trust GDBusValue for this) or maybe it's not
worth it (most probably is, but profiling would be good here).
o The C API for invoking methods / emitting signals would also accept
G_TYPE_DBUS_VALUE. This, basically, allows you to feed raw D-Bus
messages.
o We'd have a way for the code generator to read an annotation on
whether you'd want e.g. a GHashTable or a GDBusValue for a type
signature a{ss}. Also a command-line switch.
In fact, I was already considering having a boxed type for DBusMessage
so people
Re: GVariant for prez!
Hi,
On Sat, May 2, 2009 at 1:02 PM, David Zeuthen da...@fubar.dk wrote:
o It seems like you (or Simon or both) expect GVariant to be the only
container type in town for C bindings for D-Bus (as per the D-Bus
library bug report). E.g. you expect the C programmers to deal with
a{ss} as a GVariant instead of the more natural type GHashTable.
One thing to consider is whether we can separate the basic building
block pieces from the object system mapping and get the basic building
block stuff (main loop integration, name watching, etc.) into glib on
an earlier schedule... then give plenty of time to bake and iterate
dconf, gvariant, gdbus object mapping.
Just feels like there's a lot more controvery and open questions and
just plain stuff to figure out once we're on the object mapping
level. A lot of work left, and there would be much benefit to getting
some real-world usage of the work, too, before locking it down.
o I don't really like the name, I don't think it adequately
describes what GVariant is: a serialization format with an API
to access and build the value. So, I'd call it GDBusValue instead
since that really is what it is.
GBinaryBlob? GBinaryValue? GDataBlob? GStructuredData?
GSerializedValues? GSerialization?
Repeating what I mentioned earlier, it isn't strictly speaking a dbus
value at the moment... it's both a conceptual superset, and the actual
format is v2/slightly-incompatible.
Long-term it seems like the gvariant intent is to support both dbus,
and the mmap'd file case.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
On Sat, 2009-05-02 at 13:35 -0400, Havoc Pennington wrote:
Hi,
On Sat, May 2, 2009 at 1:02 PM, David Zeuthen da...@fubar.dk wrote:
o It seems like you (or Simon or both) expect GVariant to be the only
container type in town for C bindings for D-Bus (as per the D-Bus
library bug report). E.g. you expect the C programmers to deal with
a{ss} as a GVariant instead of the more natural type GHashTable.
One thing to consider is whether we can separate the basic building
block pieces from the object system mapping and get the basic building
block stuff (main loop integration, name watching, etc.) into glib on
an earlier schedule... then give plenty of time to bake and iterate
dconf, gvariant, gdbus object mapping.
I think that's feasible and sensible - this part is practically baked in
the gdbus branch of glib on git.gnome.org - specifically we are talking
about the GDBusConnection, GBusNameOwner, GBusNameWatcher classes and
the g_bus_[own|unown|watch|unwatch]_name() APIs.
So, basically, someone just needs to sit down and review this part of
the code and then, assuming it gets past review, we can merge it to
master after fixing things up. Then we can continue working on the C
type and object mapping in the gdbus branch.
David
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
