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

Lex Trotman elextr at xxxxx
Thu Jun 10 23:18:52 UTC 2010

On 11 June 2010 01:24, Jiří Techet <techet at gmail.com> wrote:
> On Thu, Jun 10, 2010 at 14:59, Lex Trotman <elextr at gmail.com> wrote:
>> 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..
> But why can't these be configured globally? You'll have several
> alternative commands per filetype one of which you chose.

I thought about that in the early days, but it makes the menu too big
and each user has to configure a command for each project they work on
and then remember which command to use.

> complications are just not worth it IMO.
>> 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.
> Could you give me concrete example where you need different
> per-project filetype commands? (And why it can't be solved with
> several global commands?)

It can always be solved with global commands but see above for why
thats not a good idea.

>> 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.
> Ahh, the execute commands are also per-filetype? (I don't use them, so
> I don't know.) But there is absolutely no indication in the dialog
> that they are! Is there any need for that? Now it's getting
> Eclipse-ish (I hope I haven't offended you too much with such a strong
> word ;-). The only person who currently understands how it works is
> you - and that's pretty bad. The whole project configuration needs
> serious simplification.

The per filetype execute commands have been a part of Geany for a long
time, its nothing to do with my build system additions.  A
functionality in non-C languages depends on them, eg for Latex they
start dvi viewers.

In retaliation for your hurtful comment about Eclipse :-) I am going
to suggest you stop trying to remove functionality that you don't
understand because you don't personally use it, and that you RTFM (and
then tell me how to improve it so you do understand :-).

> File types are defined globally, so I would define file type commands
> globally too. You already have three "slots" that you can fill in with
> different commands. Instead of adding file type commands per project I
> would rather suggest:
> 1. to increase the number of slots
> 2. to make the number of slots unlimited

RTFM, hidden prefs

> Then you can add several alternative commands for every file and just
> chose the one you wish in whatever project you are.

And you use global variables throughout your code too I suppose :-)
but effectively you are saying the GUI equivalent IIUC.

 It will also be
> clear what you run - "compile" will always mean the same while now it
> can mean different things for the same file depending on what project
> is open.

Yes, because project 1 uses a different compiler to project 2, its
still compile, you do not want every user to have to configure several
compile commands before they start work on a project and then having
to remember which to use.  And no, using make isn't the answer,
consider one project using python 2.6 and the other using python 3.1,
Python workflow doesn't use make.

Why do these have to be per-project and not per-geany? I have
> serious usability problems with constantly thinking in which mode I am
> (think about why you prefer geany to vi ;-)

Ouch jibes about vi are as hurtful as Eclipse :-) seriously though,
you are not meant to think about it, just use compile and the right
one for your project (or no project) will be used.

>>> 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.
> Projects should be independent, not to have an invisible magical link.

But then each project has a copy of all commands even though they
don't want to change them, so you have to go around and keep all the
projects in sync if anything common does change.

>> 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.
> See above, I would just use several global filetype commands available
> everywhere.
>>>> > 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 think that:
> 1. the GeanyProject structure should be private for the project
> implementation and contain those things that are relevant to the
> session-project (I have similar private structure for my project)

Well, other than specific parts exposed in the API because other
plugins need them, it is private to Geany.

> 2. app->project should contain a structure GeanyProjectSettings that
> contains only those members relevant for geany (from looking at the
> sources, it's mainly base_path - I've seen also file_name and
> build_filetypes_list, but I'm not sure if these are so much
> necessary).

Again, you appear to be commenting on the basis that if you don't use
it, it isn't needed.

> 3. plugins should be able to change the members of app->project (or
> just replace it)

Yes, what API do you need added? Nick and I have both asked, but you
have instead persisted in trying to force your specific view of the
world and not answered the question.

Final comment, all your suggestions are predicated on your view of the
world that one tree = one project. Others have the model of several
projects/variants being built off the one source tree, or several
trees = one project.  Please try to understand that your workflow
isn't the only one supported by Geany and stop trying to prevent

And now I'll climb down off my soapbox :-)


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

More information about the Devel mailing list