Re: GSignal stubs? (Re: GObject adaptor comments (GEP 5).)

[Michael Meeks <michael ximian com>]

Hi Tim,

On Tue, 2002-10-29 at 02:57, Tim Janik wrote:
> read into this email mostly by accident, and felt like commenting ;)

	Great; I imagine I CC'd you though - so ...

> right, but what exactly are you envisioning? specially with regards
> "fixing" GSignal.

	Ok: so, there is no benefit in having a block of signals separated in
the epv by non-signals [AFAICS], ie. we can lump them together
contiguously, so we can have signal IDL that is:

<IDL>
foo_keyword GtkWidget {
	VOID realize   (OBJECT:INT:LONG:SHORT:FAT:UGLY);
	VOID unrealize (OBJECT:STRING);
	...
};
</IDL>

	(it seems glib likes to use upper case for type names for reasons
unknown);
	
	So - having got this IDL you compile it to two things:

<IDL generated>
	typedef struct {
		void realize   (GtkWidget *, int, long, short, fat, ugly);
		void unrealize (GtkWidget *, char *);
		...
	} GtkWidgetSignals;
</IDL generated>

	with of course some (IDL) expansion options all around for the various
GSignal options, pointer types, etc. etc. In the GtkWidget header you
do:

<C header using generated IDL structure>
typedef struct {
	GtkObjectClass parent;

	void foo_virtual_method (GtkWidget *widget, ...);
	...

	GtkWidgetSignals signal_block;
	
} GtkWidgetClass;
</C header using generated IDL structure>

	Then of course; you have a -common.c file which contains a runtime
readable description of the same thing in a structure pointed to by:
gtk_widget_signal_info;

	Then instead of this interminable typing of all the signal additions
into the source you do:

<C source using generated data>
	gtk_widget_signals_add (
		G_STRUCT_OFFFSET (GtkWidgteClass, signal_block),
		gtk_widget_signal_info);
</C source using generated data>

	ie. 1 line instead of the (currently): ~500 lines of code doing the
same thing in GtkWidget.

	Now of course - there is the accumulator issue - so you'd perhaps want:

	gtk_widget_signals_add_full (
		... _gtk_boolean_handled_accumulator);

	which would up the line count to ~ 10 lines instead of 5 but ...

	Once you have that concept too - it might be considered that 40 lines
of this:

  gtk_widget_class_install_style_property (klass,
					   g_param_spec_boolean ("interior_focus",
								 _("Interior Focus"),
								 _("Whether to draw the focus indicator inside widgets"),
								 TRUE,
								 G_PARAM_READABLE));

	could also go in the 'IDL' file [ for a presumably considerable size
saving on all that bogus stack build / unwind that goes on in the
compiled version of that ]. Similarly, g_object_class_install_property
has always seemed unnecessarily verbose to me.

	Clearly there is an i18n issue with the descriptions, but
xml-i18n-tools seems to have adapted to such things admirably; and I
imagine glib can manage to ensure that a few strings in an object
description get into the .po file.

	Really - my feeling is that if we auto-generate these things from a
separate file we have the following benefits:

	* description file is authoritative
	* code is overall smaller, faster
	* a signature is typed only once vs. 3 times:
		+ header file
		+ marshaller decl.
		+ argument specifiers
		+ .defs file (?)

	Of course - we also split code into 2 different places (.c|.idl) ( in
place of the existing 2 .[ch] ) so ... of course compatibility wise -
it'd not be that possible to do this, without some hacks; simply because
you don't want to be typing out your signal stuff in the same way that
GtkWidgetClass (eg.) does.

>  as things stand, GSignal supports most any feature
> you'd want for signal emissions, so you're probably more aiming at
> convenience and/or type-safety. but those issues can be fixed on top
> of what GSignal provides, i.e. it's a matter of someone implementing
> additional code.

	Quite - I don't recollect suggesting otherwise.

> in fact, stefan is currently working on something like this in a BEAST
> specifc IDL parser, i.e. generate stubs which ensure typesafety upon
> signal creation and emission in statically typed languages (C/C++). but
> that only works in an GOB-like environment where you have:
>
> 1) object code generation utilities
> 2) custom IDL or a similar thing being the primary source for your object
>    and signal interface descriptions, rather than hand crufted C code
>    like in the above quote.

	I think GOB-like has to be the ultimate swear-word ;-) I don't think
you need to start writing your own language / source pre-processor -
simply to generate useful more useful data than we currently do with
glib-genwhatever. I propose essentially exactly the same model, but used
more effectively.

> IIUC, the only generated code (1) used in bonobo is produced by ORBit (modulo
> minor things like mkenums, or genmarshal), which implements CORBA IDL, which
> in turn doesn't provide means to describe GSignals in the IDL files.
> so what is your idea for approaching (2) for bonobo or user code then?

	Oh - sure; so - we can't re-use the ORB code here; again really due to
type issues more than anything; Then again - if we had a signal
marshaller that did the raw guts of what we both want to do:

	invoke (MethodDescription, &ret, arg_array) -> C method call.

	In such a way that we could re-use it sensibly then we could share
that; I fear that the type system disparity is not going to help us;
indeed - but the ORBit2 way is sufficiently low level that we could
possible make Glib stubs use that; but then we've enforced the Object,
args, Environment invariant on our stuff (so far) which militates agains
that (perhaps).

	Anyhow - the idea was more about making GSignal's easier to use, based
on a similar model to that used in the ORB,

	HTH,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot