Re: GTK+ brochure for FOSDEM

[Sébastien Wilmet <swilmet gnome org>]

On Fri, Jan 23, 2015 at 06:18:02PM +0000, Alberto Ruiz wrote:
> I don't see much of a debate there. Most people want to solve a problem,
> and start from the problem, not from the tool to solve it

That's why the brochure begins by an introduction to GTK+ and an
architecture overview.

> People who are likely to use GTK will start from the problem they want to
> solve and are in need for a graphical toolkit to draw widgets that do what
> they want.

Exactly. People who use GTK+ applications already know what is possible
to do with GTK+. Or if they use KDE or Windows or whatever, the
applications and the desktop are the visible part that they already
understand well. You just need to say "you can do that with GTK+".

On the other hand, what happens under the hood isn't obvious, and can be
interesting (e.g. for a CS student) even if the person doesn't want to
write a GTK+ app.

At FOSDEM there are some Belgian students (like me several years ago)
that traverse every stand and take as many things as possible, be it
stickers, brochures, pens, etc. I have that public in mind too. Imagine
a young student who reads the GTK+ brochure, and then several years
later he/she wants to write a daemon, ideally the student will remember
the brochure about GLib/GObject and event-driven programming and will
start learning GLib!

> Point them at what the toolkit does and the easiest way to use it,
> and people will learn as they go. GObject and GIO by themselves are of no
> interest for most people wanting to write apps, specially in C.

Uh, it's quite the contrary IMHO. If a developer chooses the C language
and wants to write a GTK+ application, it's advised to write GObject
classes to have a good code architecture. Look at gedit for instance,
it's full of GObject classes. You create a subclass of GtkApplication, a
subclass of GtkWindow for your main window, subclasses of GtkGrid or
GtkBox for some other components that you have in your application, etc.
Without GObject, you can write structs, allocate them and pass a pointer
as the self argument, but GObject is much more powerful. It's
interesting to create signals for example.

For developers who choose a higher-level language, knowing the basis of
GObject is useful too: what is a GObject signal, what is a property, "oh
there is actually an object hierarchy and I can call a function from the
parent class", etc.


Sébastien