On Fri, Jul 9, 2010 at 03:37, Lex Trotman elextr@gmail.com wrote:
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.
On the other hand, we could easily overdo it with plugin API generality. Geany should definitely not become Eclipse written in C. In my opinion the current approach of introducing API functions on demand is alright. The amount of things the plugins can already do is satisfactory for most of the plugins I guess. My plugin is a bit exceptional in being the first plugin that extends the project management of geany and therefore needs some extra functions and signals for that (not so many though, most of the patches are just general geany improvements). And talking about every single additional API function with geany developers is good in the sense that the given function is considered from more viewpoints and sufficient brain time is spent before introducing a possibly nonsense function into the API. Also introducing API functions in advance can cause that these functions are poorly tested because there's nothing that uses them. I also like that the API is restrictive a bit - plugins shouldn't be able to modify geany completely so it becomes a different editor - they should just extend it in a certain way.
But I don't have anything against looking at how others do it - there are surely good (and bad) lessons we can learn. If I should say a single thing I dislike about how plugins are implemented in geany (and there's actually only this single complaint), it is the fact that by including geanyplugin.h I also include lots of function prototypes that don't belong to the API. It happened to me several times that I copied some code from geany into my plugin, compiled it without any problem, but then the plugin didn't load because the function I used was not a part of the API. Some macros or whatever should be used to prevent non-API functions and data structures from being included by the plugins.
Cheers,
Jiri
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 _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel