Review Request 123313: Add Dolphin DBus interface

[David Edmundson]

> On April 14, 2015, 9:53 p.m., Xuetian Weng wrote:
> > Woundn't this change make dolphin and nautilus not co-installable?
> > Nautilus also installs this file /usr/share/dbus-1/services/org.freedesktop.FileManager1.service.
> 
> David Edmundson wrote:
>     you shouldn't need to make the filename match the service name.
>     
>     We can and should rename ours to something else.
>     Also nautilus should too.
> 
> Xuetian Weng wrote:
>     dbus daemon could not select which service to activate AFAIK. And we have konqueror as a possible alternative file manager (Or whatever file manager).
>     
>     After read the whole discussion, especially this one: http://lists.freedesktop.org/archives/xdg/2011-May/011971.html
>     I think the best solution for us is, add this dbus service to kded, and let kded use KDE's API to launch user configured file manager.
>     
>     As long as kded owns such dbus name on login, dbus activation will not be triggered. .service file is not even necessary in this case.
>     
>     In order to make use some dolphin specific feature, some hack could be done in kded to see if the file manager is configured dolphin (for start and select file option).
> 
> Emmanuel Pescosta wrote:
>     > We can and should rename ours to something else.
>     
>     +1
>     
>     > I think the best solution for us is, add this dbus service to kded, and let kded use KDE's API to launch user configured file manager.
>     
>     I don't think so.
>     IMO choosing the *best* dbus service implementation for a specific dbus interface should be done on dbus (or equal low) level, just imagine a world (sandboxing 
>     for example) with tens of different dbus interfaces like the file-manager-interface, implementing the service implementation selection in kded won't scale well.
>     Also when you see such a dbus interface as a capability of an application (e.g. I can show files/folders, I can share ..., I can ...) and
>     one application can implement multiple dbus interfaces, it will become really difficult with the kded approach. It would be great if the user can select
>     the default application (if there are multiple applications which provide the same inferface implementation) for such a capability (dbus interface) on 
>     first usage. ;)
>     
>     Also this won't fix the problem with other file-manager-interface providers e.g. Gnome Files. (kded <-> Gnome Files vs. Dolphin <-> Gnome Files)
> 
> Xuetian Weng wrote:
>     But we are not in the ideal world, and I don't think such thing would be done in the future. The original propose of this spec is to replace xdg-open that checks the environment with script. dbus-daemon is a shared implementation, not like desktop interpreting desktop file with extension.
>     
>     Nowadays, desktop specific shared service is done by starting a daemon from the very beginning of the session, instead of relying on dbus activation. For example, gnome-keyring and ksecretservice, powerdevil and gnome-settings-daemon.
>     
>     The possible way to do this right is to
>     1. have a separate daemon for dolphin.
>     2. put it in kded.
>     3. implement this interface in dolphin and make dolphin a unique application daemon.
>     
>     I don't think option 1 or 2 make too much difference. Since you mentioned 3 may require more work for now, 1/2 might be easier to go.
>     For 1/2, it can be either dolphin specific code (only able to talk to dolphin), or use kde standard interface, or both.
>     
>     And 1/2 would save some memory comparing to 3, but 3 may speed up dolphin launch speed.
>     
>     If kded is generic, it will only read the kde's confiugration (systemsettings -> application -> default file manager). And since a daemon already owns the dbus name, gnome files will not be able to take the name away from kded.
> 
> David Edmundson wrote:
>     This is nothing like powerdevil. 
>     
>     This is *exactly* what dbus activatation is for, and working round it by proxying every method is silly.
>     
>     Worst case we make the dbus activation exec line invoke xdg-open.
> 
> Xuetian Weng wrote:
>     The worst case you mentioned is against the purpose of this dbus spec.
>     The best solution for us to avoid proxying is to make dolphin a unique daemon that starts with kde desktop.

No it isn't.

the purpose of this spec is to be able to invoke specific methods on the file manager.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123313/#review78942
-----------------------------------------------------------


On April 10, 2015, 3:18 p.m., Ashish Bansal wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123313/
> -----------------------------------------------------------
> 
> (Updated April 10, 2015, 3:18 p.m.)
> 
> 
> Review request for Dolphin, David Edmundson, Emmanuel Pescosta, and Eike Hein.
> 
> 
> Bugs: 343016
>     https://bugs.kde.org/show_bug.cgi?id=343016
> 
> 
> Repository: dolphin
> 
> 
> Description
> -------
> 
> Implemented org.freedesktop.FileManager1 dbus interface in dolphin
> 
> http://www.freedesktop.org/wiki/Specifications/file-manager-interface/
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt daf9271 
>   cmake/DbusInterfaceMacros.cmake PRE-CREATION 
>   cmake/PkgConfigGetVar.cmake PRE-CREATION 
>   org.freedesktop.FileManager1.service.in PRE-CREATION 
>   src/CMakeLists.txt 89a4e43 
>   src/dbusinterface.h PRE-CREATION 
>   src/dbusinterface.cpp PRE-CREATION 
>   src/main.cpp 1c0fdab 
> 
> Diff: https://git.reviewboard.kde.org/r/123313/diff/
> 
> 
> Testing
> -------
> 
> Works fine with dbus-send, firefox.
> But sadly does not works with chromium, probably chromium had not implemented it yet!
> 
> 
> Thanks,
> 
> Ashish Bansal
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20150415/033cd689/attachment.htm>