[Geany-Devel] Core Terminal Plugin (was Re: [Geany-Users] no Terminal tab in Geany preferences??)

[Colomban Wendling]

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