On Jan 23, 2015 12:06 PM, "Sébastien Wilmet" <swilmet gnome org> wrote:
>
> 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!
That seems like an extremely bizarre and specific use case to optimize for, especially given that GLib's event loop isn't that well designed for server scenarios. They'd be better served by libev / libevent.
> > 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
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list