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

Lex Trotman elextr at xxxxx
Fri Mar 27 06:04:20 UTC 2009


Hi Enrico,

I don't think we had a conclusively brilliant suggestion for what to call
the dialog so I was just using"set build commands" in the interim, after all
its easy to change any time up to string freeze.  I am not sure that "Set
Build Options" directly implies to me that is where you set the commands,
although I would probably end up trying it and find the commands.  So maybe
"Set Build Commands/Options" if it will fit.

Warning:  GUI discussion below!!!!

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).

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.

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.

So possibly the better solution would be to put a tab in project properties
to set build commands/options for the project which, if set override the
general settings in the build menu set build commands/options.  The project
value could be displayed there but greyed out and uneditable.  This means
that the commands that are going to be used are visible in the one place
which is connected with the build menu, but editing is separate to make it
clearer where the commands/options are stored.

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 to
filetypes commands, the messages from different compilers could change per
language?  Or is all this too hard and it is only a personal preference?

Obviously the answers above suggest the best place to put it.  I can easy
handle project overrides personal preferences, thats how all the commands
work, but by language may be a bit of a streach for now.

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

Let me know what you think.

Cheers
Lex

2009/3/26 Enrico Tröger <enrico.troeger at uvena.de>

> On Thu, 12 Mar 2009 13:55:47 +1100, Lex wrote:
>
> Hey Lex,
>
> assuming you are having something like a TODO list for your branch, I
> got an idea inspired by an user on IRC:
>
> I remember we talked about the "Set Includes and Arguments" dialog in
> the past and how to rename it. Though I don't remember whether and how
> we decided :).
>
> So, here is a suggestion: "Set Build Options".
>
> This is a bit more general and allows us to add a field for the
> "error_regex" setting so users can on the fly change this setting
> without editing config files.
>
> Just an idea.
>
>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20090327/1ef531ef/attachment.html>


More information about the Devel mailing list