Date: Fri, 6 Feb 1998 00:54:47 +0100 (CET)
From: Tim Janik <Tim.Janik@Hamburg.Netsurf.DE>
Reply-To: gtk-list@redhat.com
To: Gtk+ MList <gtk-list@redhat.com>
Subject: [gtk-list] GLE, a first draft
Resent-Date: 5 Feb 1998 23:55:23 -0000
Resent-From: gtk-list@redhat.com
Resent-cc: recipient list not shown: ;

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


Date: Sun, 8 Feb 1998 17:27:46 +0000 (GMT)
From: Tushar Joshi <tjoshi@shell.turtle.net>
To: Tim Janik <Tim.Janik@Hamburg.Netsurf.DE>
Subject: Re: [gtk-list] GLE, a first draft

Hi Tim,
        I read about your idea on the gtk mailing list and although didn;t
follow too much of what you were saying I got the general gist you were
designing a gubi tool which is uptodate. Ok so now I'm passing on my ideas
:) (idea)

In my gtk applications I write template gui's which have no details on
what actually is in the interface but knows how to construct them. Like
it knows to take a structure which has certain attributes about the window
layout. Eg. It takes in an array of strings and for each of those strings
it makes an entry box and a label beside it with the same name. This was I
only need send to the template different arrays of stings to return to me
a pointer to the window with these entry boxes and labels. The template c
function will for each string in the array will dynamically allocate the
pointers to the widgets.

This is useful so I do not have to have large chunks of code in which I
hard code all the details , it's all configurable from seperate text
files which load the data and pass it on to the template files. I don;t
know if this idea is of any use to you but maybe if you were to design
something in the way of template gtk c files which took in a structure to
all the arrays of strings/int that described the interface that way you
could change the details within the template without having to edit the c
code. This is probably mainly only useful for people who use the same
layout with different names/labels buttons. I hope I explained as best as
I could the template idea, maybe it'll help you maybe not :o)

Thanks,

Tusha

                          - Tushar Joshi -

Date: 06 Feb 1998 22:47:45 -0700
From: Tom Tromey <tromey@creche.cygnus.com>
Reply-To: tromey@cygnus.com
To: Tim Janik <timj@gimp.org>
Cc: Hacking Gnomes <Gnome-Hackers@athena.nuclecu.unam.mx>
Subject: Re: GLE, a first draft (fwd)

Tim> GLE is to become the Gtk+ Layout Engine, which pretty much
Tim> describes what it actually does.

Didn't some old Motif GUI builder have a similar idea in it?  Does
anybody know why it failed?  It would be good to avoid their mistakes.


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

Here are a few concerns/thoughts of mine:

1. If GLE becomes too complicated, it will become a scripting
   language.  That would be a disaster.  In this case it would be
   better to just give in and use one from the beginning.
   (Maybe it won't happen -- but you must be diligent!)

2. GLE files should probably be some ASCII format, so that they can be
   more easily checked in.  (Binary formats lose with cvs+branches)
   Ideally one of two things would hold:
    a. A GLE file would be clear enough that a programmer could
       resolve conflicts by hand.
    b. GUBI could detect and somehow let the user visually merge
       cvs conflicts (this would be super cool)

3. It would be nice if you could use GUBI to build composite widgets,
   and not just applications.

4. GLE -> <your language here> compilers are a must.  Otherwise, GLE
   is just a funny way of writing C.  Probably just one example of how
   to hook up some other language would suffice.

5. To use an analogy, it would be good if GUBI worked more like an
   SGML editor and less like Word.  For example, in an old project I
   once had to change the layout of every button bar at the bottom of
   every dialog.  What if GUBI could do this for me?

6. It would be nice if I could set up GUBI so that by default my
   layouts were compliant with some style guide.  This is sort of a
   combination of #3 and #5, with perhaps a bit of extensibility
   added as well.

Good luck,
Tom

Date: Sat, 7 Feb 1998 17:02:59 +0000 (GMT)
From: Alan Cox <alan@cymru.net>
To: tromey@cygnus.com
Cc: timj@gimp.org, Gnome-Hackers@athena.nuclecu.unam.mx
Subject: Re: GLE, a first draft (fwd)

> 4. GLE -> <your language here> compilers are a must.  Otherwise, GLE
>    is just a funny way of writing C.  Probably just one example of how
>    to hook up some other language would suffice.

This one alone avoids almost all the other problems. It doesnt matterwhat
GLE turns into if you adjust the layout and push the "make it C" button
then ship the C

Date: Tue, 10 Feb 1998 01:52:22 +0100
From: Luca Olivetti <luca@luca.ddns.org>
To: Tim Janik <timj@gimp.org>
Subject: Re: GLE, a first draft 

> 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.

Well, since you haven't mentioned it, I suppose I can say "please make it like 
delphi!" ;-)

Seriously, I think I can make a little bit of delphi advocacy, since most of 
its design is very similar to what you are proposing, but I don't really know 
how it could fit with gtk.

Anyway:

In delphi classes (and object) objects are essentially records in which you 
defines fields and methods.
Some fields are accessible only from inside the class (private members). 
Others are declared as "property", which are means to access internal fields 
from the outside in a controlled manner (i.e. through get/set functions, much 
like the javabeans specification).
Besides giving access to private fields from the outside, properties have two 
other useful uses:
1) in design mode the environment can examine the properties, so it can build 
an "object inspector", to allow the programmer to modify such properties (i.e. 
a label could have a font property and a text property)
2) property that are different from the default value are saved in what you 
call a gle file, which in delphi is called a "delphi form file" (dfm)

The dfm is a binary format, but you can convert it to text if you like, and it 
is just a definition of the widget tree[1] with values that are different from 
the defaults.
Something like (mind me, from memory, I don't do delphi at home ;-)
(indentation indicates parent-child relationship)

tform MyForm
Top: 100
Left: 200
BorderIcons: [minimize,maximize];

     tpanel Panel1
     Bevel: raised
     Align: left
     Width: 50;

         tlabel label1
         text: "Hi there"
         OnClick: Label1Click;

         tbutton button1
         width: 20
         height: 20 
         text: "Exit"
         OnClick: Button1Click
         ToolTip: "click to exit";

     tpanel Panel2
     align: client

        tCompanyLogo: Logo
        align: client;
        


This describes a form with two panels.
The left panel holds a label and a button, and the right panel contains a 
custom component (a subclassed imaged which contains a company logo by 
default).
An event handler (the OnClick above) is just a special case of property: the 
type of this property is just a function pointer.

[1] a widget is a component in delphi, and it can be visual (a table, a label, 
a button) or non visual (a timer, a database access object)

At design time you drag objects from a toolbar to the form. Delphi then 
generates a source code template with the declaration of the objects you put 
on screen, so you can use them in the code:

    Type tmyform = class(tform)
    public 
       Panel1: tPanel;
       label1: tLabel;
       button1: tButton;
       Panel2: tPanel;
       Logo: tCompanyLogo;
       procedure label1click(sender: tobject; x,y:integer);
       procedure button1click(sender: tobject; x,y:integer);       
    private  
      { private declarations }
    published
      { published declarations }
    end;

    var myform:tmyform;  
 
You click on properties on the object inspector and you can modify them.
You double click on an "event" property and a template for the correct type of 
function is placed in the source file.
Each kind of property have the appropriate editor, based on its type: a 
"string" property will have a text entry box, a "font" property will have a 
font selection dialog and so on.

On the toolbar you can install components you have defined yourself (delphi 
will know how to build an object inspector for your object based on its 
properties) and you can register specialized editors for the custom types you 
defines (i.e. a calendar to pick up a date for a "date" type property), but if 
you fail to do so delphi will chose the best matching existing editor (for the 
date field it would be a floating point entry box - delphi stores dates in 
floating point).

Obviously Borland could achieve this tight integration between the language 
and the design time environment because they could bend the language to 
introduce the keywords the wanted (i.e. "property" is a compiler supported 
keyword, and it has nothing to do with standard pascal).

On the other hand, the same concepts could be applied to other languages (they 
do that in java with a strict naming convention, eg. the field "font" is 
accessed through the functions "getfont" and "setfont", so the design 
environments looks for functions named "set" and "get" to know the properties 
from the rest).

The other big advantage of delphi is the speed of the compiler: when you test 
the interface, delphi is not simulating it, it has just compiled your code and 
that's what's running (this is a reason why many people take delphi as a VB 
clone: you simply hardly notice the delay when you press the "run" button).

I hope my ramblings about delphi features did not annoy you.

-- 
Luca Olivetti             | Tarifa Plana ya! http://tarifaplana.home.ml.org/
http://www.luca.ddns.org/ | FAQ    http://www.luca.ddns.org/ptp-faq.html
----------------------------------------------------------------------------
PGP key on servers - see http://www.pgp.net/pgpnet/
----------------------------------------------------------------------------
You can't carve your way to success without cutting remarks.


