On 11 March 2010 04:53, Nick Treleaven
<nick.treleaven@btinternet.com> wrote:
> The current trunk arrangement has one major problem though, the project
> settings and the non-project settings are configured in separate dialogs,
> having settings that interact in different places is very poor user
> interface design (which I accept responsibility for creating). I want to
> put them in one place.
What about just making the 'Build->Set Build Commands' menu item show
the Project Properties dialog with the Build tab displayed?
I don't want to have a build tab in the project properties dialog any more since that still shows things in two places, but project properties can have a button to show the "set build commands" dialog, then whichever way you start it, everything is shown.
> > > 5. for execute commands only, the option to run without terminal,
> > checkbox
I think this is OK, just squeeze in a checkbox after the working dir
field. Maybe just the tooltip can explain what it's for?
Ok, I was having trouble fitting it :-)
> > > Things to not make available (to avoid "dialog shock"):
> > >
> > > 1. edit menu item label
Hopefully my button solution (see new mail) should allow this without
being confusing.
As I said on that one, I'm not sure, but am happy to do it if everyone thinks its a good idea. I just thought of another alternative, see second reply to other mail.
> > > 2. which commands are parsed and which are not
> > > 3. which commands are stopable and which are not
agree
> > > 4. extra commands in sections (propose simple dialog allows editing 2
> > > fieltype,3 make,2 execute)
not sure what you mean, but I think trunk is good.
Hmmm, what I was doing was leaving out the extra commands in the filetype and non-filetype sections to get back two lines, so the dialog doesn't grow too much when the three project makes are added. Although I do most of my work on a machine with two big screens I also test on a machine with a little screen and the dialog is getting up there so lets just see what will fit.
> > > 5. change internal command locations (next/prev error, show dialog)
agree
> > > 6. project filetype commands (just so the dialog is smaller)
It might be worth keeping these. They're shown for the non-project
dialog anyway.
As above, purely for the reasons of dialog size, also note again that I don't want a project and a build menu dialog, just one dialog, sorry I wasn't clearer on this, 8. below attempts to explain why you need to see it in one place.
> > > 7. parsing regex per command, source or global
Hmm, I see it would be useful/better but not sure yet. Certainly needs
to be unobtrusive.
> > > 8. viewing settings from non-editable sources ie default, system
> > filetypes,
> > > plugins/internal
Don't really understand this.
The command that is executed when you activate a build menu item is determined by the highest priority source that has an operation configured for that menu item. Sources (highest to lowest priority order) are:
internal, eg a plugin, not saved by Geany
project filetype entries, from project file
project non-filetype entries, from project file
user filetype entries,from ~/.config/geany/filedefs/filetypes.*
user non-filetype entries, from ~/.config/geany/config.conf
system filetype entries, that is ${prefix}/share/geany/filetypes.*
defaults, hard coded in geany
You can only edit project and user ones so they are the only ones shown in the dialog normally. It is important to show both project and user at the same time since project overrides user and it can get confusing when you change a setting and have nothing happen (been there done that, even while I was just testing the trunk version!!). But since entries from the other sources can also interact, the plugin config dialog has a button to show the configuration from these sources as well (but insensitive) so that you can see if they are overriding something you are setting. This gives the full "dialog shock" display so I proposed that the simple dialog does not have this ability.
Cheers
Lex
PS Nick, thanks for your input, its appreciated that you take the time to think about it and suggest things.
Regards,
Nick