On Wed, 24 Jun 2009 16:53:39 +1000, Lex wrote:
Hey,
After spending a couple of days trying to translate the current logic of operation of the build menu into the new version I have defined the following operation for the new system. The intention is that defaults won't change the user experience in any material way.
Great, and thanks for this short mail :).
Please let me know if there is anything missing, disagreed with or just plain wrong. The intention is that this can go in the manual.
I comment on a few things, I agree completely with everything I snipped out. So, the less text you find below the better.
configuration can be from the project file (if its open), user preferences or defaults which are as follows (underscore prededes the mnemonic):
- label: "_Make All", command: "make"
Maybe we should label it actually "Make" by default but this is really an unimportant detail for now, can be changed afterwards easily (and yes, hardcoding 'make all' was very wrong in the first place, we already talked about my mistake :D).
- label: "Make Custom _Target", command: "make ", but on
activation a text entry is shown and any text the user adds will be added to the end of the command (note the space after make)
I think we could add some extra logic here that checks the first character of the user supplied string to be space and if not, insert it. Or even better, unconditionally add the space as it won't hurt at all.
The execute menu item changes to "_Stop" and the icon changes to stop when a command initiated from the execute menu item is running and if activated the menu item will attempt to kill the executing command.
I read this as we have only one Run command? This is completely ok and sufficient IMO. The only thing which bites in is our famous LaTeX specials, yay. But I would say we could convenience users that usually one Run command is even enough for LaTeX. The rationale behind the two Run commands was that you can easily view your script as .dvi and as .pdf but I guess usually you only use one of the both formats, at least while testing. And so, one Run command should be enough, the user can then set it to launch a .dvi viewer or pdf viewer, whatever he prefers. Or for more advanced users, we could add a simple shellscript to the wiki (website) whih looks in the current directory for .dvi and .pdf files and launches a viewer command for whatever was found, or something. But this is much out of scope of this discussion and maybe of Geany at all, so don't worry about that. We have one Run command and that's fine.
affect the sensitivity of any other menu items. (Enrico how well does this behavior fit with your change of Windows to synchronous execution? It works fine for Linux of course so I wouldn't want to
Don't worry. The synchronous execution on Windows blocks the whole Geany interface, so we don't need to care about button sensitivity at all since everything is sort of insensitive, the GUI is blocked completely. However, the synchronous execution only affects Build commands, not the Run command. The latter one is still spawned asynchronously, as on Linux.
Both the project preferences tab and the build commands dialog are the same and behave the same *EXCEPT* (isn't there always one;-) that for menu items defined in a currently open project file, the build commands dialog will show the configuration from the project and will be set insensitive. (This is because the project will override the
Great idea.
I have continued with this basis and have continued to have success, so I ask for someone with the permission to do, so please remove the current build-system branch that appears to be massively broken and to make a new one based on trunk r3866,
I think it would be OK for you to do this yourself, so long as it only affects branches/build-system. Hopefully Enrico agrees with me ;-)
He does. :)
Well I actually wanted to completely replace build-system so there is no risk of contamination from the current contents, so if that can be done within build-system branch ok.
Not sure whether it can be done inside the branch but if you just want to throw away all the code in the current build-system branch in SVN, just 'svn delete build-system' in the branches directory and create it again by copying from trunk/. Of course, this requires you have saved your changes locally already in a patch or something to not throw away everything you have done so far :).
In whatever way you want to proceed, just do it. You have write permissions to the whole repository and as long as you don't touch trunk/ and tags/, everything is fine.
Regards, Enrico