Le 02/03/2013 06:43, Matthew Brush a écrit :
Hi All,
I wanted comment/respond to a message on user list that is completely off-topic (development related). I don't know how to do it in Thunderbird so hopefully I didn't mess up the threading too bad:
On 13-03-01 05:24 AM, Frank Lanitz 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 ;) ).
No worries, and to clarify what I probably didn't express clearly to Lex...
I like the multiple tabs in MultiTerm (obviously, that's why I made it), but to even be close to a viable alternative to built-in VTE, it needs to integrate better with Geany like running execute command in it, receiving text from Scintilla buffer, other misc GUI integration, and to be completely re-written in C instead of Vala.
I didn't yet started talking about that in the other thread but I did think about it: how do you make a plugin run the execute commands without too ugly hackery in Geany?
I'd rather see a plugin _similar_ to MultiTerm providing a multi-tabbed terminal (but in C) as a core Geany plugin if it could provide the old features. The user experience would be the same or better[1] and we could get rid of all dependencies on VTE in core[2] and generally clean up all kinds of compile/run time checks and VTE-related code necessarily mixed about Geany's code currently.
Hum. If it is a core plugin, wouldn't it add a dependency on the Geany package? Of course it'd be optional and everything, but not really different than a build-time dependency on Geany itself, would it be?
I agree though that I personally don't see much use of not having the VTE support a build-time choice, but well...
I think writing such a plugin would be relatively easy compared to safely removing VTE from core code, which seems rather difficult and error-prone.
I didn't try, but I would have though that removing VTE support altogether was quite easy, just search for various HAVE_VTE and VTE settings and drop all this. Normally the whole thing can be actually disabled at both build time and compile time so the conditions should already be there.
It would be interesting to start an experimental branch that didn't touch core at all (yet) and made a core plugin equivalent to the builtin VTE. If it could implement all of the existing functionality as well as multi-tab support, IMO it would cross the threshold of being worthwhile to replace the builtin VTE.
Yes, if it doesn't render code uglier than it is already. And maintainable, too.
I imagine it would be easy enough to keep such a branch in sync with master during development since there's very little overlap as a plugin. Also, if it doesn't work out, it could be easily abandoned without affecting main branch at all.
Yes probably.
±1? Thoughts? comments? Anyone want to work on it?
I don't see yet the huge benefits, mostly because I don't see how to make it have all the same features as current VTE support without adding a whole bunch of hackery. And I don't feel so bad about the current dyload of the VTE, and even if I did I wouldn't feel bad about making the VTE dep a normal build-time choice (e.g. no dyload).
But yes, the plugin idea looks good by itself.
If anyone shows enthusiasm I could start a wiki page giving a bit of a "plan of attack" in case people want to help out and to collect ideas. I'm moderately interested in working on this myself in the near future[3], and also possibly extending it to include a Windows "Command Prompt"-like alternative using Win32 console API.
I don't show much enthusiasm, sorry ;)
Cheers, Colomban
P.S. Sorry for such a long email, it's difficult for me to express all of this concisely in English[4].
Cheers, Matthew Brush
[1] Especially if there is or could be a way to have core plugins loaded by default, if supported/available. [2] VTE doesn't seem worthy for Geany core to depend on since it doesn't work on most operating systems (except UNIXey ones not including OSX in my experience). [3] Especially if no one objects and I don't have to do it alone :) [4] Yes, it's my native language, but it still sucks