[Geany-devel] Build System Upgrade Status
enrico.troeger at xxxxx
Wed Jun 24 12:04:51 UTC 2009
On Wed, 24 Jun 2009 16:53:39 +1000, Lex wrote:
>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
> 1. 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).
> 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)
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
>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
However, the synchronous execution only affects Build commands, not
the Run command. The latter one is still spawned asynchronously, as on
>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
>> >> 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
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.
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the Devel