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

[Lex Trotman]

On 3 March 2013 06:44, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> On Sat, 02 Mar 2013 14:37:46 +0100
> Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>
>> 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?
>
> First, you can emit a gboolean signal with more data than
> "build-start", and execute the command in Geany only if no plugin
> executed it already.

Yes, thats a good way of doing it, and it can be useful to other
plugins. But it would have to return the process_id being run, it
shouldn't be synchronous (except on windows).

>
> Second, the VTE plugin can define menu items for the execute actions
> somewhere under "Tools" (with shortcuts of course). So Build -> Execute
> will run the program with $TERM, and Tools -> VTE -> Execute (for
> example) will run it in VTE.

Personally I think thats *very* ugly, if I was wanting commands to run
in the VTE plugin I would not want to have two sets of commands.  Your
suggestion above should make it transparent (except for the preference
to say run in VTE plugin, but that is a plugin preference anyway :)

>
>> 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?
>
> Personally I thought about putting it in geany-plugins, since debugger,
> scope and multiterm already depend on libvte, or in a separate plugin.
>
>> 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.

@Colomban, VTE stuff is already mystical hackery, the way it tries to
determine the state of the VTE by smoke and mirrors for example :) So
I doubt it would be worse since we can define a nice neat interface to
the plugin :)

>
> Execute will require some work, send selection to terminal is easy. I
> don't think hackery will be required, just some signals and/or extra
> plugin API functions, and they may be beneficial to the other plugins
> with vte.
>

[from next post]

>Great minds think alike. :) However, as Colomban stated, making it a
>core plugin means that it will be a compile-time option for the whole
>Geany package, which is no different from making it a compile-time-only
>option for Geany itself.

Sure but if compiled into binary packages, the plugin will still not
load if libvte isn't present on the end user system.  So we have the
same flexibility as now.  A binary distro would only not compile it in
if it didn't even have VTE available in its repos at all.


BTW to all, the use-case for having a non-VTE Geany is lightweight
distros and rescue distros, especially where they run entirely in
memory, adding a couple of Mb is a few more percent on the distro,
fine for machines with 4Gb, but more of an issue for smaller systems.

>Will there be enough problems to warrant a page? We should discuss the
>Execute commands and the ability for a plugin to register widgets as
>"Override Geany keybindings" / "Disable menu shortcut key" (whichever
>are set), and that's all. The buildin VTE is actually < 1000 lines
>with the dlopen stuff.


The wiki page sounds like a good idea, I suspect that sufficient
problems/suggestions will occur to make it worth while.

As I've said on IRC, I don't use VTE, so I won't help, and I will also
continue to defend vigourously my right to not load the damn thing :)

Cheers
Lex

> --
> E-gards: Jimmy
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel