Hi All,
As requested by Enrico, a new thread for discussion of issues around killing builds and UI changes.
I've pasted a little from previous discussions as a seed.
I can see that you may want to kill a long build that you started by accident or when you realise you forgot to do something first. I've done that more than once ;-)
I guess we all had this issue already. At the time we added the Stop button for the Run command we also tried implementing this for the Make commands. But as you both noticed in this thread, it's not that easy. I don't say it's not possible but it's just not as easy as it may sound.
commands are set insensitive until completion. To have one menu item still enabled and to have it change to stop is going to be quite a bit of fiddling unless it is always a fixed menu item or a toolbar button.
Yes, as you say it, I'm thinking about. We actually could add a separate Stop button for the toolbar and the Build menu, That would obsolete a lot of not so nice code in build.c which deals with the double action of the button. And since the toolbar is pretty easy to configure these days, that probably would not be a big deal UI-wise. Though I don't have a strong opinion on that. Just share your thoughts about this, maybe in a separate new thread.
The switching execute menu items is a lot cleaner in the build-system version. At leasts IMHO, shouldn't comment on own code should I.;-)
My real concern is that Geany should not have a built-in kill build because of the difficulties associated with killing every child spawned from the build and the risk of the build directories being left in a strange state when the build is killed. This is especially true now that the build sysytem can run anything in any directory. That took up lots of the discussion on the previous thread and I won't repeat it here.
Thats why I encouraged Thomas to write an external script that users can configure into Geany and modify if needed. If we coded something into Geany then users can't fix it to solve problems they run into. This also helps with portability, users can create and contribute scripts for many different systems where finding child processes differ or where the particular scripting language doesn't exist.
Of course having a specific menu item and toolbar which can be configured to run that script is still ok, I wouldn't have a problem with it in the build menu, it would essentially be an execute menu item with a different label. Probably positioned after the make menu items? Because of the risks mentioned above I believe that this menu item/toolbutton should not be available by default, maybe configured by preference or hidden preference by users who know what they are doing :-)
Cheers Lex
On Tue, 18 Aug 2009 11:39:18 +1000, Lex wrote:
Hi All,
Same to you :).
As requested by Enrico, a new thread for discussion of issues around killing builds and UI changes.
Thanks.
Yes, as you say it, I'm thinking about. We actually could add a separate Stop button for the toolbar and the Build menu, That would obsolete a lot of not so nice code in build.c which deals with the double action of the button. And since the toolbar is pretty easy to configure these days, that probably would not be a big deal UI-wise. Though I don't have a strong opinion on that. Just share your thoughts about this, maybe in a separate new thread.
The switching execute menu items is a lot cleaner in the build-system version. At leasts IMHO, shouldn't comment on own code should I.;-)
Hehe. Ok, I'm not sure right now what way is better apart from the quality of the code :). Maybe I or someone else get some more ideas about this after we finally merged the branch into trunk.
My real concern is that Geany should not have a built-in kill build because of the difficulties associated with killing every child spawned from the build and the risk of the build directories being
I fully and completely agree. If necessary this could most probably be done in a plugin or with an external script which is called from within Geany as just another build command or whatever.
left in a strange state when the build is killed. This is especially true now that the build sysytem can run anything in any directory. That took up lots of the discussion on the previous thread and I won't repeat it here.
Thats why I encouraged Thomas to write an external script that users can configure into Geany and modify if needed. If we coded something into Geany then users can't fix it to solve problems they run into. This also helps with portability, users can create and contribute scripts for many different systems where finding child processes differ or where the particular scripting language doesn't exist.
Of course having a specific menu item and toolbar which can be configured to run that script is still ok, I wouldn't have a problem with it in the build menu, it would essentially be an execute menu
Not sure whether that is really necessary. If I'm not totally wrong, you can also call a fancy 'I kill everything which I want to kill' script as an usual build command, if so, I don't see a need for an extra separate stop action button/menu item. Note that this is different from the Execute/Stop button as described above.
Regards, Enrico
Enrico Tröger schrieb:
I fully and completely agree. If necessary this could most probably be done in a plugin or with an external script which is called from within Geany as just another build command or whatever.
Then please add a way to surpress the terminal that pops up when executing. I already have a script that does what I want (but that does it slower and is as "dangerous" as what I hacked together in geany.
2009/8/19 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 18 Aug 2009 11:39:18 +1000, Lex wrote:
Hi All,
Same to you :).
As requested by Enrico, a new thread for discussion of issues around killing builds and UI changes.
Thanks.
Yes, as you say it, I'm thinking about. We actually could add a separate Stop button for the toolbar and the Build menu, That would obsolete a lot of not so nice code in build.c which deals with the double action of the button. And since the toolbar is pretty easy to configure these days, that probably would not be a big deal UI-wise. Though I don't have a strong opinion on that. Just share your thoughts about this, maybe in a separate new thread.
The switching execute menu items is a lot cleaner in the build-system version. At leasts IMHO, shouldn't comment on own code should I.;-)
Hehe. Ok, I'm not sure right now what way is better apart from the quality of the code :). Maybe I or someone else get some more ideas about this after we finally merged the branch into trunk.
Agreed.
My real concern is that Geany should not have a built-in kill build because of the difficulties associated with killing every child spawned from the build and the risk of the build directories being
I fully and completely agree. If necessary this could most probably be done in a plugin or with an external script which is called from within Geany as just another build command or whatever.
left in a strange state when the build is killed. This is especially true now that the build sysytem can run anything in any directory. That took up lots of the discussion on the previous thread and I won't repeat it here.
Thats why I encouraged Thomas to write an external script that users can configure into Geany and modify if needed. If we coded something into Geany then users can't fix it to solve problems they run into. This also helps with portability, users can create and contribute scripts for many different systems where finding child processes differ or where the particular scripting language doesn't exist.
Of course having a specific menu item and toolbar which can be configured to run that script is still ok, I wouldn't have a problem with it in the build menu, it would essentially be an execute menu
Not sure whether that is really necessary. If I'm not totally wrong, you can also call a fancy 'I kill everything which I want to kill' script as an usual build command, if so, I don't see a need for an extra separate stop action button/menu item. Note that this is different from the Execute/Stop button as described above.
Well kill build can't be a normal build menu item since they are insensitive while builds are running :-)
Could be an execute menu item though, with the label configured to "kill-build"" Could make a film title, oh! already done! :-D (cultural reference, your humour may vary)
Urm Thomas' post just came through, I guess showing the terminal is an issue with execute menu items, although it ensures that there is somewhere for panic messages from the script to go.
Is the kill going to be used that often by most users to make it worth adding extra handling?
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Urm Thomas' post just came through, I guess showing the terminal is an issue with execute menu items, although it ensures that there is somewhere for panic messages from the script to go.
Is the kill going to be used that often by most users to make it worth adding extra handling?
Cheers Lex
Can it at least be auto closed, say if the script returned success (i.e. 0)?
2009/8/19 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Urm Thomas' post just came through, I guess showing the terminal is an issue with execute menu items, although it ensures that there is somewhere for panic messages from the script to go.
Is the kill going to be used that often by most users to make it worth adding extra handling?
Cheers Lex
Can it at least be auto closed, say if the script returned success (i.e. 0)?
Well we *don't* want normal executes to do that,output should be shown even if the program ran successfully, so some configuration is needed. I don't know how easy it would be to do either, it has to work for external terminals and for VTE if thats what is being used. Oh and potentially for windows when builds are corrected to be asynchronous again.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Can it at least be auto closed, say if the script returned success (i.e. 0)?
Well we *don't* want normal executes to do that,output should be shown even if the program ran successfully, so some configuration is needed. I don't know how easy it would be to do either, it has to work for external terminals and for VTE if thats what is being used. Oh and potentially for windows when builds are corrected to be asynchronous again.
Cheers Lex
It looks like it could be mostly handled already, just need the configuration. Do *not* want to make the build menu configuration dialog bigger (do we Enrico :-) so some other option needs to be used. I won't do this until after build-system is in trunk.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 19 Aug 2009 10:06:20 +1000, Lex wrote:
Can it at least be auto closed, say if the script returned success (i.e. 0)?
Well we *don't* want normal executes to do that,output should be shown even if the program ran successfully, so some configuration is needed. I don't know how easy it would be to do either, it has to work for external terminals and for VTE if thats what is being used. Oh and potentially for windows when builds are corrected to be asynchronous again.
Cheers Lex
It looks like it could be mostly handled already, just need the configuration. Do *not* want to make the build menu configuration dialog bigger (do we Enrico :-) so some other option needs to be used. I won't do this until after build-system is in trunk.
It seems you know me already pretty good :)
No, I do not want to have more options and more special commands for Thomas' need to kill builds (btw, Lex' joke about film titles was coool). Don't get me wrong but I don't see this as that important, usually (!) you want a build to finish and not kill it for whatever reason. And if so, opening a terminal and type 'killall make' isn't that hard, I guess.
Or as already said, (ab)use the Execute command and live with the opened terminal. IMO the opened terminal for the Execute command should stay open, in any case. That is what it is meant for, Lex already said.
Finally, as also already said, if it is really that important, implement it as a plugin and request API additions you need.
Just my 2 cents.
Regards, Enrico
Enrico Tröger schrieb:
On Wed, 19 Aug 2009 10:06:20 +1000, Lex wrote:
Can it at least be auto closed, say if the script returned success (i.e. 0)?
Well we *don't* want normal executes to do that,output should be shown even if the program ran successfully, so some configuration is needed. I don't know how easy it would be to do either, it has to work for external terminals and for VTE if thats what is being used. Oh and potentially for windows when builds are corrected to be asynchronous again.
Cheers Lex
It looks like it could be mostly handled already, just need the configuration. Do *not* want to make the build menu configuration dialog bigger (do we Enrico :-) so some other option needs to be used. I won't do this until after build-system is in trunk.
It seems you know me already pretty good :)
No, I do not want to have more options and more special commands for Thomas' need to kill builds (btw, Lex' joke about film titles was coool). Don't get me wrong but I don't see this as that important, usually (!) you want a build to finish and not kill it for whatever reason. And if so, opening a terminal and type 'killall make' isn't that hard, I guess.
As we've established in the other thread, killall make isn't an option, since it kills all makes on the system, some of which aren't started by you (such as if you're running a build client for other software to help building nightlies).
Or as already said, (ab)use the Execute command and live with the opened terminal. IMO the opened terminal for the Execute command should stay open, in any case. That is what it is meant for, Lex already said.
Finally, as also already said, if it is really that important, implement it as a plugin and request API additions you need.
I see. I'll just stick to my local hack then.
Best regards.