Re: [Geany-Devel] Proxy Plugins Update
Steven, right, I specifically want to avoid "doing the gedit" and put off plugin developers (repeatedly). A rewrite will not be necessary, but, if anything, a small modification to the compilation process of the plugin (no source code changes). At least if what I'm having in my mind works out. Do you maintain plugins outside geany-plugins, and are these publicly available? Best regards Am 13.11.2014 17:35, schrieb Steven Blatnick: I concur completely. It's also possible to lose some plugins entirely, as that's why I left gedit. I figured if I have to rewrite my plugins anyway, I may as well look at other editors/IDEs as possible candidates. On 11/13/2014 05:50 AM, Lex Trotman wrote: my gut feeling is that unless the effort is minimal it risks those plugins being unavailable for a while after the geany release ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
I concur completely. It's also possible to lose some plugins entirely, as that's why I left gedit. I figured if I have to rewrite my plugins anyway, I may as well look at other editors/IDEs as possible candidates. On 11/13/2014 05:50 AM, Lex Trotman wrote: my gut feeling is that unless the effort is minimal it risks those plugins being unavailable for a while after the geany release ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
To summarise our IRC discussion: 1. If the libpeas and the gobjectification can be split then I would say that would be the better way to do it, as two steps. 2. If changes required for core plugins and GP plugins can be mechanised and don't require any changes by GP plugin maintainers then those should be peasified as part of the release that supports libpeas. 3. Support for third party plugins depends on how much of the automation from the core/GP changes can be re-used by third party plugin authors to minimise their efforts, compared to how much effort is required to support them for one Geany release period (as described below). More info on exactly what each option entails is needed but my gut feeling is that unless the effort is minimal it risks those plugins being unavailable for a while after the geany release. Cheers Lex On 12 November 2014 18:44, Thomas Martitz wrote: > Am 11.07.2014 um 22:03 schrieb Colomban Wendling: >> >> Le 07/07/2014 18:48, Thomas Martitz a écrit : >>> >>> [...] >>> >>> In my last post I've followed the approach of proxy plugins, aka pluxys. >>> This approach is based on geanypy and implements a plugin API for >>> plugins to act as proxy. I have mostly finished that (including an >>> trivial example pluxy), and ported geanypy to this framework. The result >>> is that with this approach I was successfully able to load python >>> plugins with the core, including access to the plugin API, to the extend >>> that geanypy allows plus keybindings via a new (experimental) API call. >>> I think this should cover almost everything you would want for python >>> plugins. >>> >>> Since with that work you can successfully load python plugins I consider >>> this approach workable. >> >> Nice. >> >>> Now that the pluxy approach is in the final stages I went onto toying >>> with libpeas. >>> >>> [...] >>> >>> There are three areas of problems with libpeas before we can adapt it, >>> two of which I could already solve in a fork. >>> >>> [...] >> >> If using libpeas really requires having a modified version of it lying >> in our code, I'm not convinced it's a great idea. >> > > > FWIW, I did talk to the libpeas maintainer, Garret Regier. I cc'd him to get > him into the loop. > > Unsurprisingly, I met resistance to allow any changes that are only useful > to load legacy plugins, I don't see any hope in this direction. > > However, the Garret made a proposal that could enable us to load our > existing plugins (using libpeas) without relying on any modifcations to > libpeas. > > Please note before juding that this needs only be done for non-peas-enabled > plugins. We can peas-enable all of geany-plugins at compile time (using a > mechanism not described here but which I already thought out) so this really > does not apply g-p, but only out-of-tree plugins. And if it turns out we > care too little about these out-of-tree plugins we can skip the whole > backward-compat loading stuff and make an immediate switch to libpeas, and > treat it like an ordinary API/ABI bump. > > The proposal: > 1) Scan the plugin dir for non-peas-enabled plugins (they can be > distinguished by a) lacking a corresponding .plugin and b) missing the lib > prefix in the filename) > 2) For each of these, copy them to a user-writable dir (perhaps > ~/.config/geany/XXX or ~/.local/lib/geany/XXX), if not already done by a > previous session > 3) Load the plugin into a special environment for the purpose of extracting > it's metadata and generating a correspoding .plugin file. The environment > can be a separate process (geany or separate binary) or within geany itself > 4) Write the .plugin file for each to next to the copied plugin binary (can > use GKeyFile API for that). > *** The Module key needs to point to a wrapper binary that can provide the > plugin entry point required by libpeas, I'll call it modlib. And the Module > key needs to be unique across all available plugins, as required by libpeas > 5) Load the plugin-specific modlib copy using standard libpeas apis > > Point 5) is the most tricky. The modlib's job is only to load the actual > plugin and create the gobject interface instance. It is suggested that the > modlib implements the PeasExtensionBase [1] interface so that it can itself > determine which actual plugin to load, by looking at its PeasPluginInfo. > There needs to be a copy of the modlib for each actual plugin, to keep the > Module key in the .plugin unique. And the modlib needs to register a unique > GObject (GType) per plugin that libpeas instantiates (this would proxy the > actual plugins exported functions). > > Please comment on what you think. > > [1]: https://developer.gnome.org/libpeas/stable/PeasExtensionBase.html > > ___ > Devel mailing list > Devel@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/ma
Re: [Geany-Devel] Proxy Plugins Update
Am 11.07.2014 um 22:03 schrieb Colomban Wendling: Le 07/07/2014 18:48, Thomas Martitz a écrit : [...] In my last post I've followed the approach of proxy plugins, aka pluxys. This approach is based on geanypy and implements a plugin API for plugins to act as proxy. I have mostly finished that (including an trivial example pluxy), and ported geanypy to this framework. The result is that with this approach I was successfully able to load python plugins with the core, including access to the plugin API, to the extend that geanypy allows plus keybindings via a new (experimental) API call. I think this should cover almost everything you would want for python plugins. Since with that work you can successfully load python plugins I consider this approach workable. Nice. Now that the pluxy approach is in the final stages I went onto toying with libpeas. [...] There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork. [...] If using libpeas really requires having a modified version of it lying in our code, I'm not convinced it's a great idea. FWIW, I did talk to the libpeas maintainer, Garret Regier. I cc'd him to get him into the loop. Unsurprisingly, I met resistance to allow any changes that are only useful to load legacy plugins, I don't see any hope in this direction. However, the Garret made a proposal that could enable us to load our existing plugins (using libpeas) without relying on any modifcations to libpeas. Please note before juding that this needs only be done for non-peas-enabled plugins. We can peas-enable all of geany-plugins at compile time (using a mechanism not described here but which I already thought out) so this really does not apply g-p, but only out-of-tree plugins. And if it turns out we care too little about these out-of-tree plugins we can skip the whole backward-compat loading stuff and make an immediate switch to libpeas, and treat it like an ordinary API/ABI bump. The proposal: 1) Scan the plugin dir for non-peas-enabled plugins (they can be distinguished by a) lacking a corresponding .plugin and b) missing the lib prefix in the filename) 2) For each of these, copy them to a user-writable dir (perhaps ~/.config/geany/XXX or ~/.local/lib/geany/XXX), if not already done by a previous session 3) Load the plugin into a special environment for the purpose of extracting it's metadata and generating a correspoding .plugin file. The environment can be a separate process (geany or separate binary) or within geany itself 4) Write the .plugin file for each to next to the copied plugin binary (can use GKeyFile API for that). *** The Module key needs to point to a wrapper binary that can provide the plugin entry point required by libpeas, I'll call it modlib. And the Module key needs to be unique across all available plugins, as required by libpeas 5) Load the plugin-specific modlib copy using standard libpeas apis Point 5) is the most tricky. The modlib's job is only to load the actual plugin and create the gobject interface instance. It is suggested that the modlib implements the PeasExtensionBase [1] interface so that it can itself determine which actual plugin to load, by looking at its PeasPluginInfo. There needs to be a copy of the modlib for each actual plugin, to keep the Module key in the .plugin unique. And the modlib needs to register a unique GObject (GType) per plugin that libpeas instantiates (this would proxy the actual plugins exported functions). Please comment on what you think. [1]: https://developer.gnome.org/libpeas/stable/PeasExtensionBase.html ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
Am 12.07.2014 01:35, schrieb Lex Trotman: On 12 July 2014 09:25, Matthew Brush wrote: On 14-07-11 01:25 PM, Thomas Martitz wrote: Am 11.07.2014 22:03, schrieb Colomban Wendling: Le 07/07/2014 18:48, Thomas Martitz a écrit : [...] In my last post I've followed the approach of proxy plugins, aka pluxys. This approach is based on geanypy and implements a plugin API for plugins to act as proxy. I have mostly finished that (including an trivial example pluxy), and ported geanypy to this framework. The result is that with this approach I was successfully able to load python plugins with the core, including access to the plugin API, to the extend that geanypy allows plus keybindings via a new (experimental) API call. I think this should cover almost everything you would want for python plugins. Since with that work you can successfully load python plugins I consider this approach workable. Nice. Now that the pluxy approach is in the final stages I went onto toying with libpeas. [...] There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork. [...] If using libpeas really requires having a modified version of it lying in our code, I'm not convinced it's a great idea. It's because we require modifications to it for backwards compat, this way we could maintain ABI and API stability across a transition to libpeas. We can drop it from our source after the transition period and/or convince upstream to accept rather geany-specific code (unlikely). Another issue is that upstream libpeas tends to require recent glib/gtk versions even when not justified. The fork would allow us to lower the glib/gtk requirements. If they're not justified, then why not provide upstream with a patch that lowers them to minimum version required? libpeas is tiny, and is not actively developed (one can consider the project mostly done). So I don't think it's a big deal really. On the other concept of libpeas does provide a lot of benefits so it's worth it IMO. What alternatives can you propose? Thomas, As I understand it you only need to bundle peas to be able to add the backward compatible loader? Yes. If that is going to be for a limited deprecation period (say two release periods after the peas version is released) then it is reasonable to argue that the changes to libpeas are Geany specific, for a limited period and not worth pushing upstream. The changes would be very geany specific, although the first one (supporting plugins that are not described by a .plugin file) can perhaps be made generic in some way. But the loader is always going to be highly Geany specific, and I don't think it would be accepted by upstream, seeing that they even dropped a java script loader that is not app-specific. But yea, but I didn't ask yet either. This is in part because the last mailing list activity is from 2012 which didn't receive any response. I'd like to remember you about another point: Even if libpeas would accept all our modifictions like tomorrow, Geany realistically couldn't depend on it for the near future anyway (too new). By the time we can depend on it, i.e. when it lands in the current enterprise distros (REHL will probably only have it by RHEL 8), we probably don't even need to modifications anymore. This is the main reason that I don't think it's worth even trying to push the changes upstream: we wouldn't be able to use that upstream for a few years, and once we can we don't need these changes anymore. Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
On 12 July 2014 09:25, Matthew Brush wrote: > On 14-07-11 01:25 PM, Thomas Martitz wrote: >> >> Am 11.07.2014 22:03, schrieb Colomban Wendling: >>> >>> Le 07/07/2014 18:48, Thomas Martitz a écrit : [...] In my last post I've followed the approach of proxy plugins, aka pluxys. This approach is based on geanypy and implements a plugin API for plugins to act as proxy. I have mostly finished that (including an trivial example pluxy), and ported geanypy to this framework. The result is that with this approach I was successfully able to load python plugins with the core, including access to the plugin API, to the extend that geanypy allows plus keybindings via a new (experimental) API call. I think this should cover almost everything you would want for python plugins. Since with that work you can successfully load python plugins I consider this approach workable. >>> >>> Nice. >>> Now that the pluxy approach is in the final stages I went onto toying with libpeas. [...] There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork. [...] >>> >>> If using libpeas really requires having a modified version of it lying >>> in our code, I'm not convinced it's a great idea. >>> >> >> It's because we require modifications to it for backwards compat, this >> way we could maintain ABI and API stability across a transition to >> libpeas. We can drop it from our source after the transition period >> and/or convince upstream to accept rather geany-specific code (unlikely). >> >> Another issue is that upstream libpeas tends to require recent glib/gtk >> versions even when not justified. The fork would allow us to lower the >> glib/gtk requirements. >> > > If they're not justified, then why not provide upstream with a patch that > lowers them to minimum version required? > >> libpeas is tiny, and is not actively developed (one can consider the >> project mostly done). So I don't think it's a big deal really. On the >> other concept of libpeas does provide a lot of benefits so it's worth it >> IMO. >> >> What alternatives can you propose? >> Thomas, As I understand it you only need to bundle peas to be able to add the backward compatible loader? If that is going to be for a limited deprecation period (say two release periods after the peas version is released) then it is reasonable to argue that the changes to libpeas are Geany specific, for a limited period and not worth pushing upstream. Although Fedora are well known to be strict on this, that is one of their acceptable reasons. Cheers Lex > > Not bundling it in the tree :) > > You haven't really given any good reasons why we need to fork libpeas that > can't be solved by working with upstream to make the things you want to do > possible (ex. exposing the needed headers/types). AFAIK some distros[1][2] > hate when apps bundle libs like this and might require at least that we > tried to work with upstream before we can get exceptions about embedding > current/active/readily-available system libraries in our tree. > > Alternatively, couldn't you do the Peas extensions completely separate from > the existing loader code (as in my "peas" branch), and then make the plugin > manager GUI homogeneous so that it's the same experience for plugin users? > Without trying to munge our old loader together with the Peas loader, all of > your problems would fall away, IIUC (or at least make a new different set of > problems :) > > Cheers, > Matthew Brush > > [1]: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries > [2]: https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles > ___ > Devel mailing list > Devel@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
On 14-07-11 01:25 PM, Thomas Martitz wrote: Am 11.07.2014 22:03, schrieb Colomban Wendling: Le 07/07/2014 18:48, Thomas Martitz a écrit : [...] In my last post I've followed the approach of proxy plugins, aka pluxys. This approach is based on geanypy and implements a plugin API for plugins to act as proxy. I have mostly finished that (including an trivial example pluxy), and ported geanypy to this framework. The result is that with this approach I was successfully able to load python plugins with the core, including access to the plugin API, to the extend that geanypy allows plus keybindings via a new (experimental) API call. I think this should cover almost everything you would want for python plugins. Since with that work you can successfully load python plugins I consider this approach workable. Nice. Now that the pluxy approach is in the final stages I went onto toying with libpeas. [...] There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork. [...] If using libpeas really requires having a modified version of it lying in our code, I'm not convinced it's a great idea. It's because we require modifications to it for backwards compat, this way we could maintain ABI and API stability across a transition to libpeas. We can drop it from our source after the transition period and/or convince upstream to accept rather geany-specific code (unlikely). Another issue is that upstream libpeas tends to require recent glib/gtk versions even when not justified. The fork would allow us to lower the glib/gtk requirements. If they're not justified, then why not provide upstream with a patch that lowers them to minimum version required? libpeas is tiny, and is not actively developed (one can consider the project mostly done). So I don't think it's a big deal really. On the other concept of libpeas does provide a lot of benefits so it's worth it IMO. What alternatives can you propose? Not bundling it in the tree :) You haven't really given any good reasons why we need to fork libpeas that can't be solved by working with upstream to make the things you want to do possible (ex. exposing the needed headers/types). AFAIK some distros[1][2] hate when apps bundle libs like this and might require at least that we tried to work with upstream before we can get exceptions about embedding current/active/readily-available system libraries in our tree. Alternatively, couldn't you do the Peas extensions completely separate from the existing loader code (as in my "peas" branch), and then make the plugin manager GUI homogeneous so that it's the same experience for plugin users? Without trying to munge our old loader together with the Peas loader, all of your problems would fall away, IIUC (or at least make a new different set of problems :) Cheers, Matthew Brush [1]: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [2]: https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
Am 11.07.2014 22:03, schrieb Colomban Wendling: Le 07/07/2014 18:48, Thomas Martitz a écrit : [...] In my last post I've followed the approach of proxy plugins, aka pluxys. This approach is based on geanypy and implements a plugin API for plugins to act as proxy. I have mostly finished that (including an trivial example pluxy), and ported geanypy to this framework. The result is that with this approach I was successfully able to load python plugins with the core, including access to the plugin API, to the extend that geanypy allows plus keybindings via a new (experimental) API call. I think this should cover almost everything you would want for python plugins. Since with that work you can successfully load python plugins I consider this approach workable. Nice. Now that the pluxy approach is in the final stages I went onto toying with libpeas. [...] There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork. [...] If using libpeas really requires having a modified version of it lying in our code, I'm not convinced it's a great idea. It's because we require modifications to it for backwards compat, this way we could maintain ABI and API stability across a transition to libpeas. We can drop it from our source after the transition period and/or convince upstream to accept rather geany-specific code (unlikely). Another issue is that upstream libpeas tends to require recent glib/gtk versions even when not justified. The fork would allow us to lower the glib/gtk requirements. libpeas is tiny, and is not actively developed (one can consider the project mostly done). So I don't think it's a big deal really. On the other concept of libpeas does provide a lot of benefits so it's worth it IMO. What alternatives can you propose? Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
Le 07/07/2014 18:48, Thomas Martitz a écrit : > [...] > > In my last post I've followed the approach of proxy plugins, aka pluxys. > This approach is based on geanypy and implements a plugin API for > plugins to act as proxy. I have mostly finished that (including an > trivial example pluxy), and ported geanypy to this framework. The result > is that with this approach I was successfully able to load python > plugins with the core, including access to the plugin API, to the extend > that geanypy allows plus keybindings via a new (experimental) API call. > I think this should cover almost everything you would want for python > plugins. > > Since with that work you can successfully load python plugins I consider > this approach workable. Nice. > Now that the pluxy approach is in the final stages I went onto toying > with libpeas. > > [...] > > There are three areas of problems with libpeas before we can adapt it, > two of which I could already solve in a fork. > > [...] If using libpeas really requires having a modified version of it lying in our code, I'm not convinced it's a great idea. Regards, Colomban ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
On Wed, 09 Jul 2014 10:40:20 -0700 Matthew Brush wrote: > On 14-07-09 10:01 AM, Dimitar Zhekov wrote: > > On Tue, 08 Jul 2014 20:16:49 +0200 > > Thomas Martitz wrote: > > > >> My whole libpeas fork is (currently) imported into the geany repo so > >> it's a bit academic. > > > > I'd like to have a libpeas fork, or at least our own copy of the > > library (the code is actually quite small). The latest libpeas > > requires glib/gobject/gmodule/gio all >= 2.30, and the Debian package > > even has gtk+3 as requirement because of libpeas-gtk, which is actually > > optional and will not be used in Geany. > > You could use that point to recommend forking all of our dependencies, > for example the latest GLib/GObject/GModule/GIO is >= 2.30 too, the > latest GTK+ is 3.12 and requires GLib >= 2.39, the latest Pango requires > GLib >= 2.32. We can't fork everything :) These are shipped together as an official Windows binary, while libpeas is not AFAIK (havent't searched too deeply). We don't want all Windows users to compile peas to be able to use Geany. > IMO, it'd be better just to depend on an older version than the latest > like we do for everything else, and maybe open a bug report for the > Debian package if it wrongly makes libpeas depend on libpeas-gtk instead > of the other way around. To use an unmodified package, we'll have to go back to version 1.2.0 or so, and check for any important bugfixes until the current 1.10.0. We may end up with a de-facto fork. libpeas-gtk is a subdirectory of libpeas, it's normally compiled with the package, so the dependency is not wrong. The maintainer could have chosen to make it a separate package, but did not. I strongly suspect that libpeas (at least without the gtk+ widgets) does not really require the g* >= 2.30. There haven't been any major changes in the type system since glib _2.4_, and GTypePlugin is stable even before that. It could be the developers simply place the current g* versions as requirement. -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
Am 09.07.2014 19:40, schrieb Matthew Brush: On 14-07-09 10:01 AM, Dimitar Zhekov wrote: On Tue, 08 Jul 2014 20:16:49 +0200 Thomas Martitz wrote: My whole libpeas fork is (currently) imported into the geany repo so it's a bit academic. I'd like to have a libpeas fork, or at least our own copy of the library (the code is actually quite small). The latest libpeas requires glib/gobject/gmodule/gio all >= 2.30, and the Debian package even has gtk+3 as requirement because of libpeas-gtk, which is actually optional and will not be used in Geany. You could use that point to recommend forking all of our dependencies, for example the latest GLib/GObject/GModule/GIO is >= 2.30 too, the latest GTK+ is 3.12 and requires GLib >= 2.39, the latest Pango requires GLib >= 2.32. We can't fork everything :) IMO, it'd be better just to depend on an older version than the latest like we do for everything else, and maybe open a bug report for the Debian package if it wrongly makes libpeas depend on libpeas-gtk instead of the other way around. If I understand correctly, libpeas backends are pluggable/modules that do not need to be hardcoded into core either, so there's no too much incentive to keep our own fork/modified copy for that purpose, IMO. The fork is necessary (for now) for two reasons: * the code to detect current $plugin.so files as plugins and generate a PeasPluginInfo for them (in addition to those indicated by $plugin.plugin) has to be in libpeas core, PeasPluginInfo creation is not pluggable. * even though the actual loader is pluggable, the api (PeasPluginLoader interface) for that is private. there are no public headers which allow third-party loaders so the loader has to be build within libpeas It's not a huge problem for now since libpeas isn't developed at a overwhelming pace currently (mostly because it's simply done). Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
On 14-07-09 10:01 AM, Dimitar Zhekov wrote: On Tue, 08 Jul 2014 20:16:49 +0200 Thomas Martitz wrote: My whole libpeas fork is (currently) imported into the geany repo so it's a bit academic. I'd like to have a libpeas fork, or at least our own copy of the library (the code is actually quite small). The latest libpeas requires glib/gobject/gmodule/gio all >= 2.30, and the Debian package even has gtk+3 as requirement because of libpeas-gtk, which is actually optional and will not be used in Geany. You could use that point to recommend forking all of our dependencies, for example the latest GLib/GObject/GModule/GIO is >= 2.30 too, the latest GTK+ is 3.12 and requires GLib >= 2.39, the latest Pango requires GLib >= 2.32. We can't fork everything :) IMO, it'd be better just to depend on an older version than the latest like we do for everything else, and maybe open a bug report for the Debian package if it wrongly makes libpeas depend on libpeas-gtk instead of the other way around. If I understand correctly, libpeas backends are pluggable/modules that do not need to be hardcoded into core either, so there's no too much incentive to keep our own fork/modified copy for that purpose, IMO. My $0.02 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
On Tue, 08 Jul 2014 20:16:49 +0200 Thomas Martitz wrote: > My whole libpeas fork is (currently) imported into the geany repo so > it's a bit academic. I'd like to have a libpeas fork, or at least our own copy of the library (the code is actually quite small). The latest libpeas requires glib/gobject/gmodule/gio all >= 2.30, and the Debian package even has gtk+3 as requirement because of libpeas-gtk, which is actually optional and will not be used in Geany. -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
Am 08.07.2014 20:15, schrieb Dimitar Zhekov: On Mon, 07 Jul 2014 18:48:00 +0200 Thomas Martitz wrote: Hello, I'm still working on proxy plugins, sorts of. I thought it would be useful to give you an update. [...] 1) backward-compat: Libpeas is fundamentally based on describing plugin metadata with a separate .ini-style file ($plugin.plugin). It cannot load plain .so files on its own. -> I solved this by extending the libpeas parser such that it can parse the plugin description of Geany plugins, and generate a PeasPluginInfo from it. This way we can load existing plugins before they transitioned to the .plugin file. Well, if we decide on libpeas, we can move the descriptions from .so to .plugin at some future point. Hope you havent hardcoded the file type to ".so", since it's ".dll" under Win~1. I should do s/.so/G_MODULE_SUFFIX/ 2) backward-compat again: libpeas' existing C parser cannot load the C plugins because they do not implement a gobject interface. -> For this I wrote a trivial custom loader which instantiates a "PeasGeany" interface instance (it has the traditional init(), configure(), help(), cleanup() methods) on behalf of the existing plugins. This one should be part of Geany (there is no requirement to put the custom loaders in separate libraries). I integrated the loader as a additional libpeas loader (like the python one). so it compiles together with libpeas and the other loaders. That was easiest way to get working. My whole libpeas fork is (currently) imported into the geany repo so it's a bit academic. Best regards ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proxy Plugins Update
On Mon, 07 Jul 2014 18:48:00 +0200 Thomas Martitz wrote: > Hello, > > I'm still working on proxy plugins, sorts of. I thought it would be > useful to give you an update. > > [...] > > 1) backward-compat: Libpeas is fundamentally based on describing plugin > metadata with a separate .ini-style file ($plugin.plugin). It cannot > load plain .so files on its own. > -> I solved this by extending the libpeas parser such that it can > parse the plugin description of Geany plugins, and generate a > PeasPluginInfo from it. This way we can load existing plugins before > they transitioned to the .plugin file. Well, if we decide on libpeas, we can move the descriptions from .so to .plugin at some future point. Hope you havent hardcoded the file type to ".so", since it's ".dll" under Win~1. > 2) backward-compat again: libpeas' existing C parser cannot load the C > plugins because they do not implement a gobject interface. > -> For this I wrote a trivial custom loader which instantiates a > "PeasGeany" interface instance (it has the traditional init(), > configure(), help(), cleanup() methods) on behalf of the existing plugins. This one should be part of Geany (there is no requirement to put the custom loaders in separate libraries). -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Proxy Plugins Update
Hello, I'm still working on proxy plugins, sorts of. I thought it would be useful to give you an update. I first taken my proxy-plugin approach to the final stages, and then went onto researching what we can do with libpeas and gobject based approaches. Please feel free to discuss things and/or contribute to my efforts. In my last post I've followed the approach of proxy plugins, aka pluxys. This approach is based on geanypy and implements a plugin API for plugins to act as proxy. I have mostly finished that (including an trivial example pluxy), and ported geanypy to this framework. The result is that with this approach I was successfully able to load python plugins with the core, including access to the plugin API, to the extend that geanypy allows plus keybindings via a new (experimental) API call. I think this should cover almost everything you would want for python plugins. Since with that work you can successfully load python plugins I consider this approach workable. The code is on my github repo. The code is still in a proof-of-concept state with rough edges but I invite you to try it out. If you maintainers want to consider this for merging into geany proper then let's get this done, I'm all for it. Now that the pluxy approach is in the final stages I went onto toying with libpeas. Libpeas provides a nice interface for loadable plugins, both from the core's and plugin's point of view. For the core, plugins written in different language can be loaded through a unified interface. And plugins can implement multiple plugin entry points for different functionalities. Everything is based on gobject interfaces. There are three areas of problems with libpeas before we can adapt it, two of which I could already solve in a fork. 1) backward-compat: Libpeas is fundamentally based on describing plugin metadata with a separate .ini-style file ($plugin.plugin). It cannot load plain .so files on its own. -> I solved this by extending the libpeas parser such that it can parse the plugin description of Geany plugins, and generate a PeasPluginInfo from it. This way we can load existing plugins before they transitioned to the .plugin file. 2) backward-compat again: libpeas' existing C parser cannot load the C plugins because they do not implement a gobject interface. -> For this I wrote a trivial custom loader which instantiates a "PeasGeany" interface instance (it has the traditional init(), configure(), help(), cleanup() methods) on behalf of the existing plugins. with 1 and 2 i have successfully loaded existing plugins with libpeas. 3) access to Geany's plugin API for non-C plugins (aka bindings). -> This problem also applies to the plugin-proxy approach, except that for that it is mostly solved for python with geanypy. Anyway gobject-introspection provides a nice path to autogenerate language bindings. However, geany's API currently isn't introspectible. 3) is the problem I'm currently stuck at. I think Matthew already had an idea how we could possibly make it introspectible with little effort, with the help of vala. If anyone has other ideas or comments please speak up! So, I do plan to make libpeas fully work as 3) would ultimately also help with the pluxy approach so it's a good idea regardless. Then we can have a look which of the approaches we want to merge for geany (if any (?)). Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
