[Geany-devel] Build system glitches

[Lex Trotman]

Hi,

2009/10/18 Lex Trotman <elextr at 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:
>
> 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 <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
>>>
>>>
>>
>