Created attachment 7459 Annotations patch The ThunarxRenamer.get_menu_items method calls into the ThunarxRenamer classes created by extensions (through C, python, or otherwise) and currently it is marked as not introspectable by the g-ir scanner. You can confirm this by looking at the generated Thunarx-3.0.gir file and in that get_menu_items method it says introspectable="0". This happens because there is something about the function arguments or return value that the g-ir scanner doesn't understand, and it needs annotation. What this means is that for thunarx-python extensions, their get_menu_items callback is going to be ignored and they will be unable to add custom menu items. I'm including a patch to add the needed annotations.
Andre Miranda referenced this bugreport in commit 77358656225e1fa7a431cffa5da0f4db49b7993d Provide missing g-i annotations (Bug #14045) https://git.xfce.org/xfce/thunar/commit?id=77358656225e1fa7a431cffa5da0f4db49b7993d
I think that commit provides all pending g-i annotations, I get no warnings anymore. Please let know if that is enough before we close this bug.
Hey Andre, so I tested out your patch and it confirms an issue that I'm dealing with in the nautilus-python bindings, which is that python extension methods are conflicting with the introspected Thunarx objects. For the Renamer menu items call we want it to be introspectable so that the Thunar C code can call directly into the python extension. But for the other methods like MenuProvider.get_file_items and get_folder_items, if these are introspectable and the extension doesn't implement them, then thunarx-python will end up calling back into thunarx_menu_provider_get_file_menu_items. This is because the python extensions sub-class ThunarxMenuProvider. I need to think about this a little and how to correctly handle this.
I think there are probably two solutions to this: 1) The extension methods that call into providers should not be introspectable. I'm not sure there is any usefulness in having those be introspectable, unless we want other programs to be able to call into them. Really, they're only useful for Thunar to call into extension providers. Also, this would require no changes in thunarx-python extensions. 2) Modify thunarx-python extensions to not sub-class Thunarx provider classes, but instead to create a new set of provider classes like ThunarxPythonMenuProvider which they would then sub-class instead. This would prevent any kind of collisions in the future. I'm sort of leaning towards #2, which seems more correct to me. And since we're breaking compatibility in this release anyway, it doesn't hurt to add to the breakage, which is minor. What do you think?
So after looking at things some more I think I'm leaning back towards #1. What you would need to do is add the (skip) annotation to the provider callback functions, like so: /** * thunarx_menu_provider_get_file_menu_items: (skip) * That will return it to introspectable="0" and will prevent collisions.
Actually, I don't know, I expect you to be the g-i export :) Just as reference, how Nautilus and Nemo deal with this? Since the skip annotation will not make any difference for C plugins, I'm fine, just give me a patch or point which methods need to skipped.
Created attachment 7477 Patch to skip provider callbacks Here is a patch to skip the provider callback functions. When I first wrote the nautilus-python bindings for gobject-introspection, Nautilus didn't have annotations so those methods were not introspectable. At some point around 2012 they added annotations and it caused an assertion failure if a callback method wasn't implemented for a sub-class. I'm trying to talk to the Nautilus folks about fixing the issue. Hopefully they'll add the skip annotation in as well.
Andre Miranda referenced this bugreport in commit 40c9a9bcb904e1bfcc9f0cfdc103a73719fbcd81 Skip functions not meant to be introspectable (Bug #14045) https://git.xfce.org/xfce/thunar/commit?id=40c9a9bcb904e1bfcc9f0cfdc103a73719fbcd81
Sorry for taking this long to merge your patch. Are we missing anything? If not, let's close this bug :)
Great! Nope it looks good. Thanks for helping with this.
Don't mention it ;)