[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

On 08/05/2017 12:59 AM, Marek Marczykowski-Górecki wrote:
> On Fri, Aug 04, 2017 at 07:40:22PM -0700, Andrew Morgan wrote:
>> 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.
>>
>>> Talki

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Aug 04, 2017 at 07:40:22PM -0700, Andrew Morgan wrote:
> 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

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

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_IN

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

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_IN

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

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_IN

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

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
>>>
>>>
>>>

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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
> > 
> > 
> >

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

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 

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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


- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJZgejjAAoJENuP0xzK19cslRgH/32Iv0SNvw6BNI+K3/IvEcgT
4kLuNRAJeE9lB6eDSH9SFE1fvkyXW9/5eh71sqRK4gpOU2GUiTAbnakGQFQGNvB/
X8MlBpYVE0cTPx2Pz5jSJlzTEcIsnHzhn309cqmWbnk+6AmnQ1C/w

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

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.

Thanks,
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/olsdas%24qlg%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

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 :)
> 
> 


-- 
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/olpj4h%24431%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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...

> 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 :)

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJZgE99AAoJENuP0xzK19csaokH/RnttNKLqHZdVWCgs95Aw7No
oh9Ay0aYlpThTX3pQKti2oUImrGWguUvOZyaHH0phIkr6Te7TEAwCjKmeiOwCRVA
QF4H+C86tetmk62wPLjGRtCSSP2v5LFnBZc8ISPUvaY40kTvAUqzEnZA1kGtFZPM
e0LJnxUDyAPG67jq1TN+JPTg3GMY2VxJI+c2XGxD4M8YTNA4xSoPRMhS1rS4XMeN
3hnmnwUtc8eTeomIzIFuyaep+JqC6ZxVRNTi88q8bPBEKvk43r1HFXcUJ091TqJ1
1xk9eXAxLFV/EUMspHxvdfe6vPRxJiK6v8Aq6US/B1sk+127riKc2NYor3YPxW0=
=nNh+
-END PGP SIGNATURE-

-- 
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/20170801095301.GU1095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

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] :)

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.

Thanks
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/olpccg%24pm9%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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
> 




- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJZfwOlAAoJENuP0xzK19cs2sEH/1a9J6AHnSTulLdvxd934G8m
SQlIRhwdjnIY71MKVwY4OfpbcMWFeDgVj8fPZMhPw7CvtZNK3pM6cWUOGJol+hWZ
TSQzbMjTKNJ6zWhoBMOvfPRdy0BTHvn3kerL7XIoyBzPMP4kYq54OzIRnzGs6tGo
mYEnNxoe98Jba6UwLCFLsz1VdS4wrBxANwC24eP1jlhqXrTprtvlNdOogv1HWvbK
qmuCQBVHAX7OgkULOvw6cqD2lN/BWSGYmvC+rAzUM+Ha0UxQ9yKGarVWIg7kTlM0
tM68M1sHjLe7OxX35lpkKU1OxKpcL7lpxL1+5cK92fvKAwHg6Cfgx0bdYGXCer4=
=upFI
-END PGP SIGNATURE-

-- 
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/20170731101708.GM1095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

On 07/30/2017 02:42 AM, Marek Marczykowski-Górecki wrote:
> On Sat, Jul 29, 2017 at 08:43:14PM -0700, Andrew Morgan wrote:
>> On 07/28/2017 08:47 PM, Andrew Morgan wrote:
>>> On 07/28/2017 01:21 AM, Marek Marczykowski-Górecki wrote:
 On Thu, Jul 27, 2017 at 07:01:17PM -0700, Andrew Morgan wrote:
> On 07/26/2017 01:29 AM, Marek Marczykowski-Górecki wrote:
>> On Tue, Jul 25, 2017 at 08:54:57PM -0700, Andrew Morgan wrote:
>>> Is it possible to build just Nautilus with qubes-builder? That may make
>>> things much closer to what we want.
>>
>> You'll need source package (.spec for rpm for example). You can start
>> with upstream source package:
>>  - dnf download --source nautilus && rpmdev-extract nautilus*src.rpm
>>  - apt-get source nautilus
>>
>> Then place resulting files in a subdirectory of qubes-src and add
>> Makefile.builder with either (or both):
>>  RPM_SPEC_FILES = relative/path/to/spec
>>  DEBIAN_BUILD_DIRS = debian (actually, a path to a directory with 
>> "control" file)
>>
>> For RPM, qubes-builder will handle unpacking sources, for Debian, you
>> need to add commands to do it into Makefile.builder, something like:
>>
>> ifneq ($(filter $(DISTRIBUTION), debian qubuntu),)
>> SOURCE_COPY_IN = debian-source-copy-in
>> endif
>>
>> debian-source-copy-in: SRC_FILE = 
>> "$(CHROOT_DIR)/$(DIST_SRC)/nautilus-x.y.z.tar.gz"
>> tar xf $(SRC_FILE) -C $(CHROOT_DIR)/$(DIST_SRC) 
>> --strip-components=1  
>>
>> Some more details here:
>> https://github.com/QubesOS/qubes-builder/blob/master/doc/ComponentConfiguration.md
>>
>>

> Hey Marek,

> I was able to build an entire f25-minimal template. Is there any way to
> build just the app or perhaps just build a new copy of Nautilus for an
> existing template?

 Yes, I recommend "make help" ;)
 In short: "make component-name", like "make core-agent-linux". It will
 print list of built packages at the end - you need to copy them into
 appropriate (Template)VM and install using rpm or dnf.

 To build nautilus (which is by default downloaded from upstream
 repositories as binary package), you need to add new component,
 according to instruction above.

 Also, other builder documentation
 https://www.qubes-os.org/doc/qubes-builder/


>>>
>>> Thanks Marek, I've managed to get it working and all automated with a
>>> dom0 script.
>>>
>>> I'll also make sure to update you guys more often on my progress going
>>> forward ;)
>>>
>>> Thanks,
>>> Andrew Morgan
>>>
> 
>> Quick progress update:
> 
>> I've created the following repos to hold progress of the nautilus patch:
> 
>> https://github.com/anoadragon453/nautilus
>> https://github.com/anoadragon453/nautilus-python
> 
>> The nautilus repo doesn't have commit history as checking out the
>> gnome-3-22 branch from upstream produces a tree that's slightly
>> different from the source package from Fedora repo. Mostly just build stuff.
> 
>> Commits made on there should still be applicable to the upstream branch
>> once finished.
> 
> For working directly with sources, this is the most convenient way. But
> for building and maintaining the package later, it would be better to
> have source package + patches. Then for example rebasing it later would
> be much easier, and will not mess the git history that much. See here
> for example:
> https://github.com/QubesOS/qubes-linux-scrypt
> or here:
> https://github.com/QubesOS/qubes-core-libvirt/
> 
> In fact the second example is maintained in a local git repository
> (clone of upstream), and patches.qubes directory is result of `git
> format-patch ...`. To reconstruct that local repository, you can clone
> upstream repo, then `git am patches.qubes/*`.
> 
> So, for now your repos are ok. But when finished, you'll need to extract
> those patches to:
> 1) send them upstream
> 2) create package in maintainable way
> 
>> Notes/what I've found so far:
> 
>> NautilusPython creates a Python interface to Nautilus' C extensions. It
>> is itself a Nautilus C extension. Nautilus extensions are in fact shared
>> libraries and thus are loaded in at run-time.
> 
>> There are three main areas across the different codebases to worry about:
>>  NautilusPython: nautilus-python-object.c
>>  Nautilus: nautilus-info-provider.c
>>  Nautilus: Wherever a file open call is invoked
> 
>> There are a few different categories of methods that can be called by a
>> nautilus extension. nautilus-info-provider is for getting information
>> about and dealing with files and file data. There exists a method inside
>> already called update_file_info, which is called every time a file is to
>> be displayed on screen, once per file.
> 
>> If an extension subclasses this method, it will be able to alter file
>> properties (such as add an emblem) to each file based on that file's
>> 

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Jul 29, 2017 at 08:43:14PM -0700, Andrew Morgan wrote:
> On 07/28/2017 08:47 PM, Andrew Morgan wrote:
> > On 07/28/2017 01:21 AM, Marek Marczykowski-Górecki wrote:
> >> On Thu, Jul 27, 2017 at 07:01:17PM -0700, Andrew Morgan wrote:
> >>> On 07/26/2017 01:29 AM, Marek Marczykowski-Górecki wrote:
>  On Tue, Jul 25, 2017 at 08:54:57PM -0700, Andrew Morgan wrote:
> > Is it possible to build just Nautilus with qubes-builder? That may make
> > things much closer to what we want.
> 
>  You'll need source package (.spec for rpm for example). You can start
>  with upstream source package:
>   - dnf download --source nautilus && rpmdev-extract nautilus*src.rpm
>   - apt-get source nautilus
> 
>  Then place resulting files in a subdirectory of qubes-src and add
>  Makefile.builder with either (or both):
>   RPM_SPEC_FILES = relative/path/to/spec
>   DEBIAN_BUILD_DIRS = debian (actually, a path to a directory with 
>  "control" file)
> 
>  For RPM, qubes-builder will handle unpacking sources, for Debian, you
>  need to add commands to do it into Makefile.builder, something like:
> 
>  ifneq ($(filter $(DISTRIBUTION), debian qubuntu),)
>  SOURCE_COPY_IN = debian-source-copy-in
>  endif
> 
>  debian-source-copy-in: SRC_FILE = 
>  "$(CHROOT_DIR)/$(DIST_SRC)/nautilus-x.y.z.tar.gz"
>  tar xf $(SRC_FILE) -C $(CHROOT_DIR)/$(DIST_SRC) 
>  --strip-components=1  
> 
>  Some more details here:
>  https://github.com/QubesOS/qubes-builder/blob/master/doc/ComponentConfiguration.md
> 
> 
> >>
> >>> Hey Marek,
> >>
> >>> I was able to build an entire f25-minimal template. Is there any way to
> >>> build just the app or perhaps just build a new copy of Nautilus for an
> >>> existing template?
> >>
> >> Yes, I recommend "make help" ;)
> >> In short: "make component-name", like "make core-agent-linux". It will
> >> print list of built packages at the end - you need to copy them into
> >> appropriate (Template)VM and install using rpm or dnf.
> >>
> >> To build nautilus (which is by default downloaded from upstream
> >> repositories as binary package), you need to add new component,
> >> according to instruction above.
> >>
> >> Also, other builder documentation
> >> https://www.qubes-os.org/doc/qubes-builder/
> >>
> >>
> > 
> > Thanks Marek, I've managed to get it working and all automated with a
> > dom0 script.
> > 
> > I'll also make sure to update you guys more often on my progress going
> > forward ;)
> > 
> > Thanks,
> > Andrew Morgan
> > 
> 
> Quick progress update:
> 
> I've created the following repos to hold progress of the nautilus patch:
> 
> https://github.com/anoadragon453/nautilus
> https://github.com/anoadragon453/nautilus-python
> 
> The nautilus repo doesn't have commit history as checking out the
> gnome-3-22 branch from upstream produces a tree that's slightly
> different from the source package from Fedora repo. Mostly just build stuff.
> 
> Commits made on there should still be applicable to the upstream branch
> once finished.

For working directly with sources, this is the most convenient way. But
for building and maintaining the package later, it would be better to
have source package + patches. Then for example rebasing it later would
be much easier, and will not mess the git history that much. See here
for example:
https://github.com/QubesOS/qubes-linux-scrypt
or here:
https://github.com/QubesOS/qubes-core-libvirt/

In fact the second example is maintained in a local git repository
(clone of upstream), and patches.qubes directory is result of `git
format-patch ...`. To reconstruct that local repository, you can clone
upstream repo, then `git am patches.qubes/*`.

So, for now your repos are ok. But when finished, you'll need to extract
those patches to:
1) send them upstream
2) create package in maintainable way

> Notes/what I've found so far:
> 
> NautilusPython creates a Python interface to Nautilus' C extensions. It
> is itself a Nautilus C extension. Nautilus extensions are in fact shared
> libraries and thus are loaded in at run-time.
> 
> There are three main areas across the different codebases to worry about:
>   NautilusPython: nautilus-python-object.c
>   Nautilus: nautilus-info-provider.c
>   Nautilus: Wherever a file open call is invoked
> 
> There are a few different categories of methods that can be called by a
> nautilus extension. nautilus-info-provider is for getting information
> about and dealing with files and file data. There exists a method inside
> already called update_file_info, which is called every time a file is to
> be displayed on screen, once per file.
> 
> If an extension subclasses this method, it will be able to alter file
> properties (such as add an emblem) to each file based on that file's
> information. Once finished, the extension can return an object that
> 

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

On 07/28/2017 08:47 PM, Andrew Morgan wrote:
> On 07/28/2017 01:21 AM, Marek Marczykowski-Górecki wrote:
>> On Thu, Jul 27, 2017 at 07:01:17PM -0700, Andrew Morgan wrote:
>>> On 07/26/2017 01:29 AM, Marek Marczykowski-Górecki wrote:
 On Tue, Jul 25, 2017 at 08:54:57PM -0700, Andrew Morgan wrote:
> Is it possible to build just Nautilus with qubes-builder? That may make
> things much closer to what we want.

 You'll need source package (.spec for rpm for example). You can start
 with upstream source package:
  - dnf download --source nautilus && rpmdev-extract nautilus*src.rpm
  - apt-get source nautilus

 Then place resulting files in a subdirectory of qubes-src and add
 Makefile.builder with either (or both):
  RPM_SPEC_FILES = relative/path/to/spec
  DEBIAN_BUILD_DIRS = debian (actually, a path to a directory with 
 "control" file)

 For RPM, qubes-builder will handle unpacking sources, for Debian, you
 need to add commands to do it into Makefile.builder, something like:

 ifneq ($(filter $(DISTRIBUTION), debian qubuntu),)
 SOURCE_COPY_IN = debian-source-copy-in
 endif

 debian-source-copy-in: SRC_FILE = 
 "$(CHROOT_DIR)/$(DIST_SRC)/nautilus-x.y.z.tar.gz"
 tar xf $(SRC_FILE) -C $(CHROOT_DIR)/$(DIST_SRC) 
 --strip-components=1  

 Some more details here:
 https://github.com/QubesOS/qubes-builder/blob/master/doc/ComponentConfiguration.md


>>
>>> Hey Marek,
>>
>>> I was able to build an entire f25-minimal template. Is there any way to
>>> build just the app or perhaps just build a new copy of Nautilus for an
>>> existing template?
>>
>> Yes, I recommend "make help" ;)
>> In short: "make component-name", like "make core-agent-linux". It will
>> print list of built packages at the end - you need to copy them into
>> appropriate (Template)VM and install using rpm or dnf.
>>
>> To build nautilus (which is by default downloaded from upstream
>> repositories as binary package), you need to add new component,
>> according to instruction above.
>>
>> Also, other builder documentation
>> https://www.qubes-os.org/doc/qubes-builder/
>>
>>
> 
> Thanks Marek, I've managed to get it working and all automated with a
> dom0 script.
> 
> I'll also make sure to update you guys more often on my progress going
> forward ;)
> 
> Thanks,
> Andrew Morgan
> 

Quick progress update:

I've created the following repos to hold progress of the nautilus patch:

https://github.com/anoadragon453/nautilus
https://github.com/anoadragon453/nautilus-python

The nautilus repo doesn't have commit history as checking out the
gnome-3-22 branch from upstream produces a tree that's slightly
different from the source package from Fedora repo. Mostly just build stuff.

Commits made on there should still be applicable to the upstream branch
once finished.

Notes/what I've found so far:

NautilusPython creates a Python interface to Nautilus' C extensions. It
is itself a Nautilus C extension. Nautilus extensions are in fact shared
libraries and thus are loaded in at run-time.

There are three main areas across the different codebases to worry about:
NautilusPython: nautilus-python-object.c
Nautilus: nautilus-info-provider.c
Nautilus: Wherever a file open call is invoked

There are a few different categories of methods that can be called by a
nautilus extension. nautilus-info-provider is for getting information
about and dealing with files and file data. There exists a method inside
already called update_file_info, which is called every time a file is to
be displayed on screen, once per file.

If an extension subclasses this method, it will be able to alter file
properties (such as add an emblem) to each file based on that file's
information. Once finished, the extension can return an object that
Nautilus' extension infrastructure can use (what is returns is used for
determining whether Nautilus should block the main thread's execution
until the extension is finished or continue and wait for the extension
to tell it when it's finished, but that is irrelevant here).

Essentially we also want to define a method that can return a value, in
this case a True/False, whenever a file is opened which will tell
nautilus whether to open the file or not.

Thus I've created a new method, file_open, to do just this. All it
should pass to the extension is a NautilusFileInfo object (plus some
other boilerplate), which the extension can then use to get the file
path, pass that to qvm-file-trust, and return a False if the file is
untrusted. The extension should've already began to open the file in a
disposableVM, so Nautilus doing nothing at this point is desired.

I've created some basic structures for the new method in both nautilus
and nautilus-python. I still need to determine where a file is opened
and restructure that to be blockable by an extension (I assume have a
method that just returns True, 

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

On 07/28/2017 01:21 AM, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 27, 2017 at 07:01:17PM -0700, Andrew Morgan wrote:
>> On 07/26/2017 01:29 AM, Marek Marczykowski-Górecki wrote:
>>> On Tue, Jul 25, 2017 at 08:54:57PM -0700, Andrew Morgan wrote:
 Is it possible to build just Nautilus with qubes-builder? That may make
 things much closer to what we want.
>>>
>>> You'll need source package (.spec for rpm for example). You can start
>>> with upstream source package:
>>>  - dnf download --source nautilus && rpmdev-extract nautilus*src.rpm
>>>  - apt-get source nautilus
>>>
>>> Then place resulting files in a subdirectory of qubes-src and add
>>> Makefile.builder with either (or both):
>>>  RPM_SPEC_FILES = relative/path/to/spec
>>>  DEBIAN_BUILD_DIRS = debian (actually, a path to a directory with "control" 
>>> file)
>>>
>>> For RPM, qubes-builder will handle unpacking sources, for Debian, you
>>> need to add commands to do it into Makefile.builder, something like:
>>>
>>> ifneq ($(filter $(DISTRIBUTION), debian qubuntu),)
>>> SOURCE_COPY_IN = debian-source-copy-in
>>> endif
>>>
>>> debian-source-copy-in: SRC_FILE = 
>>> "$(CHROOT_DIR)/$(DIST_SRC)/nautilus-x.y.z.tar.gz"
>>> tar xf $(SRC_FILE) -C $(CHROOT_DIR)/$(DIST_SRC) 
>>> --strip-components=1  
>>>
>>> Some more details here:
>>> https://github.com/QubesOS/qubes-builder/blob/master/doc/ComponentConfiguration.md
>>>
>>>
> 
>> Hey Marek,
> 
>> I was able to build an entire f25-minimal template. Is there any way to
>> build just the app or perhaps just build a new copy of Nautilus for an
>> existing template?
> 
> Yes, I recommend "make help" ;)
> In short: "make component-name", like "make core-agent-linux". It will
> print list of built packages at the end - you need to copy them into
> appropriate (Template)VM and install using rpm or dnf.
> 
> To build nautilus (which is by default downloaded from upstream
> repositories as binary package), you need to add new component,
> according to instruction above.
> 
> Also, other builder documentation
> https://www.qubes-os.org/doc/qubes-builder/
> 
> 

Thanks Marek, I've managed to get it working and all automated with a
dom0 script.

I'll also make sure to update you guys more often on my progress going
forward ;)

Thanks,
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/olh0fo%24ke%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jul 27, 2017 at 07:01:17PM -0700, Andrew Morgan wrote:
> On 07/26/2017 01:29 AM, Marek Marczykowski-Górecki wrote:
> > On Tue, Jul 25, 2017 at 08:54:57PM -0700, Andrew Morgan wrote:
> >> Is it possible to build just Nautilus with qubes-builder? That may make
> >> things much closer to what we want.
> > 
> > You'll need source package (.spec for rpm for example). You can start
> > with upstream source package:
> >  - dnf download --source nautilus && rpmdev-extract nautilus*src.rpm
> >  - apt-get source nautilus
> > 
> > Then place resulting files in a subdirectory of qubes-src and add
> > Makefile.builder with either (or both):
> >  RPM_SPEC_FILES = relative/path/to/spec
> >  DEBIAN_BUILD_DIRS = debian (actually, a path to a directory with "control" 
> > file)
> > 
> > For RPM, qubes-builder will handle unpacking sources, for Debian, you
> > need to add commands to do it into Makefile.builder, something like:
> > 
> > ifneq ($(filter $(DISTRIBUTION), debian qubuntu),)
> > SOURCE_COPY_IN = debian-source-copy-in
> > endif
> > 
> > debian-source-copy-in: SRC_FILE = 
> > "$(CHROOT_DIR)/$(DIST_SRC)/nautilus-x.y.z.tar.gz"
> > tar xf $(SRC_FILE) -C $(CHROOT_DIR)/$(DIST_SRC) 
> > --strip-components=1  
> > 
> > Some more details here:
> > https://github.com/QubesOS/qubes-builder/blob/master/doc/ComponentConfiguration.md
> > 
> > 
> 
> Hey Marek,
> 
> I was able to build an entire f25-minimal template. Is there any way to
> build just the app or perhaps just build a new copy of Nautilus for an
> existing template?

Yes, I recommend "make help" ;)
In short: "make component-name", like "make core-agent-linux". It will
print list of built packages at the end - you need to copy them into
appropriate (Template)VM and install using rpm or dnf.

To build nautilus (which is by default downloaded from upstream
repositories as binary package), you need to add new component,
according to instruction above.

Also, other builder documentation
https://www.qubes-os.org/doc/qubes-builder/

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJZevQSAAoJENuP0xzK19csPLAH/0hgqeQiwMSGPeeqaB17F/l3
3tqUa9zAttAHHDdMcic0w2v0AB6hAQl8bfXMq+CTLfO/wRBKc0fMKkXmFeLby21y
ds78yuJvOKn14yjZdAWy7WRg55u2NdAySROeI2tr749lK6Bj8JU8svwY+NLtN9+m
pomuhEUTYvDYbAK9gTKZtqV3Ckl4MkGMFY4U9EBBTeyFXfcK/qIpnGoYAC3fBoLH
c+uh/T7XNd8P86697cSJwj1HFZv0w/bPHU7md3ZLD0ZZNg1pFMpuslrJopUxZeib
0E024cyPasWIM1gPL2bFH45Wy69ldudS0cGTSGHCZNjqN87JoHh12Td7oIC7EVY=
=Ueos
-END PGP SIGNATURE-

-- 
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/20170728082137.GN1095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

On 07/26/2017 01:29 AM, Marek Marczykowski-Górecki wrote:
> On Tue, Jul 25, 2017 at 08:54:57PM -0700, Andrew Morgan wrote:
>> On 07/25/2017 06:23 PM, Marek Marczykowski-Górecki wrote:
>>> On Tue, Jul 25, 2017 at 05:52:56PM -0700, Andrew Morgan wrote:
 On 07/24/2017 02:33 AM, Andrew Morgan wrote:
> ## Nautilus
>
> The patch for Nautilus is finally getting going! After some hiccups with
> Nautilus' build process, I've now switched to [GNOME
> Builder](https://wiki.gnome.org/Apps/Builder) for the compilation and
> run management of Nautilus. Builder provides a much cleaner experience
> when building and compiling, and after only hearing about it here and
> there, it was exciting to finally download and try it out.
>
> After a couple hiccups with importing the Nautilus code and checking out
> the correct branch (gnome-3-22 in this case) with the help of some fine
> folks on #gnome-builder, Nautilus was building and launching as expected:
>
> ![Nautilus built and running from
> Builder](images/nautilus-gnome-builder.png)
> *Nautilus built and running from Builder*
>
> The other advantage GNOME Builder holds is its ability to build all
> projects as flatpaks. This makes it much easier to share testing builds
> of Nautilus without asking people to install Nautilus' [horrible list of
> dependencies](https://ubuntuforums.org/showthread.php?t=1678656&p=10426119#post10426119),
> and instead just run a single command to start it up!
>
> In addition to Nautilus, GNOME Builder is also helping me with patching
> [nautilus-python](https://wiki.gnome.org/Projects/NautilusPython/),
> which are the python bindings that allow extensions written in python to
> interact with Nautilus' C API.
>
> [This
> folder](https://git.gnome.org/browse/nautilus-python/tree/src/nautilus-python-object.c)
> houses the definitions of functions that can be referenced in
> `nautilus-python` extensions. Nautilus' maintainer, Carlos Soriano, also
> kindly pointed out where these methods connect to Nautilus itself, which
> turns out to be
> [here](https://git.gnome.org/browse/nautilus/tree/libnautilus-extension).
>
> The typical workflow in a `nautilus-python` extension is to define a
> function that corresponds to the data or action you desire, then return
> some data based on some logic you have in your extension. My plan is to
> create another function here that will be called when a file is
> determined to be opened. The file will then be opened depending on
> whether the extension returns a `True` or a `False`.
>
> A new DisposableVM with the file in question can be launched from within
> the extension, so there is no need for any Qubes-specific code to go
> into this patch.
>
 To clarify on this after some digging today, Nautilus officially only
 supports extensions written in C. There are a few extensions that are
 included in Nautilus' source tree (such as the sendto extension), but
 all one needs to do to install an extension is to place the extension
 library in `/usr/lib(64)/nautilus/extensions-3.0/`, restart Nautilus and
 it should be installed.
>>>
 NautilusPython is a Nautilus C extension. It's purpose is just to read
 python scripts that perform extension actions and translate those into
 the C actions Nautilus is used to. It's a completely separate
 compatibility layer.
>>>
 This is all fine and dandy, and means that if needed, really only
 Nautilus (not NautilusPython) would have to be patched to include new
 bindings for file open events, and a C Nautilus extension could be
 written to make use of it.
>>>
 I'm going to strive to have NautilusPython be compatible with the new
 bindings though, since writing extensions in C is a heck of a lot more
 work and setup then their Python counterparts.
>>>
>>> +1
>>>
 One blocker I'm having at the moment is getting the gnome-builder
 version of Nautilus to recognize extensions. The 'gnome-3-22' branch
 version, to my knowledge, does not support building with Flatpak (or at
 least there was no manifest defined, even though it could be built and
 ran from gnome-builder).
>>>
>>> I'm not really sure if you need to spend time on getting Flatpak build
>>> working. If you build the same (or similar) Nautilus version as is
>>> already installed in the template, all dependencies should be already in
>>> place, so it should be still easy.
> 
>> Is it possible to build just Nautilus with qubes-builder? That may make
>> things much closer to what we want.
> 
> You'll need source package (.spec for rpm for example). You can start
> with upstream source package:
>  - dnf download --source nautilus && rpmdev-extract nautilus*src.rpm
>  - apt-get source nautilus
> 
> Then place resulting files in a subdirectory of qubes-src and add

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Jul 25, 2017 at 08:54:57PM -0700, Andrew Morgan wrote:
> On 07/25/2017 06:23 PM, Marek Marczykowski-Górecki wrote:
> > On Tue, Jul 25, 2017 at 05:52:56PM -0700, Andrew Morgan wrote:
> >> On 07/24/2017 02:33 AM, Andrew Morgan wrote:
> >>> ## Nautilus
> >>>
> >>> The patch for Nautilus is finally getting going! After some hiccups with
> >>> Nautilus' build process, I've now switched to [GNOME
> >>> Builder](https://wiki.gnome.org/Apps/Builder) for the compilation and
> >>> run management of Nautilus. Builder provides a much cleaner experience
> >>> when building and compiling, and after only hearing about it here and
> >>> there, it was exciting to finally download and try it out.
> >>>
> >>> After a couple hiccups with importing the Nautilus code and checking out
> >>> the correct branch (gnome-3-22 in this case) with the help of some fine
> >>> folks on #gnome-builder, Nautilus was building and launching as expected:
> >>>
> >>> ![Nautilus built and running from
> >>> Builder](images/nautilus-gnome-builder.png)
> >>> *Nautilus built and running from Builder*
> >>>
> >>> The other advantage GNOME Builder holds is its ability to build all
> >>> projects as flatpaks. This makes it much easier to share testing builds
> >>> of Nautilus without asking people to install Nautilus' [horrible list of
> >>> dependencies](https://ubuntuforums.org/showthread.php?t=1678656&p=10426119#post10426119),
> >>> and instead just run a single command to start it up!
> >>>
> >>> In addition to Nautilus, GNOME Builder is also helping me with patching
> >>> [nautilus-python](https://wiki.gnome.org/Projects/NautilusPython/),
> >>> which are the python bindings that allow extensions written in python to
> >>> interact with Nautilus' C API.
> >>>
> >>> [This
> >>> folder](https://git.gnome.org/browse/nautilus-python/tree/src/nautilus-python-object.c)
> >>> houses the definitions of functions that can be referenced in
> >>> `nautilus-python` extensions. Nautilus' maintainer, Carlos Soriano, also
> >>> kindly pointed out where these methods connect to Nautilus itself, which
> >>> turns out to be
> >>> [here](https://git.gnome.org/browse/nautilus/tree/libnautilus-extension).
> >>>
> >>> The typical workflow in a `nautilus-python` extension is to define a
> >>> function that corresponds to the data or action you desire, then return
> >>> some data based on some logic you have in your extension. My plan is to
> >>> create another function here that will be called when a file is
> >>> determined to be opened. The file will then be opened depending on
> >>> whether the extension returns a `True` or a `False`.
> >>>
> >>> A new DisposableVM with the file in question can be launched from within
> >>> the extension, so there is no need for any Qubes-specific code to go
> >>> into this patch.
> >>>
> >> To clarify on this after some digging today, Nautilus officially only
> >> supports extensions written in C. There are a few extensions that are
> >> included in Nautilus' source tree (such as the sendto extension), but
> >> all one needs to do to install an extension is to place the extension
> >> library in `/usr/lib(64)/nautilus/extensions-3.0/`, restart Nautilus and
> >> it should be installed.
> > 
> >> NautilusPython is a Nautilus C extension. It's purpose is just to read
> >> python scripts that perform extension actions and translate those into
> >> the C actions Nautilus is used to. It's a completely separate
> >> compatibility layer.
> > 
> >> This is all fine and dandy, and means that if needed, really only
> >> Nautilus (not NautilusPython) would have to be patched to include new
> >> bindings for file open events, and a C Nautilus extension could be
> >> written to make use of it.
> > 
> >> I'm going to strive to have NautilusPython be compatible with the new
> >> bindings though, since writing extensions in C is a heck of a lot more
> >> work and setup then their Python counterparts.
> > 
> > +1
> > 
> >> One blocker I'm having at the moment is getting the gnome-builder
> >> version of Nautilus to recognize extensions. The 'gnome-3-22' branch
> >> version, to my knowledge, does not support building with Flatpak (or at
> >> least there was no manifest defined, even though it could be built and
> >> ran from gnome-builder).
> > 
> > I'm not really sure if you need to spend time on getting Flatpak build
> > working. If you build the same (or similar) Nautilus version as is
> > already installed in the template, all dependencies should be already in
> > place, so it should be still easy.
> 
> Is it possible to build just Nautilus with qubes-builder? That may make
> things much closer to what we want.

You'll need source package (.spec for rpm for example). You can start
with upstream source package:
 - dnf download --source nautilus && rpmdev-extract nautilus*src.rpm
 - apt-get source nautilus

Then place resulting files in a subdirectory of qubes-src and add
Makefile.builder with

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

On 07/25/2017 06:23 PM, Marek Marczykowski-Górecki wrote:
> On Tue, Jul 25, 2017 at 05:52:56PM -0700, Andrew Morgan wrote:
>> On 07/24/2017 02:33 AM, Andrew Morgan wrote:
>>> ## Nautilus
>>>
>>> The patch for Nautilus is finally getting going! After some hiccups with
>>> Nautilus' build process, I've now switched to [GNOME
>>> Builder](https://wiki.gnome.org/Apps/Builder) for the compilation and
>>> run management of Nautilus. Builder provides a much cleaner experience
>>> when building and compiling, and after only hearing about it here and
>>> there, it was exciting to finally download and try it out.
>>>
>>> After a couple hiccups with importing the Nautilus code and checking out
>>> the correct branch (gnome-3-22 in this case) with the help of some fine
>>> folks on #gnome-builder, Nautilus was building and launching as expected:
>>>
>>> ![Nautilus built and running from
>>> Builder](images/nautilus-gnome-builder.png)
>>> *Nautilus built and running from Builder*
>>>
>>> The other advantage GNOME Builder holds is its ability to build all
>>> projects as flatpaks. This makes it much easier to share testing builds
>>> of Nautilus without asking people to install Nautilus' [horrible list of
>>> dependencies](https://ubuntuforums.org/showthread.php?t=1678656&p=10426119#post10426119),
>>> and instead just run a single command to start it up!
>>>
>>> In addition to Nautilus, GNOME Builder is also helping me with patching
>>> [nautilus-python](https://wiki.gnome.org/Projects/NautilusPython/),
>>> which are the python bindings that allow extensions written in python to
>>> interact with Nautilus' C API.
>>>
>>> [This
>>> folder](https://git.gnome.org/browse/nautilus-python/tree/src/nautilus-python-object.c)
>>> houses the definitions of functions that can be referenced in
>>> `nautilus-python` extensions. Nautilus' maintainer, Carlos Soriano, also
>>> kindly pointed out where these methods connect to Nautilus itself, which
>>> turns out to be
>>> [here](https://git.gnome.org/browse/nautilus/tree/libnautilus-extension).
>>>
>>> The typical workflow in a `nautilus-python` extension is to define a
>>> function that corresponds to the data or action you desire, then return
>>> some data based on some logic you have in your extension. My plan is to
>>> create another function here that will be called when a file is
>>> determined to be opened. The file will then be opened depending on
>>> whether the extension returns a `True` or a `False`.
>>>
>>> A new DisposableVM with the file in question can be launched from within
>>> the extension, so there is no need for any Qubes-specific code to go
>>> into this patch.
>>>
>> To clarify on this after some digging today, Nautilus officially only
>> supports extensions written in C. There are a few extensions that are
>> included in Nautilus' source tree (such as the sendto extension), but
>> all one needs to do to install an extension is to place the extension
>> library in `/usr/lib(64)/nautilus/extensions-3.0/`, restart Nautilus and
>> it should be installed.
> 
>> NautilusPython is a Nautilus C extension. It's purpose is just to read
>> python scripts that perform extension actions and translate those into
>> the C actions Nautilus is used to. It's a completely separate
>> compatibility layer.
> 
>> This is all fine and dandy, and means that if needed, really only
>> Nautilus (not NautilusPython) would have to be patched to include new
>> bindings for file open events, and a C Nautilus extension could be
>> written to make use of it.
> 
>> I'm going to strive to have NautilusPython be compatible with the new
>> bindings though, since writing extensions in C is a heck of a lot more
>> work and setup then their Python counterparts.
> 
> +1
> 
>> One blocker I'm having at the moment is getting the gnome-builder
>> version of Nautilus to recognize extensions. The 'gnome-3-22' branch
>> version, to my knowledge, does not support building with Flatpak (or at
>> least there was no manifest defined, even though it could be built and
>> ran from gnome-builder).
> 
> I'm not really sure if you need to spend time on getting Flatpak build
> working. If you build the same (or similar) Nautilus version as is
> already installed in the template, all dependencies should be already in
> place, so it should be still easy.

Is it possible to build just Nautilus with qubes-builder? That may make
things much closer to what we want.

> 
>> The version that was built couldn't find installed extensions however,
>> which lead me to think it was packaged as a Flatpak, with a policy that
>> prevented reading it from the extensions directory. (Though I could
>> navigate to the extensions directory in Nautilus, so presumably you can
>> access it??)
> 
>> Checking out the master branch did reveal a Flatpak manifest
>> (org.gnome.Nautilus.json), however I am unable to build the latest
>> version due to a dependency on glibc v2.51.2 on Fedora 25 (v2.50.3 is
>> installed).
> 
>> Also not even sure if t

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Jul 25, 2017 at 05:52:56PM -0700, Andrew Morgan wrote:
> On 07/24/2017 02:33 AM, Andrew Morgan wrote:
> > ## Nautilus
> > 
> > The patch for Nautilus is finally getting going! After some hiccups with
> > Nautilus' build process, I've now switched to [GNOME
> > Builder](https://wiki.gnome.org/Apps/Builder) for the compilation and
> > run management of Nautilus. Builder provides a much cleaner experience
> > when building and compiling, and after only hearing about it here and
> > there, it was exciting to finally download and try it out.
> > 
> > After a couple hiccups with importing the Nautilus code and checking out
> > the correct branch (gnome-3-22 in this case) with the help of some fine
> > folks on #gnome-builder, Nautilus was building and launching as expected:
> > 
> > ![Nautilus built and running from
> > Builder](images/nautilus-gnome-builder.png)
> > *Nautilus built and running from Builder*
> > 
> > The other advantage GNOME Builder holds is its ability to build all
> > projects as flatpaks. This makes it much easier to share testing builds
> > of Nautilus without asking people to install Nautilus' [horrible list of
> > dependencies](https://ubuntuforums.org/showthread.php?t=1678656&p=10426119#post10426119),
> > and instead just run a single command to start it up!
> > 
> > In addition to Nautilus, GNOME Builder is also helping me with patching
> > [nautilus-python](https://wiki.gnome.org/Projects/NautilusPython/),
> > which are the python bindings that allow extensions written in python to
> > interact with Nautilus' C API.
> > 
> > [This
> > folder](https://git.gnome.org/browse/nautilus-python/tree/src/nautilus-python-object.c)
> > houses the definitions of functions that can be referenced in
> > `nautilus-python` extensions. Nautilus' maintainer, Carlos Soriano, also
> > kindly pointed out where these methods connect to Nautilus itself, which
> > turns out to be
> > [here](https://git.gnome.org/browse/nautilus/tree/libnautilus-extension).
> > 
> > The typical workflow in a `nautilus-python` extension is to define a
> > function that corresponds to the data or action you desire, then return
> > some data based on some logic you have in your extension. My plan is to
> > create another function here that will be called when a file is
> > determined to be opened. The file will then be opened depending on
> > whether the extension returns a `True` or a `False`.
> > 
> > A new DisposableVM with the file in question can be launched from within
> > the extension, so there is no need for any Qubes-specific code to go
> > into this patch.
> > 
> To clarify on this after some digging today, Nautilus officially only
> supports extensions written in C. There are a few extensions that are
> included in Nautilus' source tree (such as the sendto extension), but
> all one needs to do to install an extension is to place the extension
> library in `/usr/lib(64)/nautilus/extensions-3.0/`, restart Nautilus and
> it should be installed.
> 
> NautilusPython is a Nautilus C extension. It's purpose is just to read
> python scripts that perform extension actions and translate those into
> the C actions Nautilus is used to. It's a completely separate
> compatibility layer.
> 
> This is all fine and dandy, and means that if needed, really only
> Nautilus (not NautilusPython) would have to be patched to include new
> bindings for file open events, and a C Nautilus extension could be
> written to make use of it.
> 
> I'm going to strive to have NautilusPython be compatible with the new
> bindings though, since writing extensions in C is a heck of a lot more
> work and setup then their Python counterparts.

+1

> One blocker I'm having at the moment is getting the gnome-builder
> version of Nautilus to recognize extensions. The 'gnome-3-22' branch
> version, to my knowledge, does not support building with Flatpak (or at
> least there was no manifest defined, even though it could be built and
> ran from gnome-builder).

I'm not really sure if you need to spend time on getting Flatpak build
working. If you build the same (or similar) Nautilus version as is
already installed in the template, all dependencies should be already in
place, so it should be still easy.

> The version that was built couldn't find installed extensions however,
> which lead me to think it was packaged as a Flatpak, with a policy that
> prevented reading it from the extensions directory. (Though I could
> navigate to the extensions directory in Nautilus, so presumably you can
> access it??)
> 
> Checking out the master branch did reveal a Flatpak manifest
> (org.gnome.Nautilus.json), however I am unable to build the latest
> version due to a dependency on glibc v2.51.2 on Fedora 25 (v2.50.3 is
> installed).
> 
> Also not even sure if the latest version is compatible with Qubes since
> we use 3.22 Nautilus at the moment..
> 
> Anyways, that's where I stand with all that. IRC has been helpful with

[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7

[Andrew Morgan]

On 07/24/2017 02:33 AM, Andrew Morgan wrote:
> ## Nautilus
> 
> The patch for Nautilus is finally getting going! After some hiccups with
> Nautilus' build process, I've now switched to [GNOME
> Builder](https://wiki.gnome.org/Apps/Builder) for the compilation and
> run management of Nautilus. Builder provides a much cleaner experience
> when building and compiling, and after only hearing about it here and
> there, it was exciting to finally download and try it out.
> 
> After a couple hiccups with importing the Nautilus code and checking out
> the correct branch (gnome-3-22 in this case) with the help of some fine
> folks on #gnome-builder, Nautilus was building and launching as expected:
> 
> ![Nautilus built and running from
> Builder](images/nautilus-gnome-builder.png)
> *Nautilus built and running from Builder*
> 
> The other advantage GNOME Builder holds is its ability to build all
> projects as flatpaks. This makes it much easier to share testing builds
> of Nautilus without asking people to install Nautilus' [horrible list of
> dependencies](https://ubuntuforums.org/showthread.php?t=1678656&p=10426119#post10426119),
> and instead just run a single command to start it up!
> 
> In addition to Nautilus, GNOME Builder is also helping me with patching
> [nautilus-python](https://wiki.gnome.org/Projects/NautilusPython/),
> which are the python bindings that allow extensions written in python to
> interact with Nautilus' C API.
> 
> [This
> folder](https://git.gnome.org/browse/nautilus-python/tree/src/nautilus-python-object.c)
> houses the definitions of functions that can be referenced in
> `nautilus-python` extensions. Nautilus' maintainer, Carlos Soriano, also
> kindly pointed out where these methods connect to Nautilus itself, which
> turns out to be
> [here](https://git.gnome.org/browse/nautilus/tree/libnautilus-extension).
> 
> The typical workflow in a `nautilus-python` extension is to define a
> function that corresponds to the data or action you desire, then return
> some data based on some logic you have in your extension. My plan is to
> create another function here that will be called when a file is
> determined to be opened. The file will then be opened depending on
> whether the extension returns a `True` or a `False`.
> 
> A new DisposableVM with the file in question can be launched from within
> the extension, so there is no need for any Qubes-specific code to go
> into this patch.
> 
To clarify on this after some digging today, Nautilus officially only
supports extensions written in C. There are a few extensions that are
included in Nautilus' source tree (such as the sendto extension), but
all one needs to do to install an extension is to place the extension
library in `/usr/lib(64)/nautilus/extensions-3.0/`, restart Nautilus and
it should be installed.

NautilusPython is a Nautilus C extension. It's purpose is just to read
python scripts that perform extension actions and translate those into
the C actions Nautilus is used to. It's a completely separate
compatibility layer.

This is all fine and dandy, and means that if needed, really only
Nautilus (not NautilusPython) would have to be patched to include new
bindings for file open events, and a C Nautilus extension could be
written to make use of it.

I'm going to strive to have NautilusPython be compatible with the new
bindings though, since writing extensions in C is a heck of a lot more
work and setup then their Python counterparts.

One blocker I'm having at the moment is getting the gnome-builder
version of Nautilus to recognize extensions. The 'gnome-3-22' branch
version, to my knowledge, does not support building with Flatpak (or at
least there was no manifest defined, even though it could be built and
ran from gnome-builder).

The version that was built couldn't find installed extensions however,
which lead me to think it was packaged as a Flatpak, with a policy that
prevented reading it from the extensions directory. (Though I could
navigate to the extensions directory in Nautilus, so presumably you can
access it??)

Checking out the master branch did reveal a Flatpak manifest
(org.gnome.Nautilus.json), however I am unable to build the latest
version due to a dependency on glibc v2.51.2 on Fedora 25 (v2.50.3 is
installed).

Also not even sure if the latest version is compatible with Qubes since
we use 3.22 Nautilus at the moment..

Anyways, that's where I stand with all that. IRC has been helpful with
some answers, but I still have a lot of questions :)

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/ol8p56%245gh%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d