Re: Announcing: Project Ridley
- From: Roger Leigh <rleigh whinlatter ukfsn org>
- To: Jonathan Blandford <jrb redhat com>
- Cc: gtk-devel-list gnome org, desktop-devel-list gnome org
- Subject: Re: Announcing: Project Ridley
- Date: Sun, 21 Aug 2005 14:05:58 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan Blandford <jrb redhat com> writes:
> Now that GTK+-2.8.0 is out, the GTK+ team would like to announce Project
> Ridley. [...] To emphasize the 'consolidated platform'
> message, we are considering to call the GTK+ version incorporating the
> results of Project Ridley GTK+-3.0.
Would GLib also be a candidate for this work?
One thing I (as an end developer) would like is for libgobject to be
merged with libglib, so that core GLib types such as GMain,
GIOChannel, GSource etc., could be turned into full-fledged GObjects.
I currently find the split to make some tasks impossible (for example,
I recently wrote a GUnixSignalSource to inject UNIX signals into the
mainloop, but without it being a GObject, I couldn't implement it
completely).
Something else I would also like (but can implement separately
initially) is a GObject-based container library which implements
STL-style container and iterator interfaces. This would allow the
current list/hash/vector etc. types to be implemented as GObjects with
a standardised iterator interface, allowing the use of generic
algorithms etc. This could ultimately also be implemented by
e.g. GtkContainer, GnomeCanvasGroup etc..
Another thing I would be interested as an extension to the above is
specialisation (or rather, restriction) of containers to particular
GTypes. If for example, we had a call such as
GType
g_type_specialise(GType type, ...)
used like this:
g_type_specialise(G_TYPE_HASH_TABLE, G_TYPE_STRING, G_TYPE_BOOLEAN, 0);
this could trigger registration of a new type
"GHashTable<gstring,gboolean>", identical to GHashTable, but would set
e.g. "gtype1" and "gtype2" construction properties on creation which
could be used by the container to implement strict type checks on
contained data (this would need explicit support by GType, though),
i.e. it essentially becomes a call to
g_object_new(G_TYPE_HASH_TABLE,
"gtype1", G_TYPE_STRING,
"gtype2", G_TYPE_BOOLEAN, ...);
Could g_object_newv be hacked to support this sort of thing?
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFDCHw1VcFcaSW/uEgRAuJEAKCr+yaXu6GrKQtLBWYkLWNMRn2eGQCeM0+m
nF6rEKUGY536kopSerePiv8=
=H4VE
-----END PGP SIGNATURE-----
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]