Re: [anjuta-devel] Glade catalog configure switch

[Tristan Van Berkom <tvb gnome org>]

On Mon, Mar 4, 2013 at 5:59 PM, James Liggett <jrliggett cox net> wrote:
> On 03/03/2013 11:55 PM, Tristan Van Berkom wrote:
>
> > I'm not sure I follow your problem space. If Anjuta embeds the
> > libgladeui-2 widgets for editing UIs, and installs it's own catalog
> > files to whichever location it chooses, then what's to stop Anjuta
> > from informing Glade about the location of Anjuta's catalog files
> > (before initializing Glade) using GLADE_CATALOG_SEARCH_PATH ?
> >
> > http://developer.gnome.org/gladeui/3.14/catalogintro.html
>
> I appreciate the suggestion, but I see a couple of issues with this
> approach:
>
> 1. While we could probably have our Glade plugin set these environment
> variables, that solution feels like a hack for one specific problem that
> the vast majority of our users won't have. I don't think something like
> that belongs in the Glade plugin. And it would only work if you opened
> the files from within Anjuta.
>
> 2. Glade files aren't always edited from within Anjuta. What would
> happen if I opened a UI file from my file manager or from an e-mail or
> bug report? In most cases the file association system would start Glade,
> probably without the environment variables set, and it wouldn't work
> anyway. I really don't want to have to set an environment variable every
> time I open one of my UI files. I'm betting that most of us edit glade
> files much more often than we run configure. Besides, Anjuta remembers
> configure switches, and I assume that most Anjuta devs use Anjuta to
> work on Anjuta, so this would be set and forget for pretty much anybody
> that's affected by this change.
>
> I can't speak for the rest of my team, but I think putting a hack in the
> Glade plugin or having to set environment variables is a little messy.
> IMO it's just better to have the build system make sure it goes to the
> right place so that it always just works, no matter how you open our UI
> files. The cost here is that we have to remember to pass an extra option
> to configure, but in return we don't bother those that don't need it and
> it works in all cases for those that do with no extra effort.

I think I see where you're coming from, when you install Anjuta into
a relocated 'dev' prefix like /opt/devel, you would want to install
the Glade catalog into /opt/devel/share/glade/catalogs (where Glade's
pkg-config file would prescribe, had Glade been compiled into the
same relocated prefix/environment), but you would not want a relocated
Anjuta to install catalog files to the system /usr prefix.

You wouldn't be the first to add an --enable-glade-catalog configure option,
and I think that's a fine thing to do, but I would recommend that with this
added configure option, you also revert to standard installation of the
Glade catalog when enabled.

This would mean that:

  o If Glade is installed in /opt/devel, anjuta will install to
     /opt/devel/share/glade/catalogs

  o If Glade is not installed in /opt/devel, but installed
     in /usr, then Anjuta's 'make install' should ideally
     fail with a permission denied (this is good because
     we want to avoid mixing things up).

  o Anjuta could then pass 'make install' by configuring
     --disable-glade-catalog, or by installing a relocated
     build of Glade into the same prefix first.

This problem is not unlike installing fonts to a prefix's font cache,
or icons into a prefix's icon theme cache.

Cheers,
           -Tristan