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
[email protected]
https://lists.geany.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.geany.org/cgi-bin/mailman/listinfo/users
