Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet <swilmet gnome org>]

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