On 30 March 2015 at 22:43, Thomas Martitz <ku...@rockbox.org> wrote: > Hello, > > some if your question are easier to answer by looking at the code, I'll link > the appropriate sections. >
No problem, the explanations below about how things are meant to be used are more help than looking at the code by itself, what is needed is the user guide, which these explanations make a start at, don't lose them :) > > Am 30.03.2015 um 13:16 schrieb Lex Trotman: >> >> [...] >> >> Ok, this explains some of what I was asking on the other thread, so >> now I can ask the more specific questions below that are the key >> points in the confusion. >> >>> with my new loader (no pluxies) it goes like this, and this is *very* >>> similar to git master. >>> >>>> user opens PM dialog >>> >>> 1 Geany calls load_all_plugins(), which calls >>> load_plugins_from_path($path) >>> 2 for each $file in $path, Geany checks if the extension is >>> G_MODULE_SUFFIX, >>> and calls plugin_new($file, ...) >>> 3 plugin_new() calls the plugins's geany_load_module() (if new-style >>> plugin, calls version_check, set_info() for old-style ones) >>> 4 geany_load_module() is implemented by the plugin, and registers itself >>> with geany_plugin_register() >>> < geany_plugin_register() adds the plugin to the plugin list, so that the >>> PM >>> can sort and show it >>> >>> Now, with pluxies, it is completely the same except for: >>> 2* for each $file in $path, Geany calls is_plugin($file) >> >> What is is_plugin()? If its a function in Geany how does it get to >> know about new types of plugins without being hard coded? > It knows because the extensions are registered by the function below called by another plugin right? How do you make sure that the register function has been called before you come across a file with that extension? > > > It's new, small helper function I added. It loops through all known file > extensions, and returns the first pluxy (a PluginProxy *) for which a) the > supported file extension matches and b) the probe hook returned true (or is > NULL, for standard plugins). > $file is not a plugin if is_plugin returns NULL, i.e. no pluxy was found. > > https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L844 > > > File extensions and the proxy hooks (probe, load, unload) are registered by > a plugin during its init() through the new plugin_register_proxy() function. Ok, so this registers a new type of plugin by its extension(s) and that type is associated with a plugin that provides: - the loader functionality? - interface wrappers/bindings (like geanypy does)? - starts/loads any other things, like the Python interpretor or a JVM or Haskell runtime? > Here the pluxy added to the list of registered pluxies. This list is > initialized with the simulated pluxy that provides standard plugins (this is > not a plugin, it's contained in plugins.c, it's just to keep the code paths > equal). > > https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L1601 > >> >>> which matches >>> additional file extensions (as provided by pluxies), it also calls the >>> probe() hook to resolve ambiguous files (e.g. .so files, they can be core >>> or >>> libpeas plugins) >> >> I'm guessing probe() is a function that looks for something in the .so >> that distinguishes if its new or old loader, but what about others? > > > > It depends on the pluxy what the prope() function does! For my peasy pluxy > (that provides generic support for libpeas-based plugins), it looks if there > is a matching *.plugin for a given *.so, and if yes return a code so that > Geany does not attempt to process the .so itself. > > https://github.com/kugel-/peasy/blob/master/src/peasy.c#L73 > > There is no probe() for standard plugins, it accepts all .so. If it doesn't call probe how does it know if its a traditional plugin, or a peas one or maybe some other version that makes a .so file? (Haskell anybody :) > Whether it's a > new or old style plugin is determined later. It *could* be in a probe() hook > for standard plugins as well, I just didn't happen to implement it that way > (yet), because plugin_load_so needs to distinguish between the two anyway. > > https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L472 > >> >>> 3* plugin_new() calls the load() hook registered by pluxies for the given >>> extension. for standard plugins (without proxy) there is a predefined >>> plugin_load_so() funtion that gets called instead. >> >> How does the load hook get defined for new types of plugins? > > > Via the new API function plugin_register_proxy(). > https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L1601 Ok, understand now > >> >>> 4* The load-hook calls geany_plugin_register(), here Geany core and >>> proxies >>> work the same way >> >> Where is the geany_plugin_register() defined for a plugin written in a >> language that isn't C/C++/Vala that can produce a .so file? > > > In the load hook of the pluxy. Either the pluxy calls it directly or it > decides to provide a suitable binding so that the non-C script can call it > itself, but it has to be during the execution of the load hook. Ok, so if there are all these hooks, probably later the traditional plugins can be just another pre-registered set of hooks built into Geany, but I agree with your approach of not trying to do that all in the first step, leave the existing code as little changed as possible until the new system settles down and then change the existing code to use it. > > The demopluxy does it in the load() hook, right after parsing the metadata > of the example plugin (I completely made up a fake plugin format for > demonstration purposes): > > https://github.com/kugel-/geany/blob/pluxy/plugins/demopluxy.c#L169 > > I have done it the same way for peasy too, because libpeas plugins can be > python or js, and I didn't create bindings yet. But it shows working this > way. > > https://github.com/kugel-/peasy/blob/master/src/peasy.c#L130 > > >> >>> I designed it such, that the difference between standard plugins and >>> proxied >>> plugins is all contained in the load hook. The rest of Geany does not >>> know >>> about the difference. This ensures proxied plugins are first class >>> citizens. >>> >> Thats the correct target I agree, I just don't understand the design >> details yet. >> > > Thanks for the heads up! > > > Best regards > _______________________________________________ > 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
