Karl Nelson wrote:
> >
> > IIRC there are at least three code generators. One author of another
> > contacted me quite recently to discuss a bit: Matt Goodall
> > <[EMAIL PROTECTED]>
>
> I think that the approach used by glade-- may be part of the problem.
> Please don't take this the wrong way, but the Gtk-- crew did virtually
> the same thing with Gtk-- when trying to wrap gtk+. We started
> by writing out all the methods of gtk+ by hand and coding the wrapper
> for them. This took forever and was very unmaintainable.
It has not been a problem for me up to now, since search and replace can get
automated by sed ;-)
Though the main reason for this is that I myself don't master m4, perl or
python. I simply didn't need them so far (Though I studied their concepts).
> I studied through glade-- over the weekend and concluded that everything
> under src/writers could be reducted to a common set of patterns.
> These patterns could easily be generated with m4 or even just a
> widget decription file. I think as soon as glade is partially working
> it should be released and then break the patterns down and
> replace all the writers files with short macro files. This
> would allow functions to get added quickly and easily, and for
> changes to be made throughout every one of the wrapper to be
> made by changing just the pattern file. I don't know how many
> years it would have taken to wrap Gtk-- without writting a
> powerful code generator.
I agree. Noted for future thinking.
Also, please consider that glade-- 0.5 does not cover glade-- 0.2's full
functionality, yet. A lot of functions do not contain code yet.
> > > Also, gladecc's approach is really interesting, as indeed experience
> > > shows that creating a datamember per object in a compound widget is
> > > most of the time not a good idea.
> >
> > Agreed. This is on my TODO and had partially been done (visibility etc).
> > Though I had not fully looked into your (gtk--'s) automatic destruction
> > mechanisms.
>
> Although I like the idea of creating only a top level widget,
> I am a little afraid of "all the signals are sent to that class(
> like form in delphi)". It seems to me that it is better just to
> name all the visible member in the toplevel class as pointers (or
> embedded) and then let the user choose what signals to connect to.
> Pointers are easier than embedded here because the code generator
> chooses timing of the initializations.
Agreed. Some widgets even don't work embedded (e.g. Spinbutton, it's easier
to create the Adjustment before the Spinbutton). The user can specify
subtrees to form a class of their own (e.g. split the pages of a notebook
into seperate pieces (classes) with seperate signal contexts).
And you might chose to connect by hand by looking up the widgets in the map
(glade-- 0.5 generates strong typed macros). [Simply mark these widgets
public.]
> Our mechanism is just a port of the gtk+ one. The function
> manage takes a dynamically allocated piece of memory and tells
> it to use the gtk+ reference counters. It would be as simple
> as
>
> Gtk_Button *button=manage(new Gtk_Button());
>
> Then just add it to a gtk+ class and forget about it.
Thank you for this introduction. Is this also part of gtk--1.0?
> Are any of the code generators working on Gtk-- 1.1 yet?
I didn't even look at it, yet. But given the much more modular code of
glade-- 0.5 it should be not too difficult to code. (famous last words ...)
Christof
+---------------------------------------------------------------------+
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the line "unsubscribe glade-devel" in the body of the message.
