Hi Enrico,
2009/10/13 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 12 Oct 2009 16:49:43 +1100, Lex wrote:
Hey,
In the new build system there are more execute commands than in the old system:
- from system filetypes files
- from user preferences filetypes files
- from user preference
- from project filetypes in the project file
- from project preference
The cause of the issue you've identified is because modified execute commands are treated as a user preference rather than as a filetype. Its actually documented in the manual this way (see the table in 'build menu configuration') and it notes that you can't set the filetype dependent execute commands using the dialog.
Because the dialog doesn't have any way of selecting if the user is changing the preference/project setting or the filetype dependent setting a decision one way or the other had to be made. I don't remember why this particular decision was made, but I see two "solutions":
- Since projects are most likely to have an execute command
independent of the filetype and non-projects are more likely to be dependent on filetype we could have the execute commands set in the 'build commands' dialog set the filetype preferences execute not the preferences execute, but the execute commands in the project 'build commands' dialog set the project execute not the project filetypes execute, but this is potentially confusing (I'm confused just writing it)
- Or I can try to get Enrico to agree to adding one itty bitty teeny
weeny little checkbox to the build commands dialog to make the selection, I'll put it on the same line as the execute commands header and it won't make the dialog any bigger I *promise*. :-) It will
Putting things very close together won't help making better UIs...it's not about size, it's about complexity.
I guess I'm not the best to judge since I designed it and understand the underlying ideas, but to me just having lots of repeated rows of the same thing isn't complex, it just shows that there are several things to be configured.
Your point about crowding the dialog is true, I was thinking about making the title of the execute section say some thing like:
Execute commands [checkbox] for filetype xxx,
where the filetype xxx could grey out if the box was unchecked and so the commands would be stored in the geany.conf which is filetype independent (see further explanation below)
Or maybe its better for the whole section title to be a combo box choosing between "Execute commands for all filetypes" or "Execute commands for this filetype only". I think thats clearer and it will translate better.
Let me know what you think.
No idea, really. I somewhat prefer 1) as it is closer to the previous, original behaviour which I believed we wanted to keep. Maybe I missed the decision against it in one of the thousands mails about the build system stuff. If so, my bad.
Though I remember saying myself a couple of times I wanted to have it as compatible as possible and to not change the default behaviour when not absolutely necessary.
Much of the "thousands of mails" was me trying to understand the existing behaviour, you designed it and so it was obvious to you, but although I sort of knew what it did, all the implications were not obvious. And clearly I still missed some :-)
Why the hell does one need so many different types of Run commands you
Please note this is me trying to explain clearly, because to me its not complicated, but clearly that hasn't been communicated properly. It is often hard to describe flexibility without it sounding complicated or so obvious its insulting to explain it.
- from system filetypes files
Thats the standard behaviour
- from user preferences filetypes files
Thats so a user can edit the behaviour without changing system files or impacting other users.
- from user preference (geany.conf)
As soon as there is more than one file in the program, the run command is usually no longer dependent on the file, you usually want to run the main program. You don't want to have to always switch back to the "main" file before selecting run, so the command needs to be able to be set somewhere that is file independent
- from project filetypes in the project file
Same argument as for user filetypes, but only set for the project
- from project preference
Same argument as for user preference, but only set for the project
From here on numbers refer to items in the list above
The old system already had 1,2 and 5. The lack of 3 I found really annoying because I constantly forgot to change back to the main file. And an example of a good use of 4 is to set the project and only the project to run using python3 whilst everything else is still python2.5.
None of these seem unnecessary to me.
listed above? I loved the old behaviour so much where I just opened a file and could execute it, without configuring anything and without thinking about which of the thousands things it could do now...
(Sorry for sounding a bit harsh, probably I should have done deeper testing before the merge but well, it doesn't make things better. We, at least I thought so, tried to keep things small and stupid...maybe we left this way without noticing.)
Well it *should* still "just work" by default, the only problem you've got is that the configure dialog edits 3 not 2 and the more we talk about it the more obvious it is that there is a need to choose which one to edit rather than having it fixed (whichever way we fix it it will always be wrong for someone).
The combobox I described above would choose to edit 2 or 3 in the build menu "set build commands" dialog and 4 or 5 in the project dialog "build" tab.
Furthermore, the Compile button is disabled in the toolbar. But this seems to be a separate issue :).
AFAICT build.c doesn't know about the compile toolbar menu button, or the execute menu button for that matter, it only knows about the build toolbar menu button and the compile, build and execute actions, so I don't know what is setting the sensitivity of the compile and execute menu buttons.
The action is the toolbar button, at least it is the parent instance which creates the actual button widget for the toolbar. So, setting the sensitivity of the action, implicitly changes the sensitivity of the toolbar button widget. And the action's sensitivity is changed at the end of build_menu_update(). And at some point, this worked.
I didn't realise that the gtkaction controlled the widget, I've read the documentation and learned more GTK :-)
The problem is that can_compile and can_build have been combined into one, so for python it is wrong because it has a compile but no build. I had tried to copy the logic from the old build_menu_update and can_compile and can_build *seemed* to be the same tests so I used the same value.
Clearly they should be different. Fixed in SVN.
BTW should the set sensitive for widgets.compile_action, build_action and run_action be protected from NULL or do the actions always exist?
Cheers Lex
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