Hi,
2009/10/18 Lex Trotman elextr@gmail.com:
Hi all,
I had a email directly from one of my colleagues who has been reading this thread and had a question about the project filetype execute commands.
Here is part of her email (project name obscured to protect the guilty :-)
This looked exactly like what we need for the XXX project where it has to still support Python 2.4.
Since most files are coded with "if __MAIN__ then:" test code for this module, we want to run both the individual file to run the test code and we want to run the overall application.
From what you said if I edited the project file directly we could have both a filetype dependant and a non-filetype dependant command for the project which ran Python2.4, and when that project was closed everything would use Python3 as usual, perfect!!
Unfortunately I can't get project filetype executes to work at all and looking at the code I can't see where they are handled.
This raised two points:
- the project filetypes execute commands code is missing completely,
I have it in an old version in my personal bazaar repository but it never made it into SVN.
- because we have more than one execute command is it possible for
one to be filetype dependent and one to be non-filetype dependent. In fact it is and it works fine when there is no project open, but as discussed previously the dialog won't edit the filetype ones at the moment.
for 1. I will fix it first since it is a pre-requisite for the suggested solution to 2., this may also allow some simplification of the implementation due to better consistency.
Done in SVN. Didn't get any simpler though :-)
for 2. I had never considered having mixed filetype/non-filetype commands, but as my colleague has said it is reasonable, and she has identified a use for it already, and it already works for non-project commands (I tested it with HEAD)
But it did cause me to think about how the dialog should work. After much thought I suggest (I'll keep it as short as possible Enrico so I won't mention any alternatives)
There are four sets of execute commands to edit, project vs non-project which is addressed by having separate dialogs and for all filetypes vs for a specific filetype which is to be addressed by the "unobtrusive" check box selecting which is being edited.
In line with current practice if any command is overridden by a higher priority one then the higher priority one is shown but it will be insensitive. This ensures that the dialogs always show what will appear on the build menu when ok is selected.
If you edit a setting and switch the checkbox, the edit is saved in temporary storage until OK is clicked, so you can flick between all filetypes and filetype specific settings as many time as you want.
I made a prototype of this dialog, its terrible, very confusing, hard to tell what you are editing.
So I have made a temporary change in SVN to make the dialog save to the fieltype execute command for the build menu->set build commands dialog. The project dialog still stores execute commands for all fieltypes. This is how it used to work.
I will now take some time to look at an alternative build-system configuration dialog.
Cheers Lex
Cheers Lex
2009/10/16 Lex Trotman elextr@gmail.com:
2009/10/16 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 15 Oct 2009 06:08:08 +1100, Lex wrote:
Hey guys,
I don't have time to intensively answer your mails although I'd like to. Though my answer will be rather short, hopefully still clear and concentrating to the important things. I guess you'll tell me if not, haha :).
Yes, the dialog edits something different to what it used to, whatever is decided that is likely to be changed.
But it should not only allow one way of working, it may make one group of people happy, but it makes another group unhappy. Just because you don't use the particular functionality doesn't mean it isn't needed, so I have proposed a way of allowing either instead of cutting off options.
I am trying to discuss how to make the default behaviour the same as it was previously without losing access to the extra functionality.
The discussion is how to implement that.
That's a ) normal and b) absolutely ok. It's almost always about finding a compromise between different needs and wishes when it is about implementing new features.
This is exactly what expect (and want also).
The requirements were determined through "thousands of emails" to quote Enrico (again :-), that something was misunderstood has been acknowledged, constantly pointing things out with 20/20 hindsight is no help in defining a suitable solution.
Full ACK. We already noticed there were small communication problems (:D), anyway, just let's concentrate on how to make it better for the future.
To reiterate:
The build system does not do anything wrong, a dialog edits a different setting to what it used to and the build system does what that edit tells it to do.
I have suggested a change to the dialog that allows it to default to editing the settings as it used to so that the build system will behave as it used to, but still allows access to edit the other settings for those of us who want to use that functionality.
I'd prefer the checkbox, at least it'd be better than a combo box. I see why you suggested the combo box and it's rationale but just not nice. A checkbox next to the title is probably less intrusive and less diverting, I think.
Ok, I'll make a prototype with checkbox
Oops, found a crash ... fixed in SVN, prototype tomorrow (maybe).
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