[Geany-devel] project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

[Jiří Techet]

On Thu, Jun 10, 2010 at 12:35, Lex Trotman <elextr at gmail.com> wrote:
> On 10 June 2010 19:44, Jiří Techet <techet at gmail.com> wrote:
>> On Thu, Jun 10, 2010 at 03:07, Lex Trotman <elextr at gmail.com> wrote:
>>> Hi,
>>>
>>> Note to self, read the whole thread before replying to any :-) see my
>>> other reply plus below.
>>>
>>>
>>>>> Yes I realised a while ago it can be confusing, thats part of why I
>>>>> want to combine both dialogs into one in v2.0.
>>>>>
>>>>
>>>> Yes, it's pretty confusing. Once you create a project you don't expect
>>>> that what you see in the build tab changes based on what change you
>>>> make in the global settings (until you modify the commands in the
>>>> project for the first time). This makes the project totally unportable
>>>> because it depends on the global settings of the current instance of
>>>> geany. So if I move the project from my home computer to work, things
>>>> just can stop working because I have different global settings there.
>>>>
>>>> What I would suggest is that upon project creation you make a complete
>>>> copy
>>>
>>> Thats just what I didn't want to do, remember there are filetype
>>> commands and execute commands too makes each project copy big.
>>
>> Then I would suggest that there are no per-project filetype commands
>> and you just copy the global ones. In project you care about a set of
>> files so global/general/non-filetype options are the ones you want to
>> change. This seems to be the most reasonable solution now.
>
> No, that doesn't handle when projects use different compilers or
> targets compared to the default ones, changing the commands in the
> build dialog when swapping between projects is tedious and error
> prone.

I like keeping things simple, especially for features that are not
used so frequently. I've *never* ever used the option to compile a
single file of a project in any IDE - I've always compiled the whole
project (or its subsystem). I imagine that it can be useful for
individual files, but it's really not much useful for the project, so
I would just remove it for the project.

One just shouldn't overdo it with trying to be as generic as possible.
If you wanted to create a super-customizable project, you would have
to add all the extensions from filetype_extensions.conf (by the way
how does the project handle the case when some file type is defined in
the project but not in filetype_extensions.conf?) and many other
options.

>
>>
>> But really, think about how this is agains anything the user would
>> expect. What the user sees is that:
>>
>> * sometimes changing the command in the "set build command" dialog
>> changes the settings in the project
>
> The set build commands *never* changes anything in the project, where
> defined, the project command overrides the normal ones.

But there is *no* indication that something has been overridden in the
project properties dialog. The user has to open the project properties
file to see it; otherwise the behaviour is totally unpredictable. If
you defined a project two months ago you just forget which commands
have been overridden and you have no clue what you are looking at in
the project properties dialog - the overridden value or the default
value.

>
>> * sometimes it doesn't change the project
>>
>> and he has no indication when this happens (there is no indication
>> that the settings has been overridden in the project dialog so it's
>> just invisible). This is totally stupid.
>>
>
> This is unproductive, I've already said this UI is proposed to change,
> just repeating its bad gets us nowhere.

Sure, that's why I'm proposing the solution above. It would be good if
you could describe how the united dialog should operate because right
now I just have no idea how it could help.

>
>>>
>>>  of the global settings and since then the two are edited
>>>> independently. Otherwise all the settings is a total mess.
>>>
>>> And you program in C++ !! I'd have thought overriding some entries
>>> only would be easy to understand :-)
>>
>> Yes, but I didn't say I like C++ - I don't. The language is made in a
>> completely wrong way. Unfortunately the fact is that it's one of the
>> most wide-spread "low-level" OO languages with lots of libraries
>> existing for it and programs written in it. But I really hope that one
>> day it gets replaced by something like go:
>>
>> http://golang.org/
>>
>
> And I'm not getting into an argument on languages
>
>> But the fact that C++ does things in a stupid way doesn't mean we have
>> to do it too. We can't change C++ but we can make geany to be easy to
>> use. I prefer simple and less flexible GUI that is easy to use than
>> complex "I can do all" GUI that nobody understands (and that's geany's
>> philosophy at least from what I have seen). So as I said, I would just
>> remove the filetype options from the project settings.
>>
>>>
>>> Seriously, yes the whole thing should be in one dialog so that you can
>>> see what overrides what and edit the one you want, thats part of v2.0.
>>>
>>
>> No, seriously, it shouldn't. How will it work with different project
>> plugins? Please describe how you imagine the dialog should work so I
>> can tell you why it's not a good idea ;-).

I hope you didn't take my last sentence too literally - I just can't
imagine how this would work so I'd like to know more details about it.

>
> As I said many posts ago, there will be an interface for plugins to
> set the commands to be used, so use your own dialog, the Geany dialog
> will just note that "This command has been set by the xxx plugin" or
> similar message.

I just hope it won't be like that - the plugins should use their own
set of options separate from the global (default) options. If you do
something like that, how will you edit the non-overridden command?

(A note: I really don't want this thread to become a flame war. I'm
just unhappy how things work now and would like do find the most easy
to use solution acceptable for everybody.)

Cheers,

Jiri