Re: gtk_type_foreach?

[johannes nada kth se (Johannes Keukelaar)]

//On Tue, 15 Sep 1998, Johannes Keukelaar wrote:
//
//> Hi *,
//> 
//> Is there any reason why there is no gtk_type_foreach function? Something
//> that would call g_hash_table_foreach on type_name_2_type_ht in
//> gtktypeutils.c with a user-supplied function and gpointer data? This 
//> would greatly simplify dynamically type-extensible systems, allowing
//> them to find out which types exist that are derived from some basic 
//> type, for example. (Say, to construct an add-a-new-node menu dynamically.)
//
//walking the internal type names hash table is probably a bad idea, since
//1) you have to redo this after distinct time intervals since new types
//   may have been introduced, and

True.

//2) it would open up the internal data structures of the typing system
//   to the application progarmmer, which would be a _very_ bad idea since

Well, I was thinking of type name (gchar *) and GtkType as arguments. Those are 
not internal-only, so your three next arguments don't apply.

//   a) applications should never mess with that,
//   b) it's of no relevant use to an application since all significant
//      information of a type is exported through the gtktypeutils.h API, and

If the application knows the name or GtkType of a type. It can't find out which 
types exist.

//   c) the type system occasionally relocates this stuff within memory.
//
//a fesible way for applications to gain information about certain existing
//types and types that have yet to be registered would be the
//gtk_type_add_class_hook and gtk_type_foreach_class functions which i
//suggested in an older mail to this list:

Yeah, a hook plus a foreach would be better, then you'd only have to use the 
foreach once, and rely on the hook after that.

//> Date: Mon, 24 Aug 1998 00:37:22 +0200 (CEST)
//> Subject: hook functions (Re: Sound events in Gtk)

Haven't seen that.

//so far, there haven't been any comments on that issue, so i think i'll
//eventually implement what i proposed there.
//
//the GtkTypeBaseClass stuff i suggested in that mail has already been
//implemented in CVS gtk+ as GtkTypeObject and GtkTypeClass structures, 
//since i needed those definitions to start out a new proxy-object
//hierarchy in GLE.
//
//> If there is no such reason (apart from that nobody ever needed one), I'll 
//> volunteer to write one for gtk+1.0.4/5.
//
//gtk+1.0.x is a pure maintenance branch at this point, so API extensions like
//the above will only be implemented for gtk+' devel version.

I understand all that. However, I need it for my application (research 
project), and I'm not willing to spend some of my admittedly scarce time on 
regularly updating my program to a moving target. So using a maintainance 
release is out of the question for me. Once 1.2 comes out, I might consider 
moving to that, if the advantages are significant. I have not heard any 
announcement for when 1.2 is going to be released, though. I don't need it 
_now_, I can work around it for a while longer, but eventually it would be nice.

When is 1.2 going to come out? If that takes too long, I will probably 
implement something for the 1.0 branch. If that could be accepted into the 
mainstream 1.0 branch, I would appreciate that, otherwise, I can always use a 
patched version.

Regards,

Johannes.
--
"Sometimes you just can't be afraid; To wear a different hat;
If Columbus had complied; This old world would still be flat" - Garth Brooks

Self-professed nerd of Mathematics and Computer Science.