With 2.20 winding down, I think now would be a good time to talk about what should happen in Glib 2.22.
One thing that has been tossed around for a long time is that it would be really good to have DBus support on the Glib level. This would allow us to move forward with several things in GTK+ that will work much better if they can use DBus: - session support - unique application support A while ago David put forward his work on EggDbus and wrote a very detailed mail [1] with arguments for why it would be very good to have DBus support on the Glib level, why dbus-glib is not good enough, and how his EggDbus bindings work. His approach seemed to be well-received, and I'd like to propose that we take a serious look at integrating EggDbus in GLib 2.22. There is also some work by Ryan Lortie on a Glib-compatible Dbus api called gbus. It is lower-level than EggDbus, and might be suitable as a replacement for libdbus. While I have no clear idea yet how EggDbus and gbus will eventually relate, it is worth pointing out that EggDbus' use of libdbus is an implementation detail that is not exposed in the api, so it would be possible to replace it by something like gbus later on. Of course, assuming we can agree on that having DBus support inside Glib is a good idea, there are still going to be some contentious questions. Let me list some, with possible answers: - Where do we put this ? Inside libgobject (since it is more or less DBus bindings for GObject) or inside libgio (since it uses the GIO async pattern and some utility classes from GIO) or separate ? My proposal: Add it as a separate library, next to (or actually on top of) GObject and GIO. Maybe call it GBus. - What do we do about the added 16bit integer types that are supported by the DBus protocol, but don't have corresponding fundamental types in GObject ? EggDbus currently has fundamental types for them. My proposal: Just add the fundamental types to GObject. It would be odd to ship fundamental types spread over several libraries, and int16 is really not worth fighting against... - What do we do about collections ? EggDbus adds typesafe GObject wrappers around GHashTable and GArray. Other people have grandiose plans to force java/.net style collection interfaces into GObject. My proposal: Dodge the issue by just adding the minimal necessities to GObject: a type for GArray (GHashTable already has one), and an api to associate element type information to arrays and hash tables. When I sat down with David and tried to figure out what the minimal necessities actually are, we came up with the following: GLib GObject g_ptr_array_ref/unref g_ptr_array_set_data g_ptr_array_set_element_free_func G_TYPE_PTR_ARRAY g_ptr_array_set/get_element_type g_array_ref/unref g_array_set_data g_array_get_element_size G_TYPE_ARRAY g_array_set/get_element_type g_array_new_with_type g_hash_table_set/get_key_type g_hash_table_set/get_value_type g_hash_table_new_with_types Comments ? Matthias [1] http://mail.gnome.org/archives/gtk-devel-list/2008-December/msg00059.html _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list