Hi Lars,
Like Chris I don't need the feature so I am unlikely to contribute any actual work on it, but here are some comments.
First, one of the potentially problematic areas is the build commands, one of the other devs did a bit of experimenting with using libclang to provide completely accurate completions and so on. That means he needs the exact build commands since libclang needs to know about includes and defines. There is a PR where we looked at possible options that would allow a plugin to manage its commands. Not sure what state its in, but maybe you could find it and at least read the comments.
On 15 June 2017 at 06:33, Lars Paulsen lars_paulsen@web.de wrote:
Hello,
thanks, sounds good and fair (did not expect anything else from an open-source project :-) )
Right now it's just some brainstorming. I very roughly thought about this things:
- the plugin has to manage it's own files:
- a major file for storing the assigned projects (call it a project
container/list/workspace/solution... whatever)
- not sure if the structure of a single project can be kept but it would
be needed to assign files to it
Plugins normally store their stuff in ~/.config/geany/plugins/your_plugin_name which is a directory so you can save anything you want. Geany tends to use .conf files for storing stuff since the Glib library provides key-file handling, but it only has one level of hierarchy leading to hacks like "structured" field names to increase the depth, YMMV.
projects need to have capabilities/properties
the plugin should support copying of properties from one project to
another or maybe cloning an existing project
- I like the possibility to customize the commands using the placeholders
%d, %e, %f, %p , and %l. One idea I have is to make this extendable. E.g. plugins could some kind of register own placeholders to use.
Thats a good idea, I can see several uses for that, but one problem with this sort of thing is how do you mediate between plugins to say which gets which placeholder? For example currently there are multiple plugins using markers, and they can't run together since they both try to use the same marker numbers.(I think its bookmarks and debugger, not sure)
I would prefer a kind of variable names for it (not just single letters) but that is maybe not backwards compatible. But the principle is that users should be able to assign properties to the projects which could be mapped user-defined placeholders.
%c for shortnames %{longname} for longnames maybe, just save the values in a std::map and ... oh wrong language :(
But the Glib library provides BBTs or key-value files for a persistent version.
This are just my ideas so far. I got now experience in GUI programming so I am not sure how far I will get.
Possibly get the functionality working first just with user (you) editing the config files (thats the other reason for Geany using .conf, they are fairly human readable). Then you can play with the GUI. That way you don't keep re-working the GUI as you discover changes to the functionality are needed.
But I guess "GeanyPrj" and "Project Organizer" are good examples/templates to start from. Also the GTK documentation seems to be very good (at first sight).
So that's all from my side so far. Thanks for the answers.
Good Luck Lex
Kind Regards, Lars
Am 14.06.2017 um 22:00 schrieb Colomban Wendling:
Hi,
Le 14/06/2017 à 10:01, Lars Paulsen a écrit :
[…]
Would it be theoretically possible to write a plugin for that? Or do you know any design constraints which would make this impossible?
I thought GeanyPrj allowed that, but as I never used it myself I can be wrong. Anyway, I don't see an obvious reason why a plugin couldn't do this, but it probably depends on what coupling with Geany's projects it would like to have, as Geany itself can really only have one of its "projects" open at once. But nothing should stop you from having a separate representation of the projects somehow, or some kind of dynamic open/close etc., or whichever design you choose. And know that although it might not be a super fast process because we're all volunteer with our own lives beside it, we generally are happy to expose the API plugin authors needs if it sounds reasonable to us (e.g. has a "valid" use case and no obvious problematic consequences).
Regards, Colomban _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users