Hi

Geany "projects" are just collections of settings and session information, effectively named sessions, so it is not possible and does not make sense to have more than one open at once.

The project plugins extend the semantics to consider the project directory and the files in it "special", but as they are extensions to the Geany built-in projects, they also cannot have more than one open.

I don't think there are any plugins that associate projects with files and so allow you to have more than one open.

Certainly you can open more than one isntance of Geany, just be aware that changes to settings in the configuration in one instance will not be noticed by other instances, and the settings saved will be the last instance closed.

Cheers Lex

On 14 June 2017 at 05:22, Lars Paulsen lars_paulsen@web.de wrote:

Hello,

I got a question about project support in geany: Is there a way to open multiple projects at the same time?

I had a look at the plugins "Project Organizer" and "GeanyPrj". Although this plugins improve the project support it does not seem to be possible to manage several projects at once.

Am I overseeing something? Are there other plugins on different sites than http://plugins.geany.org/ which support multiple projects? Thanks for any answers in advance.

Kind Regards, Lars

---

Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users

Hi Lex,

thanks for the detailed answer. I already suspected that there is no real multiple project support.

That is something that I am really missing.

What I like on Geany is the simplicity and the de-coupling of the editor and other development tools (compiler, build system...). That is really a nice principle. All thumbs-up for that!

But not having multiple project support is IMHO quite an inconvenience.

Would it be theoretically possible to write a plugin for that? Or do you know any design constraints which would make this impossible?

Cheers, Lars

Am 13.06.2017 um 23:13 schrieb Lex Trotman:

Hi

Geany "projects" are just collections of settings and session information, effectively named sessions, so it is not possible and does not make sense to have more than one open at once.

The project plugins extend the semantics to consider the project directory and the files in it "special", but as they are extensions to the Geany built-in projects, they also cannot have more than one open.

I don't think there are any plugins that associate projects with files and so allow you to have more than one open.

Certainly you can open more than one isntance of Geany, just be aware that changes to settings in the configuration in one instance will not be noticed by other instances, and the settings saved will be the last instance closed.

Cheers Lex

On 14 June 2017 at 05:22, Lars Paulsen lars_paulsen@web.de wrote:

...

Hello,

I got a question about project support in geany: Is there a way to open multiple projects at the same time?

I had a look at the plugins "Project Organizer" and "GeanyPrj". Although this plugins improve the project support it does not seem to be possible to manage several projects at once.

Am I overseeing something? Are there other plugins on different sites than http://plugins.geany.org/ which support multiple projects? Thanks for any answers in advance.

Kind Regards, Lars

---

Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users

Well, I am not sure if I can get used to it for larger projects.

I already use Geany for some years now for DokuWiki development. Mainly for working on the plugins and only seldom working on the core. It doesn't matter for me in this case as the plugins do not have so many files.

But for larger C projects containing multiple libs I would really miss it.

I'd recommend Geany not be bloated with this unnecessary functionality.

Hmm, I guess it is everyone's personal point of view which decides if you judge it as something unnecessary or an required feature. But I agree that I would not add it to Geany itself. But a plugin would be cool.

Am 14.06.2017 um 19:22 schrieb Chris Spencer:

I came from Eclipse, which supported multiple projects, and I thought I would really miss it in Geany...but I don't. Having separate windows dividing my projects has actually helped me keep things better organized. But to each their own. It's unlikely this will ever be added to Geany, and now that I'm used to it, I'd recommend Geany not be bloated with this unnecessary functionality.

On Wed, Jun 14, 2017 at 1:01 PM, Lars Paulsen <lars_paulsen@web.de mailto:lars_paulsen@web.de> wrote:

Hi Lex,

thanks for the detailed answer. I already suspected that there is no
real multiple project support.

That is something that I am really missing.

What I like on Geany is the simplicity and the de-coupling of the
editor and other development tools (compiler, build system...). That
is really a nice principle. All thumbs-up for that!

But not having multiple project support is IMHO quite an inconvenience.

Would it be theoretically possible to write a plugin for that? Or do
you know any design constraints which would make this impossible?

Cheers,
Lars

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

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