On Thu, Jun 10, 2010 at 12:35, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 19:44, Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 03:07, Lex Trotman elextr@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:
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