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