[glade--]glademm and libglademm, was Re: [gtkmm] Re: gtkmm should support GtkPixmap (bug #82381)

[Christof Petig <christof petig-baender de>]

Bryan W. Headley wrote:
> Christof Petig wrote:
>
> > Jarek Dukat wrote:
> >
> >
> >
> > I simply don't like a program to modidy _my_ source code. And nobody 
> > has writen a merge program which appends _missing_ declarations into 
> > the .cc and .hh / .h file. Any volunteers? I simply don't miss it.
>
> No, but there are ways to avoid it. The callback object, say 
> "mainWindow", should be nothing but virtual methods. A mainWindowLogic 
> class (and file is created, but never overwritten) where you stick in 
> your implementations of the callbacks.

That's really near to the current solution used by glade--:

The foo_glade class holds the ctor (widget creation and customization, 
connection of callbacks) and the dtor (non managed widgets' deletion).

The foo class holds the user-defined callbacks (and their declaration). 
This file is initially created and then never touched (though completed 
versions go to the _new files).

If you still think that glademm is far away from what you described, I 
misunderstood you. So please expain further if this is the case.

--- interesting idea: ---

1) Defining empty (or containing a return 0;) virtual methods in the 
foo_glade class would make it unnecessary for people to extend their 
user class unless they really want to do something in the callback.

2) Defining pure virtual functions (=0) would force the user to declare 
and define them to get it compiled. That's similar to the current 
situation but the compiler errors point directly to the problem (missing 
method).

3) Declaring the functions in the foo_glade class but defining them in 
the user file is perhaps not a good idea since these methods can not 
access the user's data.

--------------------------

Drawback: virtual functions have a (relatively small) cost.

What do you think?

> That gets rid of everything except any customizations you might do the 
> projects "main" file. E.g., global variables (ugh!) and initializing 
> toolkits. Of course, main() can have a call to initializeSingletons( 
> argc, argv), and globals/startup code be moved to the file that has 
> initializeSingletons() in it...

Isn't that like the current situation of glade-- generated code?

> Actually, I'd like to see if someone has a glade file with all widget 
> types in it, and the corresponding .cc/.hh files to "talk" to same via 
> libglademm. The example program looks easy enough to base a codegen 
> around, but all that's there is an entry and a button. And a callback 
> that's not specifically called for in the glade file (onClick). 

Glade-- comes with a lot of test files which test code generation for a 
lot of widgets. (See the test directory)

> glade--
> has the beginnings of a codegen for libglademm, why not finish it?

Because there are two things which I would like to get done before 
supporting a libglademm skeleton generator (besides my daily work):

- Glademm has the concept of associated user classes (per widget tree) 
which hold all callbacks and customization (via the ctor). Libglade does 
not have this. And libglademm did not have this concept the last time I 
looked at it. It should have the ability to pass the object to the 
callbacks. Shouldn't this fundamental OO concept make libglademm 
programmers' lifes easier? I can't imagine how they do without it.

- Glademm has the concept of dividing large widget trees into smaller 
sub classes (separate class). Libglademm does not have it, yet. But to 
get a real substitute for glademm's code it needs support for it.

Once these issues are resolved it would be a pleasure to make glademm 
emit a libglademm skeleton or a standalone version of the program which 
would share the user code. I planned to resolve them myself some time 
ago but didn't find the time.

Perhaps Murray (libglademm maintainer) has more ideas on this. If we 
need code to illustrate the concept I'd happily provide it. Simply ask.

This would enable users of glademm and libglademm to produce statically 
(gtkmm code) or dynamically (libglade) generated versions of their 
programs up to their choice (and a command line parameter). I would love 
to have this choice (this is why the coding has started)!

    Christof

But: My current TODO list for glademm is full gtkmm2 support within a 
few days. So my ressources are limited.