On 08/04/2017 05:17 AM, Marek Marczykowski-Górecki wrote: > On Fri, Aug 04, 2017 at 03:51:32AM -0700, Andrew Morgan wrote: >> On 08/02/2017 07:59 AM, Marek Marczykowski-Górecki wrote: >>> On Wed, Aug 02, 2017 at 04:33:51AM -0700, Andrew Morgan wrote: >>>> On 08/01/2017 02:54 AM, Andrew Morgan wrote: >>>>> On 08/01/2017 02:53 AM, Marek Marczykowski-Górecki wrote: >>>>>> On Tue, Aug 01, 2017 at 12:59:16AM -0700, Andrew Morgan wrote: >>>>>>> On 07/31/2017 03:17 AM, Marek Marczykowski-Górecki wrote: >>>>>>>> On Sun, Jul 30, 2017 at 11:48:48PM -0700, Andrew Morgan wrote: >>>>>>>>> Quick update for tonight. >>>>>>>> >>>>>>>>> I've found where the most likely choke point for opening files is. [1] >>>>>>>>> Ideally one would just make a call to extensions through >>>>>>>>> libnautilus-extension through there, wait for responses, then return >>>>>>>>> if >>>>>>>>> any extension returns a False. I'm unsure if anything in Nautilus on >>>>>>>>> the >>>>>>>>> UX side needs to happen after that (such as showing a loading icon or >>>>>>>>> something...) but that's currently outside the scope of this patchset. >>>>>>>> >>>>>>>>> I've been talking to and getting help from people on >>>>>>>>> GIMPnet/#nautilus. >>>>>>>>> After explaining the whole idea to a few people, I've been prompted to >>>>>>>>> post on the mailing list. I have now done so with a RFC of sorts on >>>>>>>>> the >>>>>>>>> idea and whether or not they'd be prone to accepting it upstream once >>>>>>>>> it's ready. >>>>>>>> >>>>>>>>> The post is currently awaiting moderation approval, but I'll link it >>>>>>>>> once it goes up so people can keep up with the discussion. >>>>>>>> >>>>>>>> Great, thanks for the update! >>>>>>>> >>>>>>>>> Andrew Morgan >>>>>>>> >>>>>>>>> [1]: >>>>>>>>> https://github.com/GNOME/nautilus/blob/master/src/nautilus-mime-actions.c#L2421 >>>>>> >>>>>>> Another update, >>>>>> >>>>>>> The mailing list post still hasn't been approved. I messaged on GIMPnet >>>>>>> about it not too long ago so hopefully the appropriate people will get >>>>>>> pinged eventually. The team is currently busy with GUADEC so it's >>>>>>> understandable they may be running behind on moderating posts on a not >>>>>>> too traffic heavy mailing list[1] :) >>>>>> >>>>>> Does subscribing to the list workaround the issue? Some times moderator >>>>>> is set to just one, busy, person... >>>>> >>>>> I presume that's probably the case, yeah. I subscribed before I posted, >>>>> didn't seem to make a difference :) >>>>> >>>>>> >>>>>>> In terms of the patch, I've inserted the necessary code into all the >>>>>>> accompanying files and Nautilus builds successfully. During my testing I >>>>>>> threw a return statement in there and confirmed it blocked all file open >>>>>>> attempts silently, which is intended behavior. >>>>>> >>>>>>> I've stuck the WIP code up on Github, currently it segfaults but the >>>>>>> cause is known. I'll be modifying the qvm_trust.py NautilusPython >>>>>>> extension to make use of this method soon, and once it all works out >>>>>>> I'll provide some pre-made .RPMs for testing. >>>>>> >>>>>> Ok :) >>>>>> >>>>>> >>>>> >>>>> >>> >>>> Another status update for today. >>> >>>> As I said mostly everything's in place, however I'm currently stuck on >>>> trying to provide the correct arguments to a function that calls the >>>> subclassed methods in nautilus extensions. >>> >>>> Here is an example of calling a function subclassed by extensions: >>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-directory-async.c#L4647 >>> >>>> The update_complete and &handle arguments are not necessary for our >>>> purposes, but the provider and file args are. >>> >>>> Here I am calling our new method, that asks extensions whether we should >>>> open a particular file or not: >>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-mime-actions.c#L2500 >>> >>>> However the provider object is NULL. That >>>> nautilus_module_get_extensions_for_type method is defined here: >>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-module.c#L268 >>> >>>> That G_TYPE_CHECK_INSTANCE_TYPE always fails, so we never get any data >>>> prepended. G_TYPE_CHECK_INSTANCE_TYPE doesn't seem to be defined in this >>>> codebase either, which makes it a bit tricky to figure out why we're >>>> getting a negative value back from it. >>> >>>> Talking to people about it on IRC has brought mixed results, it seems >>>> the extension interface hasn't been changed in a while, so most don't >>>> remember too much about it. I'll keep asking though, hoping someone in >>>> the know pops in. >>> >>>> That's where I'm at currently, any help or clues are appreciated. >>> >>> See this search results: >>> https://github.com/search?q=org%3AGNOME+NAUTILUS_TYPE_INFO_PROVIDER&type=Code >>> >>> Especially this one: >>> https://github.com/GNOME/gnome-system-tools/blob/50f92695648a1d6340416c8db6eff7c38a7b3bbd/src/shares/nautilus/nautilus-shares.c#L349-L352 >>> >>> >>> > >> Alright well I've been at this for a bit again with varying success. > >> The issue is that this if statement here fails: >> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-module.c#L290 > >> This is due to none of the modules in module_objects being of type >> NAUTILUS_TYPE_INFO_PROVIDER. I tried the method suggested >> (g_type_module_add_interface) but am unsure of how to get access to the >> correct module to add our NAUTILUS_TYPE_INFO_PROVIDER type to. > >> Looking at nautilus-sendto-module.c (part of the included sendto >> extension) it gets a module from Nautilus, then calls a method that >> registers the NAUTILUS_TYPE_MENU_PROVIDER with that module: > >> https://github.com/anoadragon453/nautilus/blob/master/nautilus-sendto-extension/nautilus-sendto-module.c#L33 > >> https://github.com/anoadragon453/nautilus/blob/master/nautilus-sendto-extension/nautilus-nste.c#L190 > >> So, nautilus-python is flexible and will do this for you given that your >> extensions asks for one of the variable provider types: > >> https://github.com/anoadragon453/nautilus-python/blob/master/src/nautilus-python-object.c#L651 > >> So while writing this it seems that unless the new method (or any >> extension) is integrated into nautilus-python, it won't work to call it >> from nautilus. That wouldn't be such a big deal... if nautilus-python >> would work when I build and installed it. For that I'm having the >> following issue: > >> [user@dev-fedora nautilus-python]$ nautilus >> /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40: Warning: >> specified class size for type 'PyGtkGenericCellRenderer' is smaller than >> the parent type's 'GtkCellRenderer' class size >> from gtk import _gtk >> /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40: Warning: >> g_type_get_qdata: assertion 'node != NULL' failed >> from gtk import _gtk >> ^CSegmentation fault (core dumped) >> [user@dev-fedora nautilus-python]$ > >> This happens with both my patched nautilus-python and the version >> directly from source. Some research online says that it has to do with >> importing both PyGObject and PyGTK libraries at the same time[1], which >> is interesting as both libraries are a requirement to build >> NautilusPython. This crash occurs with patched nautilus and nautilus >> from the repos, so it's definitely an issue with building NautilusPython >> in some form or another, even though the build completes successfully. > >> The process of building it is as follows, simply: > >> ./autogen >> make > >> Then one copies the produced src/.libs/libnautilus-python.so to >> /usr/lib64/nautilus/extensions-3.0/ and nautilus will load it on startup. > >> You can grab the source code from here: git clone >> git://git.gnome.org/nautilus-python > >> And all the dependencies on Fedora: sudo dnf install gnome-common >> gtk-doc python-devel gnome-python2-devel > >> And getting an error related to get_toolbar_items is normal, I just >> comment out that line. I don't believe it to be related to the segfault. > > I get identical behavior. > Then switched to nautilus-3.0 branch and this one do not crash. > > I get this at startup: > > Traceback (most recent call last): > File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 39, in > <module> > raise ImportError(_static_binding_error) > ImportError: When using gi.repository you must not import static modules > like "gobject". Please change all occurrences of "import gobject" to "from > gi.repository import GObject". See: > https://bugzilla.gnome.org/show_bug.cgi?id=709183 > > (nautilus:1168): Nautilus-Python-WARNING **: nautilus_python_init_python > failed > > Not sure if failing nautilus_python_init_python prevent the SEGV, or > previously it didn't got that far. > > BTW that SEGV was infinite recursion like this: > > #39684 0x00007fffcb7d42d2 in pyg_type_get_bases () at > /usr/lib64/python2.7/site-packages/gobject/_gobject.so > #39685 0x00007fffcb7d4672 in pygobject_new_with_interfaces () at > /usr/lib64/python2.7/site-packages/gobject/_gobject.so > #39686 0x00007fffcb7d4285 in pygobject_lookup_class () at > /usr/lib64/python2.7/site-packages/gobject/_gobject.so > #39687 0x00007fffcb7d42d2 in pyg_type_get_bases () at > /usr/lib64/python2.7/site-packages/gobject/_gobject.so > #39688 0x00007fffcb7d4672 in pygobject_new_with_interfaces () at > /usr/lib64/python2.7/site-packages/gobject/_gobject.so > > >
Wow, did not notice that branch. Yes that seems to be compatible with
the latest Nautilus code.
I can't explain it, but for some reason I do not get that error on my
fedora-25-minimal VM (where I'm doing my testing), however I do get it
on my fedora-25 VM. Instead, I get the following:
[user@fedora-25-minimal np3]$ nautilus
sys:1: PyGIWarning: Nautilus was imported without specifying a version
first. Use gi.require_version('Nautilus', '3.0') before import to ensure
that the right version gets loaded.
** (nautilus:11881): WARNING **: Unable to get contents of the bookmarks
file: Error opening file /home/user/.gtk-bookmarks: No such file or
directory
update_file_info_full
Traceback (most recent call last):
File
"/usr/share/nautilus-python/extensions/update-file-info-async.py", line
9, in update_file_info_full
gobject.timeout_add_seconds(3, self.update_cb, provider, handle,
closure)
NameError: global name 'gobject' is not defined
update_file_info_full
However python extensions still seem to work fine, so I'll just continue
on with this VM for now.
Andrew Morgan
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/om33ti%24kt3%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
