[glade--]Re: Glade-- Two questions

[Christof Petig <christof petig-baender de>]

Bryan W. Headley wrote:
> Christof Petig wrote:
>
> > Bryan W. Headley wrote:
> >
> > > Christof,
> > No both executables will be the same. Actually I read both styles of 
> > files and emit code according to available Gtkmm2/Gtk-- Version or 
> > command line parameters. And according to renaming, perhaps I will 
> > call it glademm (reason see gtkmm) and rethink about the name of the 
> > executable (since glade calls it as glade-- there is reason to not 
> > switch).
> Not really. An orthogonal thinker will make a glade-- package using the 
> Gnome-1 source tree/version, and then a glade-- package using the 
> current source tree/version. The Debian packagers are beginning to 
> understand that they need one of each package to continue to support 
> Gnome-1 (which they'll do for awhile). Glade-- so far is the only 
> package that maintains Gnome-1 support.

But it's more than handy to just work out of the box for both 
environments. So you can even create code for 1.2 in a 2.0 environment 
and vice versa. I usually have them both installed. glademm-1.1.0 simply 
will support both glade and glade-2 and both of gtk-- and gtkmm-2 (Note: 
four combinations!!!). No branch, no fork, from a user standpoint I 
can't envision a better solution. Most user's won't notice (unless glade 
magically starts generating gtkmm-2 code once they install it in their 
path, which IMHO is not so undesirable). Perhaps a glademm-1 link should 
default to 1.2?
I'd vote for letting it die really fast.

I can understand the glademm-2 point of view, but supporting both in one 
binary (note: glademm does never link to lib(gtk/glib/gnome).so) makes 
transition of projects much easier.

> Anyway, you know the user will install the packages in the wrong order, 
> and end up with the Gnome-1 only Glade--. dpkg won't help them, because 
> the dependencies will be met, whichever order the packages are installed 
> in.
>
> Not just Debian, but the rpm guys and other packagers.

And if I just don't mention? They will upgrade glademm-0.6.4 by 
glademm-1.1.0 which still supports 1.2.

The problem already existed back in the gtkmm-0.99/gtkmm-1.0/gtkmm-1.2 
days. Glademm naturally supported generating code for them all.

> > Actually IIRC toolbar handles it's children itself. So the code is 
> > inside toolbar (and not button). Whether this was a good decision is 
> > debatable but it looks good to have toolbar specific code inside 
> > toolbar. IIRC the generated gtkmm code uses a lot of Toolbar_Helpers 
> > functions which have not too much in common with normal button 
> > creation API.
>
> Hmm. They're leaking into Widget::check4validity(). 

Wasn't this to support placeholders?

> If you saw my patch, 
> I made special writers for them.

Which did not differ from button.cc/radiobutton.cc/checkbutton.cc. 
Please test my solution, it should be equivalent without duplicating code.

> If toolbar children were guaranteed to only be button, checkbutton, 
> togglebutton, you are okay. But glade allows you to "convert to regular 
> widget", which means you'll see "GtkButton" et al. Actually, for fun, I 
> found that GtkEntry and other useful widgets can appear up there. Too 
> many exceptions...

This work(ed) for gtk-1.2 and was sometimes used. I don't see any 
relationship to supporting '*button'. Please tell me more. What does not 
work now?

   Christof