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

Lex Trotman elextr at xxxxx
Sat Jun 12 00:59:46 UTC 2010

On 12 June 2010 10:15, Jiří Techet <techet at gmail.com> wrote:
> On Fri, Jun 11, 2010 at 14:07, Lex Trotman <elextr at gmail.com> wrote:
>>> 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.
> This is the point where one has to make a choice:
> 1. Start a flame war that won't lead to anything useful
> 2. Give up despite being convinced about something different and try
> to find a solution that's acceptable for all
> I have chosen the second option (even though the first is tempting too
> :-)

Awww, you're no fun ;-) but thanks for being constructive

so forget all I have written about removing per-filetype options
> from the project settings dialog.
>>> 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.
> I would prefer an inconsistency with the menu (nobody will notice) but
> have per-filetype commands grouped.

I don't know that nobody will notice, and I personally very strongly
prefer them to match, after all what you are doing is configuring the
menu, lets see what others think after they have used it a bit.

>> The menu is the same as it was in 0.18, one of the design requirements.
>>> 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.
> Of course, I understand it this way. The above paragraph says that you
> look at the project options thinking that these options are valid for
> the project only, but in fact, they are global and change whenever you
> change the global options.
>> 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 asked twice already without much detailed response so I'll ask again
> - could you describe how you imagine this will work? For instance, I
> have no idea how you plan to make both the project options and the
> global options editable for the same command in the single dialog if
> project is loaded (without making the dialog too scary). You might
> consider what I propose below instead.

There will be two dialogs, one built-in which provides the main
capabilities in a simple package.  As you say, seeing all the
possibilities might be scary the first time, so that dialog will be in
a plugin and will be multi level.

As to exactly what is in the simple dialog, thats not yet finalised, I
have already suggested that there may be some "robust" discussion on
that, all suggestions welcome :-)

ATM I am in the middle of trying to get the greying out to work again.
To get into 0.19 any change must be minimal and must not change
strings, which rules out new buttons.
If I can't get it to work, then I will probably go with leaving them blank.

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

BTW what you are editing in the "set build commands" dialog are user
settings not global ones, the global ones are in system directories
and would need root to edit.

>> 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.
> OK, a better idea than the one with "copy from global commands" -
> initially you could make all the edit boxes inactive but containing
> the global per-filetype options (so you see what is used). There would
> be an "override" button that would activate all the edit boxes and
> since then, these would be copied to the project and override the
> global options. The override button could be a toggle button - the
> second state would be "use default" that would just delete the
> override from the project, deactivate the edit boxes, and return back
> to the global settings for the filetype. This is explicit, has clear
> semantics and shouldn't cause any confusion. If the per-filetype
> options are grouped together and if there is a clear indication that
> these are per-filetype (I suggest the combo box), then I'm perfectly
> happy about this solution. What do you think?

Too big a change for 0.19 IMO, after that, maybe, but see other proposal below

>> 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.
> But if I understand it correctly, this won't make it possible to edit
> both global and project properties if the project is loaded. Also all
> project settings should be definable in a single dialog. Everything
> else is the "lost in dialog hell" I was talking about.

Yes, project properties and set build commands should show the same thing.

You will be able to edit either, as I said above the complete dialog
will be big and the exact operation of the simple one is still up for

My current thinking is that the dialog that is shown is read only and
shows what will actually be run, and then there is an edit button
which shows a sub-dialog. If a project is open the subdialog has two
sets of fields, if no project then only one set, or the project fields
are insensitive (which I think is better GUI design practice since the
user can see where that info will be edited when the project is open)

For the first dialog, suggestions on how to simply show where that
setting comes from are welcome, the simplest is of course to just say
"from project", "from user", "from global" or whatever but it does use
a bit of space.

>>> * 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.
> See my talk with Dimitar (I know you did, thanks for the hint, I've
> completely overlooked that you get GKeyFile as the parameter) - my
> thinking about how to integrate my project management to geany has
> changed a bit. With GKeyFile of the settings available, which I
> thought was the most serious missing thing in the interface, I could
> actually start changing the implementatiton and see what else is
> missing on the way (there is already some missing API mentioned in the
> reply to Dimitar - unless I overlook some more functions and data
> structures).

Sorry, maybe I'm going blind, all I can see is the settings question.


> 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