[Geany-Users] Multiple projects support?

Lars Paulsen lars_paulsen at xxxxx
Thu Jun 15 06:55:23 UTC 2017


Hello Lex,

thanks for the tips and hints I'll keep them in mind/have a look at it.

 > 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.

That sounds like a very good idea.

 > 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?

I would tend to try to find a simple solution. As there do not seem to 
be so many plugins for geany this could simply be a common naming 
principle. E.g. prefix placeholder names with the plugin name. As that 
would get very long, maybe just use the abbreviation of a plugin name. 
So it e.g. would be "AM_somevar" for a placeholder owned by the 
Auto-Mark plugin. So plugins would need to "manually" guarantee that 
there are no collisions between names and so they could simply register 
a callback function for their placeholders. Of course there should be a 
check e.g. if a duplicate placeholder shall be registered throw an error 
message. The naming convention would need to get part of the hacking 
guidelines. At a later step - as a usability improvement - the 
placeholders could be selectable from a combo box or something. It would 
be very nice if plugins could also deliver a description for their 
placeholders. This could be used in the help or for displaying tooltips.

Thanks and greetings,
Lars

Am 15.06.2017 um 01:18 schrieb 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



More information about the Users mailing list