Hi Jiri
Remove the "set" button from the project properties dialog
Unless I miss something the button just adds %d to the corresponding fields, but this is already the default settings so I don't see any point of doing it.
I think so too.
I was wrong about %d being default (it was set this way in my global settings) but I still don't like the button much. First it takes too much time for my brain to understand what the long label says, second it's no problem to set the %d manually. But I don't care too much about this particular patch.
It actually sets them to %p not %d, but I agree that it should go, someone wanted it to give a single click replacement for the checkbox that was there (in 0.18 and before) but I think its confusing.
Use relative paths in the project files
Hmm, I thought there was something like this already, but haven't checked, so maybe.
No, there's nothing like that. I understand that using full paths may be useful in some special cases to move the project file separately from the project files to a completely different place without breaking things, but in my opinion being able to move a project together with the project file to a different directory (PC) without breaking the paths is much more useful.
I'd find that very useful, second the motion
(The patch (mis)uses short evaluation of boolean expressions in C so this is probably what you have overlooked.)
Its a perfectly valid use and a widely used idiom, don't apologise for it.
The "find in project files" item is identical to "find in files" but always using the project's base directory no matter what file is active.
The reason why I think it's better to put these entries into the project menu is that when the user uses my gproject plugin, it is completely invisible for him that it's some kind of extension of geany
- everything is integrated to the current project handling and it
would look a bit strange if some entries related to the project would be under the project menu and some under the tools menu.
Totally agree, Geany doesn't (yet) support plugins integrating themselves fully into Geany, but its something that needs thinking about as a general capability to allow a more seamless user experience, maybe we can look at how tools like Firefox do it.
The problem with the current approach is that each time someone comes along with a good idea they have to request access to parts of Geany from the primary developers and then there is a discussion of what is right to make available or add to the core. All of which wastes the core developers time and reduces what else they can do. A more general plugin system would save them having to do that.
One more thing that might be needed by plugins (but which isn't needed by gproject so I haven't added the API methods) is the ability to add their own validators of the dialog entries the given plugins added. There could be something like register_validator() and unregister_validator() whose argument would be a pointer to the validator function. Geany would keep a list of these pointers and run all the functions to see if everything is valid before it sends the above signal. The functions could also return some error string used by a pop up error dialog. As I said, I don't need it but could be added when some plugin requires such a functionality.
This is a good idea that needs to be addressed as part of an overall discussion of how plugins integrate with Geany. I guess when everyone gets some time :-(.
Cheers Lex