Re: RFC: Gtk + XML chroming



> I was looking at doing something similar to this, but using GLADE's XML
> file format as the base.  The reason for choosing this file format is that
> there is already a GUI builder for it.

Well, I wouldn't be so quick in choosing that - after taking a look
at glade's format, it does seem good for a GUI builder but however
not so nice for authoring by hand.

The thing I like about the format I proposed is that it's pretty terse
in terms of length - it's not difficult to write a simple application
by hand.

One of the really nice things about XML is how easy it is to convert
different formats to each other - I could whip up a Perl script in half
an hour to go both ways between my format and glade format.

I guess I'll have to come up with a more convincing demonstration than
the 90-line directory browser to show what I mean, like the XML editor
I hinted towards.

> My ideas for the interface so far have been similar to Miguel's.  I was
> also planning on using gmodule to automatically connect signal handlers
> like this:
>   GModule *self = g_module_open(NULL, 0); /* look at executable's symbols*/
>   gpointer handler
>   if (!g_module_symbol(self, sig_handler_name, &handler))
>     g_warning("couldn't find signal handler %s", sig_handler_name);
>   else
>     gtk_signal_connect(object, "signal", GTK_SIGNAL_FUNC(handler), NULL);
> 
> Of course this functionality would be optional, so the code would be
> useful to people who use OS's not supported by gmodule.

But wouldn't it be just more useful to export the necessary symbols as CORBA
methods or something? Or alternatively by a macro

	static SignalFunction export_handlers[] = {
		{"xxx", my_xxx_handler},
		{...}
	};

This way it wouldn't need to be dependent on gmodule support. Optional
functionality is often a bad thing - XML is nice because there is none.

	Tuomas



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]