Re: [glade--]Re: Gnomemm-2 support in glade--

[Christof Petig <christof petig-baender de>]

Peter Wainwright wrote:
> On Mon, 2002-11-04 at 11:55, Christof Petig wrote:
>
> > Hi Peter,
> >
> > perhaps I should express my opinion on a GNOME1 and a GNOME2 macro (see 
> > GTKMM1 in Configuration.hh). I'd like to see the switch replaced by a if 
> > (GNOME1). This is
> > - much less overhead (read: characters to type/read)
> > - much more readable
> > since we only have to support 2 versions.
> >
> > Would you mind to remove the environment variable? Or do you still see a 
> > need for it (given my explanations on which version to select).
> >
> > Yours
> >   Christof
>
>
> Dear Christof and all on glademm-list,
>
> Still hacking on Gnome2 / glademm...
> I downloaded the CVS on 16th November, and applied my latest patches.
>
> I have a number of things to suggest. Forgive me if I have
> misunderstood your design...
>
> (0) When you replaced the switch() with if() in Cxx.cc, you overlooked
> the break; at the end of the default section... This breaks the
> Gnome 1 code generation.

Sorry. Thanks.

> (1) In configure.in, I test separately for the versions of the GTK,
> GTK2, Gnome, Gnome2, and Bonobo libraries. I expect most developers
> will have for some time parallel installations of Gnome 1 and 2, and
> may need to develop Gnome1 applications for backward compatibility;
> what is detected on the developer's system may have little in common
> with the platform where the generated code is to run.
>
> (2) I've gone with your single gnome2 flag and GNOME2 macro. Also I
> agree it's reasonable to set gnome2 by default if a Glade 2 file is
> read. But for the reason set out in (1), I think the GNOME1/GNOME2
> macros should test the Configuration.gnome2 flag, rather than looking
> at package versions.

Looking at package versions was chosen for historical reasons ... during 
development of gtkmm/gnomemm often things broke and I had to work around 
specific bugs in specific versions. These days I tend to tell the people 
to upgrade to the newest version. Also this allows a finer distinction 
for future developments.

Please not that the Configuration.gnome2 flag is set first (depending on 
command line switches and glade version used) and then only the matching 
version is probed. So gnome2 has direct influence on the gnome version 
found.

I did not add a --gnome1 switch yet (to allow glade2 users generate 
gnome1 software) since I thought this unnecessary.

> (3) I ran into problems with my GnomeApp example, and I'm not sure
> which way to proceed. Glade-2 (1.1.2) exposes certain internal widgets
> of a Gnome App: namely
>
>   <child internal-child="dock">
>     <widget class="BonoboDock" id="bonobodock1">
>       <child>
> 	<widget class="BonoboDockItem" id="bonobodockitem1">
> 	  <child>
> 	    <widget class="GtkMenuBar" id="menubar1">
> 	      ...
>
> The question is, should glademm
>
> (a) try to manipulate the BonoboDockItems directly, using the
> libbonobouimm bindings.
>
> ... or ...
>
> (b) try to figure out the function of each BonoboDockItem and use the
> libgnomeuimm methods set_menus() and set_toolbar() when appropriate.
>
> I've tried (a); the advantage is you don't need to know about the
> special methods for handling menus and toolbars, you just do exactly
> what it says in the Glade-2 file. In fact, this is what glademm does
> for Gnome1, with GnomeDockItems instead of BonoboDockItems. The
> disadvantage is you need the libbonobouimm bindings, which I think are
> still not very stable. Unfortunately I needed to add a call to
> Gnome::Bonobo::wrap_init() at startup; this shouldn't be necessary
> in the long term but libgnomeuimm doesn't do it (there's a FIXME
> comment in the code there, though).

I'm familiar to Corba but don't know anything about bonobo, yet. 
Concerning internal widgets: Did you understand the isInternal way of 
setting up internal widgets? Seems so, but I'm not sure since I don't 
understand too much about bonobo.

If one of these methods involves creating an own widget and overwriting 
the already internally created widget instead of configuring the 
existing one, I'd prefer the other way (modifying the existing widget). 
To me this sounds like solution (a).

What about setting a flag (uses_bonobo) during ApplyPreferences() and 
emitting Gnome::Bonobo::wrap_init() in main(). This looks like the right 
way to do it. Sounds like "Gnome::Bonobo::main m(argc,argv,...);" (if 
that exists) would be the most consistent approach.

Sorry, perhaps Murray Cummings (gnomemm / libglademm maintainer) has a 
more knowledge based view on this.

    Christof