GLE, a first draft

[Tim Janik <timj gimp org>]

hello fellow Gtk hackers out there.

i'm currently putting down my ideas about what the next generation
of GUBI (Gtk+ User Interface Builder) will look like.
there have been certain problems with the current implementation
(at least for me) which i'm going to revert in a complete rewrite.

first i'd like to layout some "Hello World" code, so you will get
an idea of what i'm actually talking about here:

void
MyApp_quit_handler (void)
{
  printf ("Hello-World has been finished\n");
  gtk_main_quit ();
}

int
main (int argc, char **argv)
{
  gtk_init (&argc, &argv);
  gle_init (&argc, &argv);
  
  gle_register_handler ("quit-handler", MyApp_quit_handler, NULL);
  
  gle_build_from_file ("./helloworld.gle");
  
  gtk_main ();
  
  return 0;
}

this would be the actual code you have to *write* to see, let's say
a nice window with background pixmap which shows a frame including
a label that says "Hello World", plus a button (or even a menu) that
you could click on to finish the application.

you might have already stumbled about the gle_init() call, which raises
the question: what is gle?

GLE is to become the Gtk+ Layout Engine, which pretty much describes
what it actually does.
my goal is to simplify application building using the Gtk+ toolkit in
general. the application programmer should only care about writing the
apropriate signal handlers, and the layout can be composed by clicking
and dragging widgets on an application window or editing the widget
tree of a certain window along with modifying the properties of certain
widgets. once a programmer has registered his signal handlers/callback
functions with GLE, he should be able to connect them on the fly to
any widget at will.
if the programmer is in the need to retrive a certain widget pointer
e.g. the widget pointer to the main window, this should be achivable
as simple as a call like window = gle_widget_handle ("MainWindow")
(if he had named it so).

no after you got the basic idea, i think i have to admitt that this
is still pure vapoware, but i expect it to become realized quite
soon, since i'm pretty familiar with Gtk+ on the one hand, and some
stuff needs only be talken over from GUBI at the other hand.

now if you want to start out on some kind of application, you will
create a simle main program like the above, and then you can register
imaginary signal handlers and create the UI. after this you dump the
window descriptions into a file which will then be used as a "Layout
Resource" for further invocations of the program.

GLE itself is meant to be a shared library (released under the LGPL)
which will only provide the window editing and building functions
for your programs.

along with this there can be certain front ends to operate on the widget
tree dump, e.g. a handler function skeleton builder for the previously
"virtually" registered signal hanlders.
let's say you registered a signal hanlder "MyApp_click_hanlder" that has
been connected to a GtkButton::clicked signal, the skeleton builder
will the put out code like:

static void
MyApp_click_hanlder (GtkObject *object,
                     gpointer   func_data)
{
}

or you virtually registered a function named "MyApp_expose_handler" that
you connected to the GtkWidget::expose signal, the outputted skeleton
would look like:

static gint
MyApp_expose_handler (GtkObject *object,
                      GdkEvent  *event,
                      gpointer   func_data)
{
}

according to the signature of the GtkWidget::expose event.

other front ends could for example compress and stringify the widget tree
dump, so that you programmers can stick it right into the data section of
their program, avoiding the need of installing a seperate widget tree
description along with their programs.
also imaginable are front ends that would generate actual code for various
languages which would build the UI without having the application to depend
on GLE, but this would depend on the amount of help that people would be
willing to provide ;)


now for those who are still with me ;) i'm curious about your ideas/demands
on this topic and i'm open to any suggestions/enhancements for the basic
system, that you could come up with.
but, *please* *please* don't make suggestion like "make it look like vTcl"
or "i wanna have it NextStep like", but come up with conrete ideas about
the topic.

now i thank you for your patience and am curious about your comments!


---
ciaoTJ