Re: gephex--main--0.4--patch-1846

Martin Bayer wrote:
>> Yes, I see. But I don't think this is important. Due to the build system
>> stuff (dependency to pluc.py, no extra module and type SDK) I suppose
>> that there won't be many third party developers other than those who
>> integrate their modules into our source tree.
> 
> 
>> Or, to put it another way, I think the gephex type and module system is
>> not really targetted towards (and not suited for) third party 
>> development.
> 
> 
> It's right that developing plugins outside of the gephex source tree is
> a bit difficult, but it's not impossible.
> 
>> That's why I don't see much benefit in this part of the patch,
> 
> 
> I use a gephex installation at /usr/ from a debian package and install
> only new or modified modules in a subdir in my home directory. This
> allows me to reinstall all gephex stuff in /usr with dpkg and keep my
> local experimental changes in ~/.gephex/

But this is a developer only scenario, too :)

> 
>> but I see that
>> it breaks current behaviour. (In addition the patch could lead to even 
>> more
>> confusion when multiple gephex versions are installed at different
>> locations).
> 
> 
> There is only a behavior change if gephex is installed at a uncommon
> location or if there a multiple installations of gephex. The first is
> only relevant for developers and the second is buggy with or without the
> change. The default gephex.conf is only installed in the users home at
> the first startup time. The gephex location to search for the plugins is
> wrong if you reinstall it at a different location.

True.

> The current behavior of configure time selection of the default location
> to search for plugins is problematic for distributions. It is difficult
> to relocate the plugins after build time. E.g. binary linux
> distributions with user installable packages(in the users home) need to
> patch files at install time.

How do you handle this with the debian packages at the moment?
Isn't the path substitution handled at install time in data/Makefile.am?
(Cannot check it right now).

My point against the patch is: I don't expect third party modules
and types for gephex any time soon. If somebody does it, he will also manage
to change gephex.conf. Apart from that, I think third party add-ons
should be done with frei0r.
So there is not much incentive to change currrent behaviour (which may also
be not optimal, but I don't see serious problems).

Georg