[Geany-Devel] My non-C plugin roadmap

Lex Trotman elextr at xxxxx
Mon Mar 30 23:48:27 UTC 2015


On 30 March 2015 at 23:54, Thomas Martitz <kugel at rockbox.org> wrote:
> Am 30.03.2015 um 14:33 schrieb Lex Trotman:
>>
>>
>>>> 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?
>
>
>
> For now, I kept it simple: Geany simply restarts the "scan for plugins" loop
> when new extensions are added during the the scan (remember that during the
> scan, each file is loaded and its init() is called, before the next file is
> even attempted). The PM dialog is refreshed in the same way when a pluxy is
> activated by the user.
>
> It can be made smarter, but it's good enough at the moment.
>
> https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L878 and
> https://github.com/kugel-/geany/blob/pluxy/src/plugins.c#L1272

Ok, so long as it doesn't re-load plugins already loaded thats ok, the
PM might get a bit slow, but its not something thats used every minute
of every day.


>
>
>
>>>
>>> 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?
>
>
>
> Yes, but the 2nd and 3rd points are entirely up to the pluxy. My
> demopluxy.so doesn't do anything fancy. it creates a dummy plugin out of a
> GKeyFile.

Oh sure it depends on the language/runtime etc.

>
> But the loader/unloader function is mandatory, it also acts as the entry
> point for pluxies to start their bindings/vm machinery if necessary.

Thats the load for the proxy right? The load for the supported plugins
is one of the registered hooks right?

That means that the "machinery" gets started even if there are no
plugins using it enabled?

>
>
>>
>>> 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 :)
>
>
> Geany doesn't and cannot know it's a peas plugin, though it could be smarter
> at determining it's a standard plugin. But I currently implemented a scheme
> where the first pluxy that matches wins, but if it doesn't match all other
> pluxes are tried. Geany itself is tried last.
>
> This should work for all real-world cases, even when there are multiple
> (more than 2) providers for .so files. If the pluxies are accurate enough at
> determining their own filetypes then no conflicts arise.
>
> Geany is always tried last, so if it gets to process a .so file, then it
> assumes it's a standard plugin like it's done in git master (no change here)

Ok

>
>>>
>>> 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.
>
>
>
> It's done this way already, the hooks are compiled into Geany. As I said the
> list of pluxies is initialized with a simulated one that provides the
> standard plugins { .extension = { "so", NULL }, .probe = NULL, .load =
> plugin_load_so, .unload = plugin_unload_so };
>

Ok, missed that, fine.

Cheers
Lex

>
>
> Best regards
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel


More information about the Devel mailing list