Hi Guys,
I have had a lot of problems with strange behavior for a couple of weeks. I decided that the problems were related to the SVN merge of the build system branch with trunk which seems not to have done what I had expected. Maybe it was an update too far.
To "prove" this I checked out a truck (r3866) and copied some of my changes into it. Success! No problems anywhere but in my code, but them I expect ;-).
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, that way I can just copy the changed files into a checkout of the new branch and continue. Thanks in advance.
Currently I have both build dialog and project dialogs setting commands, build menu created from them and am about to add save and restore in prefs and projects, then will check it in as a prototype in the new branch. Oh and most Latex special code gone, you won't recognise build.c.
Cheers Lex
On Mon, 22 Jun 2009 15:21:45 +1000 Lex Trotman elextr@gmail.com wrote:
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 ;-)
that way I can just copy the changed files into a checkout of the new branch and continue. Thanks in advance.
Maybe 'svn switch' would work, not sure.
Currently I have both build dialog and project dialogs setting commands, build menu created from them and am about to add save and restore in prefs and projects, then will check it in as a prototype in the new branch. Oh and most Latex special code gone,
Sounds good.
you won't recognise build.c.
:-O ;-)
Regards, Nick
On Mon, 22 Jun 2009 13:45:19 +0100, Nick wrote:
On Mon, 22 Jun 2009 15:21:45 +1000 Lex Trotman elextr@gmail.com wrote:
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. :)
that way I can just copy the changed files into a checkout of the new branch and continue. Thanks in advance.
Maybe 'svn switch' would work, not sure.
Currently I have both build dialog and project dialogs setting commands, build menu created from them and am about to add save and restore in prefs and projects, then will check it in as a prototype in the new branch. Oh and most Latex special code gone,
Yay.
Regards, Enrico
Hi Guys,
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.
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 know that is a lot of words for a GUI operation, but I have tries to make it a simple hierarchy, i.e. fixed vs configurable, if configurable where is it configured from, then when are menu items available and when are they insensitive, finally the logic of the configuration dialogs.
BUILD MENU
The build menu has two types of menu items, configurable and fixed.
Fixed menu items are always visible and show the same text: - next error - is sensitive anytime that the current document has a next error mark to go to - previous error - is sensitive anytime that the current document has a previous error mark to go to - set build commands - always available and shows the build commands dialog (see below). Because this is always available, the build menu itself is always available.
Configurable menu items all execute external commands not part of Geany, and can have both the menu item text label and the command to be run configured. Some menu items have icons, these are currently not configurable.
There are three groups of configurable menu items with differing configuration sources. These groups are: three filetype menu items, four non-filetype menu items and execute. The configuration takes the definition in the highest priority source. The sources in decreasing priority for each group are:
- filetype menu items can be configured from the project file (if its open), user preferences or by default the filetype file. There are no other defaults if not defined in the filetype file.
- non-filetype menu items can also configure if the command runs in the directory of the current document or in the base directory defined for the project (if one is open) as well as label and command. The configuration can be from the project file (if its open), user preferences or defaults which are as follows (underscore prededes the mnemonic): 1. label: "_Make All", command: "make" 2. 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) 3. label "Make _Object", command: "make %e.o" 4. no default
- execute can be configured from the project file (if its open), the user preferences, the filetype file or a default which has label "_Execute" and command "./%e"
Any menu item that is not configured in any source or which has a zero length label will not be visible in the menu. Extraneous separators are also not visible. Commands can be zero length because it is possibly usefull for non-filetype menu item two, so that the user types the whole command. Since an empty command does no damage (it actually doesn't run) it does not seem worth adding logic to only allow it for non-filetype command two.
Only one of the filetype and non-filetype commands can be executing at a time and all menu items in the filetype and non-filetype groups are set insensitive when one is executing.
If the current document does not have a both a filetype and a filename (has been saved once) then the filetype menu items are set insensitive.
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. Since this is an internal operation like the fixed menu items (ie doesn't run a command), the label is not configurable. It does not 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 change it.)
DIALOGS
Configuration for menu items defined by the project file is in a tab of the project peferences dialog. Configuration for menu items in the user preferences is in the build commands dialog. 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 user preferences in the menu and so changing the user preference would have no effect, potentially causing user confusion).
Both tab and dialog allow configuration for menu items relating to the filetype of the current document only. (This isn't perhaps perfect user interface design, but its the way the current system works and it is potentially complicated to change).
If there is no current document or it has no filetype then the entries for filetype menu items are insensitive but the other entries are always available, which is why the dialog is always available.
Simple :-)
Cheers Lex
PS I'll try SVN in a few days. See below for more.
2009/6/23 Enrico Tröger enrico.troeger@uvena.de
On Mon, 22 Jun 2009 13:45:19 +0100, Nick wrote:
On Mon, 22 Jun 2009 15:21:45 +1000 Lex Trotman elextr@gmail.com wrote:
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.
that way I can just copy the changed files into a checkout of the new branch and continue. Thanks in advance.
Maybe 'svn switch' would work, not sure.
I'll have to look that one up ;-)
Currently I have both build dialog and project dialogs setting commands, build menu created from them and am about to add save and restore in prefs and projects, then will check it in as a prototype in the new branch. Oh and most Latex special code gone,
Yay.
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
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
Shorter (slightly) reply ;-)
2009/6/24 Enrico Tröger enrico.troeger@uvena.de
On Wed, 24 Jun 2009 16:53:39 +1000, Lex wrote:
Great, and thanks for this short mail :).
Thank you very much for reading it, I'm trying to express the essential simplicity of the system to put in the manual and this is the shortest I've come up with to date, not quite there maybe, but definitely better than previous attempts.
- 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).
I was just making it the same as 0.17, as you say it doesn't matter we can change it anytime.
- label: "Make Custom _Target", command: "make ", but on
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.
I actually thought that it was better not to impose that there had to be a space, for all I know someone has a situation where they want to directly catenate the typed input to the command, or more likely to the last argument. Putting the space in the configurable part means that we don't rule out things just because we can't think of a use right now.
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 We have one Run command and that's fine.
Yes only one run command at the moment. Note that the implementation is such that if it *really* is a problem then the extra run command can be added back in reasonably easily (same goes for adding extra commands to any of the configurable sections) by changing some enums and tables. Since execute commands inherit from filetype, the menu could then inherit two different execute commands for lAtEx from the filetype and the extra menu item would be ignored (and not visible) for everything else (or at least until someone found a use for it ;-) For now I will stick to one and lets see how much trouble it causes.
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 :).
Well I was just going to check out the new branch into a different directory and copy over the changed files, I use bazaar for my personal change control so it will tell me which ones to copy.
Cheers Lex
On Thu, 25 Jun 2009 16:37:25 +1000, Lex wrote:
- label: "Make Custom _Target", command: "make ", but on
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.
I actually thought that it was better not to impose that there had to be a space, for all I know someone has a situation where they want to directly catenate the typed input to the command, or more likely to the last argument. Putting the space in the configurable part means that we don't rule out things just because we can't think of a use right now.
Ok, so let's keep the current behaviour.
Regards, Enrico