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

[Lex Trotman]

> To me this seems to be much better than the current state and would
> solve all the problems I have with the current settings

As I have said just because you have problems doesn't mean that other
people should give up functionality that they use.

 (like the mess
> with the project filetype configuration). As we talked about it in our
> programming language thread - one has to make compromises during the
> design - this solution is very slightly less flexible but much easier
> to understand how it works, which is more important IMO.
>
>>
>>  The
>>> 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 :-).
>
> No, my point wasn't that they shouldn't be per filetype - my point was
> that the dialog doesn't say that! So at least there should be
> something like "execute commands for C files". In addition, the order
> of the groups in the dialog suggests that they are global - first
> group is per filetype, the second group is global and you expect that
> the third group is global too because it follows the global options
> and the title doesn't tell you.


The order of the rows in the dialog matches the order of the menu
items in the menu.

The menu is the same as it was in 0.18, one of the design requirements.

>
> Ideally, I would like to see:
> * Non-filetype commands first
> * Filetype commands + executes second - they would have to be somehow
> visually grouped so you would know they are per-filetype. I think the
> combobox with the currently selected language would contribute to
> making it clear these are dynamic.
>

>>
>>> 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
>
> I'll read it once it's online on geany's web page. But unless I
> overlook something, it's not there right now. But if there is such an
> option, great, no extra implementation needed.
>

If you've got the Geany source then its in the doc directory,
Geany.html, this is kept up to date so even developers don't need the
tools installed to make it from source.

(unless they are editing it of course)

>>
>>> 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 :-)
>
> Nope, I avoid them (for multithreaded server applications anything
> like global variable is evil). For gproject I use only static
> variables per-file which are a sort of alternative to member variables
> in classes.

I'm sure you don't thats why I had the :-)

>
>> but effectively you are saying the GUI equivalent IIUC.
>
> Not quite sure what you mean here.

As I understand, you are saying that the filetype commands should be
global, not possibly dependent on the project, so if I have two
projects which need different commands then the only option I have is
to configure two menu items each with a different command and both of
these will be visible no matter which project is open and even if no
project is open.

 And it is up to me, the user, to remember which project I have open
and select the correct menu item.

If I have misunderstood please explain what you meant.

>
>>
>>  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.
>
> But you can still use the global commands to run python (whatever
> version you want).

See above, I don't want to select, I want Geany to select based on
which project I'm using.

>
>>
>> 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.
>
> No, because you don't have any indication that a command is overridden
> in project. So even you know you saw there was python2 in the project
> properties last week and you know you haven't changed the project, you
> will be running python3 because meanwhile you changed your global
> properties. This is just totally wrong. My suggestion was to drop the
> per-filetype commands from the project, but you can use whatever other
> reasonable way. It just has to be fixed some way.
>

No you've got it the wrong way around, the way it works is the project
overrides the user settings which override the Geany installed global
settings the other way around would indeed be silly.

I don't think it needs to be fixed, I think you've misunderstood.

As for not having an indication of overriding, I AGREE with you and I
keep saying that I intend to combine the two dialogs so that you can
see this.  But it won't start until 0.19 is released.


>>
>>>>
>>>>>
>>>>> 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.
>
> See above, this is confusing. One more idea I have is to have all the
> project filetype commands initially blank - meaning they use the
> global commands.There would be a "copy from global commands" button
> that fills the commands by those used in the global options (to help
> you initially fill the commands).

That may be useful, also when they are in the same dialog then you can
see both and cut and paste so it might not be needed then, lets see.

Currently the global command is shown in the project dialog so you
know what that menu item will run and as a convenience and  since most
of the time you only want to change an option or two, with there being
two dialogs it was intended to be helpful.  I actually tried to make
them grey until you type (like the Google search box before you type
something in it) but it isn't possible with a GtkEntry and a full
TextView for each item seemed an overkill.

As it is, whats shown in the project build tab is what will be run
when the menu item is activated.  Its a compromise with two dialogs
which is why I want  to combine them.

 Once the filetype commands aren't
> blank in the project, it means the commands override the global
> commands. With this you'll know when some commands are overridden or
> use the global settings.
>
>>
>>>
>>>>
>>>> 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.
>
> Don't take the list of required members of the settings structure I
> mentioned too seriously - others are reasonable for all projects too
> (but some are not and these should be private). Regarding the rest,
> see my comment below.
>
>>
>>> 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
>> others.
>
> I think you misunderstand the message behind my comments (and possibly
> I wasn't expressing myself clearly).
>
> The only two things I want is:
> * to have simple and understandable settings dialogs with clear semantics

See above

> * every project management plugin to have the same rights as the default one
>
> The rest were just the means of how to achieve that. I'm not strictly
> against per-project filetype commands; what I want to say is that IMO
> the additional extra flexibility doesn't justify the confusingness.
> But see see what I suggest above as the solution that preserves
> per-project filetype commands. Regarding project management plugin, I
> don't want to take over all the functionality of the current project -
> some of its features interfere with the features of my plugin. That's
> why I want to to have one "project superclass" implementing the things
> common to all projects and let the concrete implementations do the
> things their (possibly different) way.
>

Thats one way to do it.

But if Nick feels that the existing project system is hard to take
out, then I would listen to his experience, he knows it better than I
do.

Instead could you please enumerate where it interferes with what you
want to do, so that the relative effort of preventing the interference
vs major change can be assessed.

And can you please specify what you want to do in terms of setting
commands so I can ensure that the new API can do what you need.


Cheers
Lex

>>
>> And now I'll climb down off my soapbox :-)
>
> Was not necessary to climb up :-).
>
> Cheers,
>
> Jiri
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>