On 08/04/2017 05:36 PM, Andrew Morgan wrote: > 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 >
(gdb) print providers
$2 = 0x55aaeb20 = {Cannot access memory at address 0x55aaeb20
(gdb) print 0x55aaeb20
$3 = 1437264672
(gdb)
Ok now I'm very confused.
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 qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/om3bi1%247pg%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
