open file in directory action

[David Faure]

On Monday 22 April 2013 22:35:38 Hans de Goede wrote:
> Hi,
> 
> On 04/22/2013 09:15 PM, David Faure wrote:
> > On Sunday 21 April 2013 23:22:39 Hans de Goede wrote:
> >> That threads talks about a d-bus interface, which seems unnatural
> >> to me, since for all other kind of open actions, we use mime-types ->
> >> application logic.
> > 
> > But only for the basic "open this file in an application that supports
> > this type of file" action.
> 
> Which is exactly what we want here...

Well, not exactly.

One could write a .desktop file that associates a file manager with all files 
( MimeType=application/octet-stream; )
and an Exec line that contains --select. That would work, but surely you don't 
want this to end up as the default assocation for any type of file.

So it doesn't exactly fit into the "open this file" (when clicking on it) 
paradigm.

It's more of a separate voluntary action "select in preferred file manager".

> > For everything else, more is needed. And doing that multiplying the
> > command- line hacks (I think anyone opening the code of xdg-open will
> > agree with that assesment) doesn't sound right, nor is inventing
> > special-case mimetypes.
> > 
> > Instead, allowing DBus method calls in the newly-started or
> > already-running
> > app allows to extend the available functionality to infinity.
> > 
> >> As discussed in that thread, the dbus interface
> >> idea adds nothing that allows the user to specify which file-manager
> >> he wants to use (similar to how the user can select a preferred browser
> >> and a preferred mail client).
> > 
> > The recently discussed (but not yet formalized) "Intents" spec will allow
> > to do exactly that:
> > 1) pick the preferred file manager from .desktop files
> > (including the possibility for the user to change preference using a local
> > file, similar to mimeapps.list)
> > 2) start it if not already running (knowing for sure which DBus name it
> > will register under)
> 
> This is inherently racy, and when we loose the race, depending on the
> filemanager in question we may end up with 2 different windows. 

DBus activation is not racy. You cannot end up with two processes.
And if the activated service starts without a window, you cannot end up with 2 
windows either.

> Also most
> filemanagers will throw up a default window, and then one more for the dbus
> call, so if the filemanager is not running you end up with 2 windows.
> nautilus has --no-default-window to fix this, others may have something too,
> but this is not exactly simplifying the problem. 

And konqueror has --silent. But you don't have to deal with any of that 
yourself; when implementing the intents spec, the 
nautilus/konqueror/dolphin/etc. developers will provide appropriate .service 
files (including the right Exec line for not showing a window on startup).

> Really d-bus is an over-engineered solution for this

Not if you take into account the myriad of other "intents".
But I'll let Jérôme present the full intents spec that he's drafting, for full 
details and lots of examples.

> > 3) make a dbus call to it, using a pre-agreed dbus interface, in this
> > example "select these files".
> > This is much more flexible, because whichever your next request will be,
> > it
> > can be added to that method call, or additional method can be added.
> 
> There is no next request nautilus --select or dolphin --select, or
> konqueror --select does exactly what most apps want here, and is nice and
> simple. All we need is for a desktop-neutral way to do call the user's
> preferred file-manager with --select (or its equivalent).

Yes, this is your current need today. Tomorrow you or someone else will ask 
about starting a camera app (or using a running one) and getting a picture 
back. Then it will be about starting an image *editor* and not an image 
*viewer*. And later on it will be about starting a PDF reader but immediately 
activating the "print" functionality. Should we have a --print option for 
that? It never ends. The DBus-based intents spec can solve all this without 
turning the command line into a full-fledged javascript engine or something 
like that.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5