Hello,
I'm catching flack from the fedora people because of the way geany handles vte support. Now I don't see anything wrong with this approach, but in the name of making everybody happy I have this proposal. Instead of treating libvte as a plugin and doing g_module_open() on the library itself, how bout separating out the vte functionality even more into its own plugin. So instead of doing a g_module_open() on libvte, you do a g_module_open() on libgeanyvte or whatever, and then you can compile vte support into the geany-vte plugin. This keeps the same functionality as you have currently, where if you can't find the geany-vte plugin it doesn't matter, and you have better control on where that goes so you don't have to keep a list of libraries to lookup. My responsibility as the fedora packager is simply to match what upstream has, so if you don't like this approach that is fine with me and everything will continue status quo, but if you do like this approach then it would be helpful to me, and it could even open up the possibility of having a broader plugin framework for geany. Thank you,
Josef
On Thu, 25 Jan 2007 12:43:55 -0500, Josef Whiter josef@toxicpanda.com wrote:
Hello,
I'm catching flack from the fedora people because of the way geany handles vte support. Now I don't see anything wrong with this approach, but in the name of making everybody happy I have this proposal. Instead of treating libvte as a plugin and doing g_module_open() on the library itself, how bout separating out the vte functionality even more into its own plugin. So instead of doing a g_module_open() on libvte, you do a g_module_open() on libgeanyvte or whatever, and then you can compile vte support into the geany-vte plugin. This keeps the same functionality as you have currently, where if you can't find the geany-vte plugin it doesn't matter, and you have better control on where that goes so you don't have to keep a list of libraries to lookup. My responsibility as the fedora packager is simply to match what upstream has, so if you don't like this approach that is fine with me and everything will continue
Sorry, but I don't see the advantage. The only thing is, that we create more code and need to handle installation and distribution of the additional plugin. Geany will get a plugin interface and then it will get a VTE plugin. I.e. the current VTE code will be moved into a plugin but first when we have a kind of plugin interface. I really don't see any advantage in moving the code into a semi-plugin at the moment.
Regarding your last problem, you saw that Geany builds without the vte-devel package and "depends" only on the library itself. And since r1229 the libvte-detection is working correctly, so why change the code?
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.key