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
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@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel