Hi,
I have a small Geany plugin that needs some settings per Geany project.
Currently, I do it as follows: the user manually writes a special section in the .geany project file, which my plugin reads as a generic INI file.
I really like this approach (as a user) because it keeps all Geany project-related settings in one file.
But is this approach OK in the eyes of Geany core?
Hello Vasiliy,
there should be no problem with your approach (the extra content of the config file will be preserved by Geany).
However, Geany offers plugins the possibility to read/write from/to the project config files natively. When you register for the "project-open" signal, the callback is invoked every time a project is opened and you receive GKeyFile * config as a parameter from which you can read the configuration using
https://developer.gnome.org/glib/stable/glib-Key-value-file-parser.html
Similarly, when you register for "project-save", you can write your configuration to the GKeyFile signal parameter. You can also force the emission of the "project-save" signal by calling project_write_config().
You can check my projectorganizer plugin to see how to use the signals (the signals are registered in prjorg-main.c). You can also check
http://www.geany.org/manual/reference/pluginsignals_8c.html
Cheers,
Jiri
On Wed, Feb 15, 2017 at 4:21 PM, Vasiliy Faronov vfaronov@gmail.com wrote:
Hi,
I have a small Geany plugin that needs some settings per Geany project.
Currently, I do it as follows: the user manually writes a special section in the .geany project file, which my plugin reads as a generic INI file.
I really like this approach (as a user) because it keeps all Geany project-related settings in one file.
But is this approach OK in the eyes of Geany core?
-- Vasiliy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2017-02-15 11:42 AM, Jiří Techet wrote:
Hello Vasiliy,
there should be no problem with your approach (the extra content of the config file will be preserved by Geany).
However, Geany offers plugins the possibility to read/write from/to the project config files natively. When you register for the "project-open" signal, the callback is invoked every time a project is opened and you receive GKeyFile * config as a parameter from which you can read the configuration using
https://developer.gnome.org/glib/stable/glib-Key-value-file-parser.html
Similarly, when you register for "project-save", you can write your configuration to the GKeyFile signal parameter. You can also force the emission of the "project-save" signal by calling project_write_config().
You can check my projectorganizer plugin to see how to use the signals (the signals are registered in prjorg-main.c). You can also check
I also do this in code-format plugin[0], so you can have project-specific formating settings. Seems to work well.
Regards, Matthew Brush
[0]: https://github.com/codebrainz/code-format/blob/master/plugin.c#L154
Jiří, Matthew, thanks!
I missed the GKeyFile thing.
Actually, my plugin is written in Python (via Geanypy), and doesn't get the GKeyFile on project-open/project-save. Probably because there are no Python bindings for it.
But I guess Python's built-in ConfigParser should be enough.
Am 16.02.2017 um 11:58 schrieb Vasiliy Faronov:
Jiří, Matthew, thanks!
I missed the GKeyFile thing.
Actually, my plugin is written in Python (via Geanypy), and doesn't get the GKeyFile on project-open/project-save. Probably because there are no Python bindings for it.
But I guess Python's built-in ConfigParser should be enough.
Geanypy is not actively developed at this time. Let me suggest to give my Peasy plugin a try, as all the signals should be working there. Peasy is a newer approach to support Python (and lua) plugins inside Geany.
https://github.com/kugel-/peasy/
There are also prebuilt debian/ubuntu binaries here (they require a GTK3 built of Geany which is also available here):
Unfortunately I haven't written a migration guide yet but if you have questions feel free to ask.
Best regards.
On 2017-02-16 03:15 AM, Thomas Martitz wrote:
Am 16.02.2017 um 11:58 schrieb Vasiliy Faronov:
Jiří, Matthew, thanks!
I missed the GKeyFile thing.
Actually, my plugin is written in Python (via Geanypy), and doesn't get the GKeyFile on project-open/project-save. Probably because there are no Python bindings for it.
But I guess Python's built-in ConfigParser should be enough.
Geanypy is not actively developed at this time. Let me suggest to give
What does that mean? It's not 100% perfect, but it does what it's intended to do quite well. Should we just start committing random changes so it's "actively developed"?
Regards, Matthew Brush
Am 16.02.2017 um 15:55 schrieb Matthew Brush:
On 2017-02-16 03:15 AM, Thomas Martitz wrote:
Am 16.02.2017 um 11:58 schrieb Vasiliy Faronov:
Jiří, Matthew, thanks!
I missed the GKeyFile thing.
Actually, my plugin is written in Python (via Geanypy), and doesn't get the GKeyFile on project-open/project-save. Probably because there are no Python bindings for it.
But I guess Python's built-in ConfigParser should be enough.
Geanypy is not actively developed at this time. Let me suggest to give
What does that mean? It's not 100% perfect, but it does what it's intended to do quite well. Should we just start committing random changes so it's "actively developed"?
It's not being updated for new Geany APIs, nor does the upstream developer (you :-) review PRs in a timely manner, for a start.
Best regards.
What does that mean? It's not 100% perfect, but it does what it's intended to do quite well. Should we just start committing random changes so it's "actively developed"?
It's not being updated for new Geany APIs, nor does the upstream developer (you :-) review PRs in a timely manner, for a start.
Matthew, Thomas, play nice please children. :)
Neither Python solution is perfect.
Geanypy is the available Python solution that is mature(ish) and distributed, but is GTK2 only, whilst Peasy is GTK3 but still in Thomas' private repository, incompletely documented (according to Thomas), and not distributed.
Thats always the way during transitions, the old way gets little love, whilst the new way is not quite ready yet. :)
As a volunteer open source project nobody is paid to work on Geany, so we have to allow for the fact that contributors will vary in ability, interest, availability and we should accommodate their foibles with patience.
Thanks Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2017-02-16 07:33 AM, Thomas Martitz wrote:
Am 16.02.2017 um 15:55 schrieb Matthew Brush:
On 2017-02-16 03:15 AM, Thomas Martitz wrote:
Am 16.02.2017 um 11:58 schrieb Vasiliy Faronov:
Jiří, Matthew, thanks!
I missed the GKeyFile thing.
Actually, my plugin is written in Python (via Geanypy), and doesn't get the GKeyFile on project-open/project-save. Probably because there are no Python bindings for it.
But I guess Python's built-in ConfigParser should be enough.
Geanypy is not actively developed at this time. Let me suggest to give
What does that mean? It's not 100% perfect, but it does what it's intended to do quite well. Should we just start committing random changes so it's "actively developed"?
It's not being updated for new Geany APIs, nor does the upstream developer (you :-) review PRs in a timely manner, for a start.
In this particular case, I don't think PyGtk has bindings for GKeyFile (since ConfigParser was effectively the same), so there's not much point in GeanyPy just passing a naked C pointer into Python which can't be manipulated in any meaningful way.
As for new APIs, "the" upstream developer, and making it sound like a dead project; everyone who wants to contribute is more than welcome. There are 5 "collaborators" with push access on the Github repo (including you) and I'd gladly add anyone else who is interested in contributing. Just because I choose not to spend a lot of time hacking on something that works well enough for me, doesn't mean it has stop anyone else from making it better for them.
Regards, Matthew Brush
Hi Thomas,
On Thu, Feb 16, 2017 at 2:15 PM, Thomas Martitz kugel@rockbox.org wrote:
Geanypy is not actively developed at this time. Let me suggest to give my Peasy plugin a try, as all the signals should be working there. Peasy is a newer approach to support Python (and lua) plugins inside Geany.
Thank you for your suggestion. Peasy is interesting and will probably be indispensable for GTK+3 Geany. But at this time GeanyPy is better suited for my purposes, as it's more widely packaged and works well enough for me. The signals are emitted all right; it's just that the callback doesn't get a GKeyFile argument, but that seems like a minor nuisance.