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

[Lex Trotman]

On 10 June 2010 21:23, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> On Thu, 10 Jun 2010 11:44:24 +0200
> Jiří Techet <techet at gmail.com> wrote:
>
>> >> 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.
>
> I have argued that project filetype commands are useful, but you have a
> good argument here. Perhaps the complexity is not worth it when project
> non-filetype commands could suffice.

You could probably make an argument that non-filetype commands are
sufficient for C/C++ and other "building a big thing" type languages,
but other filetypes supported by Geany are more centred around the
individual file.

And don't think just in terms of compile/link type operations.

I don't think that the potential uses of filetype commands have been
explored much, even for C/C++ there is code analysis tools,
prettyfiers, hey I'm giving myself ideas here..

And then it becomes important to be able to configure them per
project.  Also don't think of it as one project file per source tree,
I'm using multiple project files to save the differing configurations
when using differing tool sets for the same source tree.

We also have the filetype dependent execute commands to consider,
pointing to the executables in the build directory rather than in the
source directory is likely to be common.

>
> I also like the copying non-project commands into the project idea.

Makes the whole thing easier to implement of course, but then for the
common things, the user has to change it in all project files.

I don't think its a good idea for filetype commands though, and even
for the executes it is a bit of a load copying all languages just to
edit one.

>
>> > 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 agree with Lex here but only if editing non-project commands when a
> project is open is necessary.
>
> Geany's project concept is integrated in a number of places, not just
> for sessions or build commands. Project plugins should not aim to take
> over Geany's project functionality, but work alongside it IMO. That may
> require API additions, but less so than rewriting all Geany's
> project functionality.

I don't know if you want to put what I'm about to say in a new thread,
but I think that there is a lot of potential for adding a lot of power
and usability in the grouping of the session management features, with
Geany project/session features, with the ideas in Jiris plugin, with
the ideas in the build system.

But there is also potential for the overlap of these implementations
to become a source of friction.

Maybe there should be a bit of top level design over how these are all
incorporated (even if parts are plugins, Jiris project and my
complicated make configurator, as Jiri points out they need
appropriate facilities in the core and access to them)

For instance is it worth while separating the session part of the
inbuilt project so that it can be made to work nicely with/without the
sm code (which IIUC won't work on windows so the old session is still
needed).  Then the project features of the project system are separate
and don't get confused with the session part.

Cheers
lex

>
> Regards,
> Nick
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>