Re: GObject instantiation hopelessly overcomplicated??
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GObject instantiation hopelessly overcomplicated??
- Date: Sun, 18 Jul 2004 16:20:07 +0200 (CEST)
On Sun, 18 Jul 2004, Owen Taylor wrote:
> On Sun, 2004-07-18 at 16:43, Ryan McDougall wrote:
> > This exercise has really made me appreciate just how much GTK+/GNOME
> > need a proper high level language. Its interesting for me to learn about
> > this stuff but 90% of application developers cannot be bother with this
> > much minutiae.
>
> GObject is very hard to reverse-engineer the use from reading the code.
> It's a very flexible toolkit. It's probably a lot easier to figure out
> from reading a library using it like GTK+.
>
> (GTK+ is old, so if you read it's sources pay more attention to widgets
> and objects added recently.)
>
> Also, the other thing to keep in mind is that there really is a
> core usage of GObject and things like base_init, constructors,
> defining fundamental types are elaborations of that core usage.
> You shouldn't introduce them to your readers until they have
> a full understanding of the way that GObject normally is used.
> (I'm not sure *I'm* advanced enough to learn about defining
> new fundamental types yet ;-)
there're really only very few valid applications to creating new
fundamental types. mostly, that feature is interesting for experimenting
with new types before they go into glib (like guint64 used to be).
there are two exceptions i know about.
one is the procedure type used in beast (it kinda mimicks the procedures
from the gimp PDB, but uses the type system for registration) i introduced
a couple years ago. though at this point, i'm not entirely sure the code
really gained a significant advantage from registering procedures with the
type system.
the other is a specific proxy object type used in GLE. it definitely has
it's place within GLE, but then i wouldn't want to turn that into
public API and explain other people how to use it. juggling with two
or three object systems in a code base really isn't fun most of the time
and binds too many brain resources better spend elsewhere ;)
>
> Regards,
> Owen
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]