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
- 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. 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.
This are just my ideas so far. I got now experience in GUI programming so I am not sure how far I will get. 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.
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