Hi, 2009/10/18 Lex Trotman <[email protected]>: > 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: > > 1. 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. > > 2. 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 <[email protected]>: >> 2009/10/16 Enrico Tröger <[email protected]>: >>> 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 >>> [email protected] >>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel >>> >>> >> > _______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
