[Geany-devel] Build system glitches

Tue Oct 13 00:27:31 UTC 2009

Hi Enrico,

2009/10/13 Enrico Tröger <enrico.troeger at 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:
>>
>>1. from system filetypes files
>>2. from user preferences filetypes files
>>3. from user preference
>>4. from project filetypes in the project file
>>5. 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":
>>
>>1. 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)
>>
>>2. 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.

>>1. from system filetypes files
Thats the standard behaviour

>>2. from user preferences filetypes files
Thats so a user can edit the behaviour without changing system files
or impacting other users.

>>3. 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

>>4. from project filetypes in the project file
Same argument as for user filetypes, but only set for the project

>>5. 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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>