Hi,
The API has been fixed to not leak symbols, which it did for a few recent versions. The only functions that are public, which is how it's always been, are those documented in the API reference[0]. That you were able to compile and link against private symbols was a bug in Geany. If you need those functions though, they can likely be added to the public API with a pull request.
Cheers, Matthew Brush
Hello Matthew,
Apparently filetypes_detect_from_document isn't needed since an instance of GeanyFiletype is a member of GeanyDocument, I just noticed, so that solved itself.
I can probably find an alternative workaround for document_close_all, e.g. iterate document_index(0) until it returns NULL, and call document_close; so I think should be ok too.
The project functions however, since Djynn is meant to integrate with the internal Geany project manager, with functions for opening and closing projects. I believe Geany would be enhanced by the possibility for plugins to open and close projects. When creating a Djynn-project a Geany-project is generated automatically, and when opening and closing Djynn-projects, the Geany-projects are opened and closed too. It's been working very well, seamlessly and invisibly, and would be a loss if I had to cut out the Geany-project integration.
When I began working with Djynn, I actually only wanted a tree-view of the project files for my projects. Since I'm working on many projects I needed quick access to files from the various projects without having to find them with Thunar (it's my preferred file manager). Then merging projects with Geany was the natural next step.
I'm not sure if anyone but me is really using my plugin, it's only designed for my personal needs, but I'd really be happy if anyone else had use for it as well.
Anyway, I'm sure document_close_all could be used by many plugins, but filetypes_detect_from_document is not needed. The project functions would be much appreciated. That's all on my xmas wishlist :)
Per
Hi,
[…]
The API has been fixed to not leak symbols, which it did for a few recent versions. The only functions that are public, which is how it's always been, are those documented in the API reference[0]. That you were able to compile and link against private symbols was a bug in Geany.
BTW, linking to private API never worked under Windows.
[…]
I can probably find an alternative workaround for document_close_all, e.g. iterate document_index(0) until it returns NULL, and call document_close; so I think should be ok too.
The project functions however, since Djynn is meant to integrate with the internal Geany project manager, with functions for opening and closing projects. I believe Geany would be enhanced by the possibility for plugins to open and close projects. When creating a Djynn-project a Geany-project is generated automatically, and when opening and closing Djynn-projects, the Geany-projects are opened and closed too. It's been working very well, seamlessly and invisibly, and would be a loss if I had to cut out the Geany-project integration.
I've got what might be a stupid question, but couldn't your plugin integrate with Geany projects the other way around, e.g. your plugin reacts to project open/close rather than making Geany react to your plugin's project open/close?
I must admit I didn't try your plugin, but there are a few other plugins enhancing Geany's project support, and AFAIU they do this by listening to Geany project open/close and add their own logic to that.
Anyway, I'm sure document_close_all could be used by many plugins, but filetypes_detect_from_document is not needed. The project functions would be much appreciated. That's all on my xmas wishlist :)
Adding `document_close_all()` sounds reasonable indeed. Out of curiosity, why do you need it? Project stuff might be too, depending on your answer on the above project-related question.
Regards, Colomban
On Tue, Dec 15, 2015 at 2:35 PM, Colomban Wendling < lists.ban@herbesfolles.org> wrote:
Hi,
[…]
The API has been fixed to not leak symbols, which it did for a few recent versions. The only functions that are public, which is how it's always been, are those documented in the API reference[0]. That you were able to compile and link against private symbols was a bug in Geany.
BTW, linking to private API never worked under Windows.
[…]
I can probably find an alternative workaround for document_close_all, e.g. iterate document_index(0) until it returns NULL, and call document_close; so I think should be ok too.
The project functions however, since Djynn is meant to integrate with the internal Geany project manager, with functions for opening and closing projects. I believe Geany would be enhanced by the possibility for plugins to open and close projects. When creating a Djynn-project a Geany-project is generated automatically, and when opening and closing Djynn-projects, the Geany-projects are opened and closed too. It's been working very well, seamlessly and invisibly, and would be a loss if I had to cut out the Geany-project integration.
I've got what might be a stupid question, but couldn't your plugin integrate with Geany projects the other way around, e.g. your plugin reacts to project open/close rather than making Geany react to your plugin's project open/close?
If I understand the project part of the plugin (haven't tried it either), it tries to simplify switching between projects and organizing projects into workspaces. In the screenshot here
http://plugins.geany.org/djynn.html
it seems that the second combo serves switching between projects in a workspace so it's the plugin which decides whether a project should be opened/closed rather than Geany. This functionality cannot be done with listening to the signals only so access to project_open()/close() makes sense here.
The other thing is the plugin itself is a bit too "All the stuff I need in Geany" and it would be better break the functionality into individual plugins, or extending existing plugins or adding the functionality directly to Geany.
Jiri
Hi Per,
On Tue, Dec 15, 2015 at 1:49 PM, Per Löwgren per.lowgren@gmail.com wrote:
Hi,
The API has been fixed to not leak symbols, which it did for a few recent versions. The only functions that are public, which is how it's always been, are those documented in the API reference[0]. That you were able to compile and link against private symbols was a bug in Geany. If you need those functions though, they can likely be added to the public API with a pull request.
Cheers, Matthew Brush
Hello Matthew,
Apparently filetypes_detect_from_document isn't needed since an instance of GeanyFiletype is a member of GeanyDocument, I just noticed, so that solved itself.
If needed, you can also use filetypes_detect_from_file() which is public.
I can probably find an alternative workaround for document_close_all, e.g. iterate document_index(0) until it returns NULL, and call document_close; so I think should be ok too.
Yep, it should be pretty easy to do this manually so the question is whether extra API is needed.
The project functions however, since Djynn is meant to integrate with the internal Geany project manager, with functions for opening and closing projects. I believe Geany would be enhanced by the possibility for plugins to open and close projects. When creating a Djynn-project a Geany-project is generated automatically, and when opening and closing Djynn-projects, the Geany-projects are opened and closed too. It's been working very well, seamlessly and invisibly, and would be a loss if I had to cut out the Geany-project integration.
Sounds like reasonable usage, I think you can just open Geany pull request to make these public. To make a function public, you just need to:
1. Prefix the implementation with GEANY_API_SYMBOL. 2. Add some user-visible API documentation with a docstring (see other API functions in the code to have an idea how it should look) 3. Move the function declarations above GEANY_PRIVATE in the header.
That's about it.
When I began working with Djynn, I actually only wanted a tree-view of the project files for my projects. Since I'm working on many projects I needed quick access to files from the various projects without having to find them with Thunar (it's my preferred file manager). Then merging projects with Geany was the natural next step.
I'm not sure if anyone but me is really using my plugin, it's only designed for my personal needs, but I'd really be happy if anyone else had use for it as well.
Anyway, I'm sure document_close_all could be used by many plugins, but filetypes_detect_from_document is not needed. The project functions would be much appreciated. That's all on my xmas wishlist :)
As it usually works, the best presents have to come from yourself, there will be just socks and pyjamas under the Christmas tree :-).
Cheers,
Jiri
Am 15.12.2015 um 14:38 schrieb Jiří Techet:
I can probably find an alternative workaround for document_close_all, e.g. iterate document_index(0) until it returns NULL, and call document_close; so I think should be ok too.Yep, it should be pretty easy to do this manually so the question is whether extra API is needed.
document_close_all() is useful on its own because there's an important detail: it's transactional. Either all or no documents are closed. As a consequence, if one or more docs spawned a dialog (because of being unsaved) and that dialog is cancelled, then no file is closed.
This is what's done when Geany exits. This is impossible with just doing document_close() in a loop (unless you export document_account_for_unsaved()).
So yes, document_close_all() should be exported.
Anyway, I'm sure document_close_all could be used by many plugins, but filetypes_detect_from_document is not needed. The project functions would be much appreciated. That's all on my xmas wishlist :)As it usually works, the best presents have to come from yourself, there will be just socks and pyjamas under the Christmas tree :-).
Right, Per should do the pull request, since he asks for the function.