Hi Guys,<br><br>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.<br>
<br>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.<br>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.<br>
<br>BUILD MENU<br><br>The build menu has two types of menu items, configurable and fixed.<br><br>Fixed menu items are always visible and show the same text:<br>- next error - is sensitive anytime that the current document has a next error mark to go to<br>
- previous error -  is sensitive anytime that the current document has a previous error mark to go to<br>- 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.<br>
<br>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.<br>
<br>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:<br>
<br>- 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.<br><br>- 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):<br>    1. label: "_Make All", command: "make"<br>
    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)<br>    3. label "Make _Object", command: "make %e.o"<br>
    4. no default<br><br>- 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"<br><br>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.<br>
<br>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.<br><br>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.<br>
<br>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.)<br>
<br>DIALOGS<br><br>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.<br>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).<br>
<br>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).<br>
<br>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.<br><br>Simple :-)<br>
<br>Cheers<br>Lex<br><br>PS I'll try SVN in a few days. See below for more.<br><br><div class="gmail_quote">2009/6/23 Enrico Tröger <span dir="ltr"><<a href="mailto:enrico.troeger@uvena.de">enrico.troeger@uvena.de</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Mon, 22 Jun 2009 13:45:19 +0100, Nick wrote:<br>
<br>
>On Mon, 22 Jun 2009 15:21:45 +1000<br>
>Lex Trotman <<a href="mailto:elextr@gmail.com">elextr@gmail.com</a>> wrote:<br>
><br>
>> I have continued with this basis and have continued to have success,<br>
>> so I ask for someone with the permission to do, so please remove the<br>
>> current build-system branch that appears to be massively broken and<br>
>> to make a new one based on trunk r3866,<br>
><br>
>I think it would be OK for you to do this yourself, so long as it only<br>
>affects branches/build-system. Hopefully Enrico agrees with me ;-)<br>
<br>
</div>He does.<br>
<div class="im">:)<br>
</div></blockquote><div><br>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.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
>> that way I can just copy the changed files into a<br>
>> checkout of the new branch and continue.  Thanks in advance.<br>
><br>
>Maybe 'svn switch' would work, not sure.</div></blockquote><div>I'll have to look that one up ;-) <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
><br>
>> Currently I have both build dialog and project dialogs setting<br>
>> commands, build menu created from them and am about to add save and<br>
>> restore in prefs and projects, then will check it in as a prototype<br>
>> in the new branch.  Oh and most Latex special code gone,<br>
<br>
</div>Yay.<br>
<br>
Regards,<br>
Enrico<br>
<font color="#888888"><br>
--<br>
Get my GPG key from <a href="http://www.uvena.de/pub.asc" target="_blank">http://www.uvena.de/pub.asc</a><br>
</font><br>_______________________________________________<br>
Geany-devel mailing list<br>
<a href="mailto:Geany-devel@uvena.de">Geany-devel@uvena.de</a><br>
<a href="http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel" target="_blank">http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel</a><br>
<br></blockquote></div><br>