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,
- 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 ;-):
- They are based on minimal changes from the current design but that
has some negatives as follows
- 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.
- 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.
- 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