On Thu, Jun 10, 2010 at 01:25, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 07:02, Jiří Techet techet@gmail.com wrote:
On Wed, Jun 9, 2010 at 18:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
Any suggestions on how the manual could be improved, it should be RTFM, not RTFS :)
I assume you mean the 'Set Build Commands' dialog when you have a project open. I think that may be a bug - IMO the Project Properties Build tab should be shown instead. It is confusing ATM.
There are several confusing things:
- The first section in the dialog ("filetype commands") depends on
the currently opened document. This wasn't clear to me at all. First I thought that this was static. Then I noticed that it changes but I was wondering how you set the file type. I would prefer if there was a combo box where the item gets automatically selected based on the current file, but which you can also manually change. This will give people some indication that the first group is dynamic.
Its how Geany has already worked, the commands changed with current filetype.
Well it does actually say "filetype xxx commands", but your idea isn't impossible either, but see questions below.
I know, but it's not clear it's dynamic. Also if you want to change the commands for N file types you have to locate N times the file with the right extension and then open the dialog - not much fun.
- What you say - when the project is open, it's not clear whether you
are editing global options or project ones. IMO by build->set build commands you should always set the global options and in project properties the project options.
Thats what should happen, if you think it isn't its a bug, let me know
Well, that's what I was talking about in the other email - if you don't override a command in the project, it appears as if you were editing both the global options and the project options simultaneously - that's really way too confusing.
Things get confusing when you start
changing semantics of menu items based on whether the project is open or not.
- The popup dialog for "make custom target" should be more flexible,
not hardcoded for item 2. I think there should be a new variable, e.g. %t, which, when found inside command, causes that the window appears and then substitutes %t with what the user specifies. This will make it usable for other commands too.
Agreed, already planned to be added for v2, %c{message to show on popup} gets substituted by user input (I used c for custom not t for target :)
- non-filetype commands deserves a better name - I quite like your
"general" commands ("global" could be confused in the context of setting global/per-project options). And I would also put them first in the dialog - starting from general options to more specific options (which means that execute command should come second). I had a problem that somehow automatically I started editing the commands in the first group (filetype) even though I wanted to edit the second group (non-filetype).
Well the order has the 0.18 items first for backward compatibility, but I agree that the order isn't optimal so I planned to make it configurable (I actually want some more groups) but I havn't got a good solution for the headings (other than fixed strings, which would let you change "non-filetype" to whatever you want :) Personally I think "general" is a bit too, well, general, to be meaningful
If I can ask for something, then please don't add any extra options to the dialog. It's already confusing enough ;-).
I know general is too general but non-filetype is so specific that nobody can imagine anything concrete under it. Unfortunately I'm pretty bad at naming things in a good way so I won't help much here.
OK, I wanted to write more things I dislike but after spending one hour looking at the dialog I think I start understanding what's behind it. There really needs to be a clear indication that the first group is dynamic and I think the combobox is a good way to do that.
But what do you do if the user changes the filetype? Do you forget any changes so far? Or you have to save them in temporary storage until the user selects apply or cancel and hope that the user meant to change both filetypes rather than starting to change one, discovering that they had the wrong type (because of the wrong current doc) and changed to the one they want. Thats why both dialogs are modal, so the current document can't be changed, so this section doesn't change.
Good point. I would probably pop up a question dialog asking whether the changed settings should be saved when the user switches between filetypes and makes some modifications (the dialog shouldn't appear if there is no modification).
Cheers,
Jiri