[Geany-devel] Build config dialog change

Lex Trotman elextr at xxxxx
Mon Jun 14 01:20:50 UTC 2010

> Of course, I don't have this version in mind when posting my comments.
> Your current version is alright for 0.19.1.

Ok thanks, as you probably can tell I'd rather move on than try to
tart up what I consider to be a fundamentally bad UI.

>> And as I explained I'm don't like UIs that
>> save hidden changes, as will happen if you make changes to several
>> filetypes, and having a reminder dialog all the time is annoying.
> Well, having the reminder is less annoying than having to close the
> dialog, find the file with the extension whose commands you want to
> edit and open the dialog again. It means no extra annoyance if you use
> it the same way you do now.

see below for another suggestion.

>>> 2. Grouping execute and build commands together so it's clear that
>>> they are per-filetype (now I have an idea for name substitution for
>>> "non-filetype" - maybe "filetype-independent" could be clearer)
>> Not changing for 0.19, string freeze was weeks ago.
> Of course, I don't expect this for 0.19.
>>> And I have one more idea - wouldn't it be better to put the contents
>>> of the "set build commands" dialog as a new tab in the "preferences"
>>> dialog? This would mean that there are only two settings dialogs - the
>>> preferences dialog for global options and "project properties" for the
>>> project ones.
>> This won't change for 0.19 and as I keep saying the intention for the
>> next version is to have a combined dialog

I should have pointed out that there is no reason for the combined
dialog to not be openable from several places, project, prefs, build
menu.  Personally I like that it can be accessed quickly from the
build menu, rather than having to dig through the prefs, but as I say
activating the combined dialog from multiple points is no problem.

> OK, here comes the idea how to make the combined dialog in a slightly
> different way - I find the way you propose it a bit too complicated.
> The key idea is that the dialog will consist of 2 tabs - one for
> global commands (I call the ones you call "global" as "superglobal"
> :-)

You should use the proper terminology, you are editing the user's
configuration files in ~/.config or -c , so they are called "user"
configuration, they override the "system" configuration files in
--prefix which would require root to edit and are overwritten when
Geany is upgraded so there is no dialog to edit them.

No global or ...  super global ?!  :-)

 and one for project commands. If no project is open, only the
> global tab appears (or no tab is displayed at all) - the contents of
> the tab will be the same as the current "set build commands" dialog.
> If a project is open, then there will be both tabs. In addition, after
> the opening the active tab will be the tab with project build commands
> (including the graying out for global commands). So when the user
> opens the dialog, he will always see the commands that are currently
> used. I think that in this case the overridden global commands don't
> have to be disabled - the user will have to click the "global
> commands" tab before so he'll know what he is editing.
> What do you think about this option?

I'm not sure what we gain by separating the project and user settings.
 Remember the idea with the new dialog is to have two levels, the
first level simply shows a table with what the menu *does now*, that
is for the current file, for each menu item in order of the menu it

* the label,
* the command,
* the working directory,
* where the command comes from
* an edit details button which

pops up a subdialog with apply, cancel, ok buttons, and fields for the
things you can edit (which is where the plugin configurator and the
built in one differ see below), but only for the one menu item.  This
makes it easy for inexperienced users to see what will happen, and
they won't even have to think about filetypes

Your filetype combo box would be on that subdialog and if you change
the filetype whilst there are changed settings that haven't been
applied you get a prompt to apply or cancel them.  That way there is
no confusion, you can always see what you are saving.  If you have
only one prompt at the end there is no way to see what you are saving.

The list of things that can be edited for each source needs to be
bigger than it is now so that you can configure things like:

* commands to go to "kill" when a build is running,
* where the output of the command goes ( to the parser and the
compiler window, to a terminal, or nowhere),
* which commands can't be run together and so become insensitive
* and more.

Thats why there is a complex and simple version of the dialog, if all
you want to do is add -g to the C compile options you don't need to be
presented with the full capabilities.

Now before you accuse me of making the build system too complicated,
let me point out that most of these functions are available now, I'm
just making them explicitly configurable rather than depending on
position in the menu or some other hidden criteria that is currently
adding lots of special case code, limiting what can be configured and
requiring knowledge of these limitations to configure it.


> Cheers,
> Jiri
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list