GNOME Bugzilla – Bug 781132
mime-actions: launch default uri handlers when activating files
Last modified: 2017-05-13 20:04:13 UTC
So it’s more Flatpak-friendly.
Created attachment 349602 [details] [review] program-choosing: reindent header
Created attachment 349603 [details] [review] mime-actions: launch default uri handlers when activating files Currently, Nautilus tries to find the default applications for files itself, which does not work well in a sandbox. This commit makes Nautilus blindly launch the default applications, which makes use of the documents portal indirectly.
Created attachment 349604 [details] [review] mime-actions: launch default uri handlers when activating files Currently, Nautilus tries to find the default applications for files itself, which does not work well in a sandbox. This commit makes Nautilus blindly launch the default applications, which makes use of the documents portal indirectly.
Review of attachment 349604 [details] [review]: /me Looking forward to have this Some work needed still: ::: src/nautilus-mime-actions.c @@ +1567,3 @@ + while ((uri = g_queue_pop_head (params->unhandled_uris)) != NULL) + { + activation_params->parent_window, Problem here is hat is useless for Flatpaked Nautilus. Maybe we can avoid this situation? Although detecting whether you are in Flatpak environment or not is hacky, we can do something about it. Look what gnome-builder or gnome-recipes does for showing the git commit in the about dialog (and that would be another nice addition for our Flatpak integration btw :P) ::: src/nautilus-program-choosing.c @@ +451,3 @@ + launch_context = get_launch_context (parent_window); + + GAsyncReadyCallback callback, instead of this dance, you should just use gtk_show_uri_on_window. You also avoid not having the portal dialog parented to the window. This probably requires a GTask to not block the UI, but I think we discussed this already, no? @@ +460,3 @@ + GError **error) +{ + launch_context = get_launch_context (parent_window); User cancelling the program dialog shouldn't be an error. So we should check this here and return TRUE in that case, ignoring the "error"
Review of attachment 349602 [details] [review]: Sure, but I think what I will do is to just run uncrustify in the headers and let's see what happens
Created attachment 350226 [details] [review] mime-actions: launch default uri handlers when activating files Currently, Nautilus tries to find the default applications for files itself, which does not work well in a sandbox. This commit makes Nautilus blindly launch the default applications, which makes use of the documents portal indirectly.
There are some weird issues with the focusing and modality of the app chooser. Not sure what’s the deal with that.
Created attachment 350227 [details] [review] mime-actions: launch default uri handlers when activating files Currently, Nautilus tries to find the default applications for files itself, which does not work well in a sandbox. This commit makes Nautilus blindly launch the default applications, which makes use of the documents portal indirectly.
Review of attachment 350227 [details] [review]: Tryting it on a sandbox, canceling the dialog raises an error "no application can handle this". Is it nos possible to discern this one? Also it's not modal to the main window. Does this happen also in Recipes or so? (I believe is from where you took the code). I'm trying with Wayland in here. ::: src/nautilus-program-choosing.c @@ +442,3 @@ +/* HAX + * + * TODO: remove everything below once it’s doable from GTK+. can you explain a little beter here, what is the thing we want in a short sentence, and a link to the bug report?
(In reply to Carlos Soriano from comment #9) > Review of attachment 350227 [details] [review] [review]: > > Tryting it on a sandbox, canceling the dialog raises an error "no > application can handle this". Is it nos possible to discern this one? We discussed this a couple of times, but didn’t reach a consensus. Should that be removed altogether or special-cased in a sandboxed environment? Anyway, I thought that could be changed in a separate patch. > Also it's not modal to the main window. Does this happen also in Recipes or > so? I alluded to that in comment 7. In our discussion yesterday, Matthias mentioned that there is a problem with window handles in Wayland (there can only be one). On X, the dialog *appears* to be modal (the background dims), but I can still interact with the parent window. I’ll see if that’s an issue on our side, though. > (I believe is from where you took the code). No, I took it from GTK+, as did Matthias. > I'm trying with Wayland in here. > > ::: src/nautilus-program-choosing.c > @@ +442,3 @@ > +/* HAX > + * > + * TODO: remove everything below once it’s doable from GTK+. > > can you explain a little beter here, what is the thing we want in a short > sentence, and a link to the bug report? Sure.
Created attachment 350311 [details] [review] mime-actions: launch default uri handlers when activating files Currently, Nautilus tries to find the default applications for files itself, which does not work well in a sandbox. This commit makes Nautilus blindly launch the default applications, which makes use of the documents portal indirectly.
Review of attachment 350311 [details] [review]: Code looks good. Now lets figure out the modality bug if possible.
Let's commit this, I think it's fine have the modality bug for now to give some awareness, and we are really early in the cycle. We can revert later on if no solution is found.
Attachment 349602 [details] pushed as a4931f4 - program-choosing: reindent header Attachment 350311 [details] pushed as f5206a6 - mime-actions: launch default uri handlers when activating files
I'm now getting a crash on opening files by double clicking on them https://paste.gnome.org/pupwe7smt Reverting f5206a6 fixes the crash.
Created attachment 351792 [details] [review] mime-actions: check for valid error before dereferencing After launching a URI, the code checks if the operation has been canceled, but does not check if the error pointer is valid.
Comment on attachment 351792 [details] [review] mime-actions: check for valid error before dereferencing Attachment 351792 [details] pushed as 1e898de - mime-actions: check for valid error before dereferencing