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'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.
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. 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.
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.
±1? Thoughts? comments? Anyone want to work on it?
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.
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
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
On Sat, 02 Mar 2013 14:37:46 +0100 Colomban Wendling lists.ban@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.
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.
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.
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.
On 3 March 2013 06:44, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sat, 02 Mar 2013 14:37:46 +0100 Colomban Wendling lists.ban@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@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
--- On Sun, 3/3/13, Lex Trotman elextr@gmail.com wrote:
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.
Don't forget also that this would make Geany more attractive as a default text editor for distros like Mint, which are definitely not lightweight/rescue, but want to target non-dev users.
Le 03/03/2013 23:31, Thrawn a écrit :
--- On Sun, 3/3/13, Lex Trotman elextr@gmail.com wrote:
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.
Don't forget also that this would make Geany more attractive as a default text editor for distros like Mint, which are definitely not lightweight/rescue, but want to target non-dev users.
They can always easily disable the VTE in the settings[1], so I don't see the big deal.
Regards, Colomban
[1] or even build Geany without VTE support but that's a bad idea
On Sun, 3 Mar 2013 10:37:21 +1100 Lex Trotman elextr@gmail.com wrote:
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.
You are right, as Loong Jin also pointed out. All we need to do is drop a note to the package maintainers not to add libvte as run-time dependency, just in case. Neither build nor run time dependencies need to be changed, which is a good thing.
On 05/03/2013 01:44, Dimitar Zhekov wrote:
On Sun, 3 Mar 2013 10:37:21 +1100 Lex Trotman elextr@gmail.com wrote:
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.
You are right, as Loong Jin also pointed out. All we need to do is drop a note to the package maintainers not to add libvte as run-time dependency, just in case. Neither build nor run time dependencies need to be changed, which is a good thing.
It's worth noting that not adding libvte as a runtime dependency may actually be pretty hard to implement, as at least on Debian, some of the dependencies are inferred from the NEEDED entries (objdump -p) of ELF binaries and shared objects. I believe rpmbuild also does something similar for RH-based distros.
I'd suggest splitting the terminal plugin into a separate, recommended (optional, installed by default) package instead.
On 02/03/2013 21:37, Colomban Wendling wrote:
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?
Not really. A core plugin exists as a separate file from the core geany binary, meaning that distros can easily shift the file into a separate, optional package if need be.
On Fri, 01 Mar 2013 21:43:13 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
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.
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.
±1? Thoughts? comments?
+1.
IMO, the visual Terminal prefs, "Override Geany keybindings" and "Disable menu shortcut key" should remain in Geany (and probably be moved into Glade), since there are other plugins using VTE.
Anyone want to work on it?
Yes, but I have something to complete, and then more work on Scope...
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.
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.
On 03/03/2013 04:24, Dimitar Zhekov wrote:
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.
There is a difference. I believe Geany can still run when unloadable plugins live in its plugin directory, meaning that if you uninstall libvte9, all that happens would be that the core VTE plugin becomes un-loadable.
And like I mentioned in my previous post, having this functionality (and dependency) as a separate file allows distributions to move it into a separate package of its own when needed.