[Geany-devel] Build system glitches

[Lex Trotman]

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.

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.

Cheers
Lex

2009/10/16 Lex Trotman <elextr at gmail.com>:
> 2009/10/16 Enrico Tröger <enrico.troeger at 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 at uvena.de
>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>>
>>
>