On Fri, Jan 23, 2015 at 01:38:05PM -0500, Paul Davis wrote: > Writing GObject classes is not typically something that application > developers will do.
There are many apps in GNOME, written in C, full of GObject classes. Look at gedit for instance. By reading the answers of this thread, it seems that GObject should be something we should hide to newcomers because it's a bit painful to use. It's indeed a bit painful, but I hope that some better tools will exist in the near future (Builder) to create, rename, refactor GObjects while still keeping a good indentation, to format the function prototypes and headers automatically, completion of signal and property names, static-analysis tools to detect if a signal callback has a wrong prototype, less boilerplate code (GProperty, signals? syntactic sugar?), and I probably forget other things. It's a bit off-topic, but maybe if GObject was created with only the C language in mind, everybody would be happy with C/GObject. But since GObject was created with bindings in mind, it's a bit more painful in C. But it has the advantage that if one day there exists a wonderful high-level language, someone "just" needs to write good GObject introspection support, and suddenly millions of lines of GObject code can be used in the high-level language. Supposing that the binding support is really stable and that API documentation targetting the high-level language is available, there is still a potential problem: the exposed API can be weird to use in the high-level language because it doesn't use all the features of that language. So ideally you need to write a wrapper for each library (a bit like the *-glib wrappers to GObjectify some libraries). This last thing really happens, for example one reason why the MonoDevelop developers have written another text widget in C# is because GtkTextView had a weird API in C# (but some can argue that it's also the case in C :-). Sébastien _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
