On Thu, 28 Feb 2013 18:56:19 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
That's suggests, not recommends, so it's not dragged in by default.
Why not just make it a hard dependency that's enabled by building against it at build time instead of dlopen()ing it?
+1, it would clean up a fair bit of extra code needed to dlopen it too.
We had a discussion on the topic some time ago, when I found two crashes if Geany was compiled with vte support but started without libvte...
--
On Fri, 1 Mar 2013 14:08:33 +1100 Lex Trotman elextr@gmail.com wrote:
IIUC that would mean that Geany binaries could not be run on any system without libvte9 installed, the user would have to re-compile?
And we had these argument as well...
--
On Fri, 01 Mar 2013 14:24:37 +0100 Frank Lanitz frank@frank.uvena.de wrote:
Am 01.03.2013 05:10, schrieb Lex Trotman:
FWIW I think Matthews suggestion of removing vte and using multiterm is the "right" solution, then only multiterm depends on libvte and it can be a hard depends.
I like the normal terminal more than multiterm to be honest (sorry Matthew ;) ).
And so do I. Some time in the last year, I wanted to propose separating our VTE terminal into a plugin, but was too busy with Scope. It's not a very hard thing to to, though keeping the VTE prefs in the basic prefs dialog is easier with an extra "settings-after-save signal" for the plugin to be able to read the new values instead of the old ones. That'll benefit any other plugins with VTE as well. What do you think?
[and if we apply "project-before-save" too, the settings/project save will have similar signals - these are currently "save-settings"-before and "project-save"-after-option]