[Geany-devel] Idea for the new build system (was: Re: Updating build-system branch)

[Enrico Tröger]

On Fri, 27 Mar 2009 17:04:20 +1100, Lex wrote:


>Warning:  GUI discussion below!!!!

Ahh, time to run away...

:)

>There is no reason not to add other things in the dialog but:
>
>In general I personally am not sure which I prefer,
>1. applications with a single big multi-page settings dialog where at
>least you know its in there somewhere, or
>2. applications which spread settings throughout the application in an
>attempt to put them near to the menus they apply to, which is sensible
>so long as users think like the developer ;-)
>
>Geany has generally been leaning towards the former with some notable
>exceptions (build and projects for example).

I personally prefer 1), i.e. a single preferences dialog where all
global settings can be found. As you pointed out, the build menu dialog
is an exception and you also correctly pointed out the rationale in
point 4, below.


>Let me make a couple of notes on the current build-system GUI
>extensions (at the risk of opening up too much discussion ;-):
>
>1. They are based on minimal changes from the current design but that
>has some negatives as follows
>
>2. The "set build commands" dialog is partly modal, that is, parts of
>it depend on if a project is open or not.  Yes the dialog title
>changes and some internal labels change to reflect the state but it is
>not GUI best practice.  You have to notice to know where your changes
>are being saved.
>
>3. This modality can be removed if project based build
>commands/options are added to the project properties dialog instead,
>atfer all the run command is there.

I don't mind much about it. On the one hand, all build/run commands
belong to build settings, on the other hand project-related build/run
commands belong to the project. It's more or less even :).
But you said above 'you have to know where your changes are being
saved', this is a good point and IMO argues for having project-related
commands in the project properties dialog.

But I'd leave this decision up to you and/or Nick.


>4. The non-modal build commands/options should remain as a build menu
>dialog since in a way they are still partly modal on the language of
>the current document, ie if a C file is current then the C commands
>can be edited, if a python file ...  So I don't think that fits well
>into the main preferences which are fully general.

Full ACK, nothing to add.


>Now for the error_regex, is it a base option or one that is project
>overridable (after all if you change the commands you may change the
>error messages by using a different compiler).  And how does it relate

For now, it is a per filetype setting, stored together with the
build/run commands. But of course, when build commands get also
project-related, error_regex maybe need also to be project-related
though it would complicate things a bit.
And then, probably most users don't need to use the error_regex setting
at all because the builtin defaults may suffice.
So, maybe it's not worth it at all and just don't add any GUI for it.


>Sorry for the really long answer to a simple question, with lots more
>questions added, unfortunately the question triggered me to think

Haha, I was afraid that happens :).


Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20090327/1dfb208b/attachment.pgp>