Compiling the girepository.h header with C++
When I built a mixed C/C++ program, I had a couple of problems with the argument names used in functions in the girepository.h header. There were args called 'namespace' and 'type-info' and I changed them to 'gnamespace' and 'gtype-info' respectively. Please find a patch attached. regards -- Richard Dale Index: girepository.h === --- girepository.h (revision 1093) +++ girepository.h (working copy) @@ -83,32 +83,32 @@ GIRepositoryLoadFlags flags, GError **error); gboolean g_irepository_is_registered (GIRepository *repository, - const gchar *namespace, + const gchar *gnamespace, const gchar *version); GIBaseInfo * g_irepository_find_by_name (GIRepository *repository, - const gchar *namespace, + const gchar *gnamespace, const gchar *name); GTypelib *g_irepository_require (GIRepository *repository, - const gchar *namespace, + const gchar *gnamespace, const gchar *version, GIRepositoryLoadFlags flags, GError **error); gchar ** g_irepository_get_dependencies (GIRepository *repository, - const gchar *namespace); + const gchar *gnamespace); gchar ** g_irepository_get_loaded_namespaces (GIRepository *repository); GIBaseInfo * g_irepository_find_by_gtype (GIRepository *repository, GType gtype); gint g_irepository_get_n_infos (GIRepository *repository, - const gchar *namespace); + const gchar *gnamespace); GIBaseInfo * g_irepository_get_info (GIRepository *repository, - const gchar *namespace, + const gchar *gnamespace, gint index); const gchar * g_irepository_get_typelib_path (GIRepository *repository, - const gchar *namespace); + const gchar *gnamespace); const gchar * g_irepository_get_shared_library (GIRepository *repository, - const gchar *namespace); + const gchar *gnamespace); const gchar * g_irepository_get_version (GIRepository *repository, - const gchar *namespace); + const gchar *gnamespace); GOptionGroup * g_irepository_get_option_group (void); ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Compiling the girepository.h header with C++
Hi Richard, 2009/2/10 Richard Dale : > When I built a mixed C/C++ program, I had a couple of problems with the > argument names used in functions in the girepository.h header. There were args > called 'namespace' and 'type-info' and I changed them to 'gnamespace' and > 'gtype-info' respectively. Please find a patch attached. Thanks for the patch, but usually the right place for this is: http://bugzilla.gnome.org/ -> Product: glib, Component: introspection Perhaps just ns or nsname instead of gnamespace? Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Working on 119189 this weekend
(Sorry for the lack of progress this weekend. The youngest was feeling ill this weekend and in the ER on Saturday night. Made for difficulty finding time to poke at this.) Hey there Kevin, Yes, there are a couple of projects to create gtk+ widgets with OpenGL contexts. GtkGLExt is one of them. The first gtk+ project I did with OpenGL was initially done using GtkGLExt. This library can be used to add an OpenGL rendering context to any widget, blessing it as a drawing surface. In contrast, the GtkGLArea aproach creates a widget with the express purpose of being an OpenGL drawing surface. It is a widget class which derives from GtkDrawingArea and has a few additional methods, in particular gtk_gl_area_make_current, which attaches the underlying OpenGL rendering context to the drawing area, and gtk_gl_area_swap_buffers, which performs the OpenGL front/back buffer swap. http://svn.gnome.org/svn/gtkglarea/trunk/gtkgl/gtkglarea.h http://svn.gnome.org/svn/gtkglarea/trunk/gtkgl/gtkglarea.c The heavy lifting is offloaded to the GdkGLContext class, which implements the windowing-system-specific OpenGL context functionality. http://svn.gnome.org/svn/gtkglarea/trunk/gtkgl/gdkgl.h http://svn.gnome.org/svn/gtkglarea/trunk/gtkgl/gdkgl.c My hope is to merge this code into the gtk+ module. If I find enough time to put something together, I'll submit the patch here. It sounds like the core developers don't feel that the widget is general-purpose enough to be accepted. It also seems there is concern that OpenGL is not ubiquitous enough that such a widget would be available on all platforms. But let's see how it goes :) Cheers, C.J. On Thu, Feb 05, 2009 at 04:50:27PM -0800, Fox, Kevin M wrote: > Hi C.J, > > Correct me if I'm wrong, but I thought something like this was already > done. GtkGLext > > http://www.k-3d.org/gtkglext/Main_Page > > Kevin > > -Original Message- > From: gtk-devel-list-boun...@gnome.org > [mailto:gtk-devel-list-boun...@gnome.org] On Behalf Of C.J. > Adams-Collier > Sent: Thursday, February 05, 2009 4:04 PM > To: gtk-devel-list@gnome.org > Subject: Working on 119189 this weekend > > Hey all, > > I'm planning some time to work on 119189 this weekend. I'm going to see > if I can put together a patch to add gtkgl.c and friends into gtk. > > http://bugzilla.gnome.org/show_bug.cgi?id=119189 > > Behdad has suggested (and correct me if I've got this wrong, Behdad) > that he feels that instead of creating a dedicated OpenGL drawing widget > (similar to GtkDrawingArea), it would be better to add a method to the > API which allows a widget to be imbued with the ability to have OpenGL > primitives drawn to it. > > What are your thoughts? > > Cheers, > > C.J. signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Compiling the girepository.h header with C++
Am Dienstag, den 10.02.2009, 18:33 -0200 schrieb Johan Dahlin: > Hi Richard, > > 2009/2/10 Richard Dale : > > When I built a mixed C/C++ program, I had a couple of problems with the > > argument names used in functions in the girepository.h header. There were > > args > > called 'namespace' and 'type-info' and I changed them to 'gnamespace' and > > 'gtype-info' respectively. Please find a patch attached. > > Thanks for the patch, but usually the right place for this is: > > http://bugzilla.gnome.org/ -> Product: glib, Component: introspection > > Perhaps just ns or nsname instead of gnamespace? Well, those abbreviations are common in XML world, but each time I read them I wonder what XML has to do with National Socialism. Well, but guess that's only a problem affecting Germans. Ciao, Mathias -- Mathias Hasselmann 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
GLib plans for the next cycle
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
