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
