Looking for feedback on nautilus-python breaking changes

--===============1151228326468420229==
Content-Type: multipart/alternative; boundary="94eb2c1152c426afa1055fac89b0"

--94eb2c1152c426afa1055fac89b0
Content-Type: text/plain; charset="UTF-8"

Hi all, after spending some time investigating this issue (
https://bugzilla.gnome.org/show_bug.cgi?id=784278) where there is an
assertion failure for get_background_items in nautilus-python menu provider
extensions, I figured out what the issue is, but I'm hoping to get some
feedback from the community about how to fix it, since it will require
either changes to Nautilus or nautilus-python.

First, some history.  When I last updated nautilus-python in 2011 to work
with gobject-introspection, the nautilus extension framework was using
introspection but not annotating much, and the functions that called out
into extensions were not introspectable.  So the generated Nautilus
typelib-generated python module did not contain methods for
Nautilus.MenuProvider.get_background_items, for example.  Sometime in 2012,
annotations were added, these provider methods were made introspectable,
and all of a sudden there was a collision.

All nautilus-python extensions sub-class their provider class of choice,
like Nautilus.MenuProvider, which means they inherit
Nautilus.MenuProvider's methods.  In this case,
Nautilus.MenuProvider.get_background_items points to a C function in
libnautilus-extension/nautilus_menu_provider.c.  And if a python extension
doesn't override get_background_items, you get an assertion failure like in
the above bug ticket, because it is trying to call into a C function that
it shouldn't be calling into.

In my mind there are two ways we can fix this, but I'm open to other
solutions:

1) Update the Nautilus annotations to ensure that these calls to extension
providers are not introspectable, which would prevent collisions in
extension clases using bindings.  I'm not sure if anyone is using these
introspected calls in real life, but I don't see what use they could get
from them anyway, unless they want to pretend to be Nautilus and access
Nautilus extensions.

2) I would update nautilus-python to use a different module name (like
NautilusPython.MenuProvider.get_background_items) that would never conflict
with Nautilus's.  This would cause breakage in any existing extension.
Easy to fix, but it could catch a lot of people by surprise.

I think I would prefer #1 here, since it would probably cause the least
breakage for existing nautilus-python users.  I could deprecate
sub-classing the Nautilus module in favor of a new NautilusPython module
and eventually require it.

What do people think?
Adam

--94eb2c1152c426afa1055fac89b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>Hi all, after spending =
some time investigating this issue (<a href=3D"https://bugzilla.gnome.org/s=
how_bug.cgi?id=3D784278">https://bugzilla.gnome.org/show_bug.cgi?id=3D78427=
8</a>) where there is an assertion failure for get_background_items in naut=
ilus-python menu provider extensions, I figured out what the issue is, but =
I&#39;m hoping to get some feedback from the community about how to fix it,=
 since it will require either changes to Nautilus or nautilus-python.<br><b=
r></div>First, some history.=C2=A0 When I last updated nautilus-python in 2=
011 to work with gobject-introspection, the nautilus extension framework wa=
s using introspection but not annotating much, and the functions that calle=
d out into extensions were not introspectable.=C2=A0 So the generated Nauti=
lus typelib-generated python module did not contain methods for Nautilus.Me=
nuProvider.get_background_items, for example.=C2=A0 Sometime in 2012, annot=
ations were added, these provider methods were made introspectable, and all=
 of a sudden there was a collision.=C2=A0 <br><br>All nautilus-python exten=
sions sub-class their provider class of choice, like Nautilus.MenuProvider,=
 which means they inherit Nautilus.MenuProvider&#39;s methods.=C2=A0 In thi=
s case, Nautilus.MenuProvider.get_background_items points to a C function i=
n libnautilus-extension/nautilus_menu_provider.c.=C2=A0 And if a python ext=
ension doesn&#39;t override get_background_items, you get an assertion fail=
ure like in the above bug ticket, because it is trying to call into a C fun=
ction that it shouldn&#39;t be calling into.<br><br></div>In my mind there =
are two ways we can fix this, but I&#39;m open to other solutions:<br><br><=
/div>1) Update the Nautilus annotations to ensure that these calls to exten=
sion providers are not introspectable, which would prevent collisions in ex=
tension clases using bindings.=C2=A0 I&#39;m not sure if anyone is using th=
ese introspected calls in real life, but I don&#39;t see what use they coul=
d get from them anyway, unless they want to pretend to be Nautilus and acce=
ss Nautilus extensions.<br><br></div>2) I would update nautilus-python to u=
se a different module name (like NautilusPython.MenuProvider.get_background=
_items) that would never conflict with Nautilus&#39;s.=C2=A0 This would cau=
se breakage in any existing extension.=C2=A0 Easy to fix, but it could catc=
h a lot of people by surprise.<br><br></div>I think I would prefer #1 here,=
 since it would probably cause the least breakage for existing nautilus-pyt=
hon users.=C2=A0 I could deprecate sub-classing the Nautilus module in favo=
r of a new NautilusPython module and eventually require it.<br><br></div>Wh=
at do people think?<br></div>Adam<br></div>

--94eb2c1152c426afa1055fac89b0--

--===============1151228326468420229==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
nautilus-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/nautilus-list
--===============1151228326468420229==--