[Geany-Users] Multiple projects support?

[Lex Trotman]

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