| Summary: | xdg-open can invoke interaction on KDE | ||
|---|---|---|---|
| Product: | Portland | Reporter: | Francois Gouget <fgouget> |
| Component: | xdg-utils | Assignee: | Fathi Boudra <fabo> |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | freedesktop.mrbax, rdieter, urxmurx |
| Version: | 1.0 | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=269823 https://bugs.kde.org/show_bug.cgi?id=336117 |
||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
for the first poing, under kde 4.3 i can't reproduce. As soon as the application is start xdg-open returns. for the second this is how kde works so i don't think we can do anything. Fabo, what do you think about this ? Maybe the way to go is to get Gnome/KDE to add options to their respective tools so that it is possible to get a consistent behavior in xdg-open. What's the status of this bug? Since from last comment have passed 8 months. I have just checked and in gnome 2.30 the behavior is the same as explained in the bugreport. What about KDE? That is, in gnome: xdg-open foo.txt returns immediately with error code 0 xdg-open foo.noassoc returns immediately with error code 4 I retested on Fedora Core 12 which has KDE 4.4.2: xdg-open foo.txt returns immediately with exit code 0. xdg-open foo.noassoc blocks and pops up a dialog asking what one wants to do. When you click on Cancel you get an exit code of 0. Based on the feedback here, seems we cant rely on the exit code of xdg-open's helper applications (kde-open in particular). Though, it would appear, we should be using kde-open --noninteractive to avoid those potential popups. *** Bug 36126 has been marked as a duplicate of this bug. *** fyi, blocking on kde upstream bug https://bugs.kde.org/show_bug.cgi?id=269823 before implementing the use of kde-open --noninteractive (In reply to comment #8) > fyi, blocking on kde upstream bug > https://bugs.kde.org/show_bug.cgi?id=269823 > before implementing the use of kde-open --noninteractive The upstream bug is now RESOLVED FIXED. A key benefit of using kde-open is KDE 4 compatibility: in kfmclient work-around code, xdg-open now calls kde-config which does not exist in KDE 4. it calls kde4-config when/if kde is present > it calls kde4-config when/if kde is present In the latest stable release available from http://portland.freedesktop.org/download, xdg-utils 1.0.2, it calls kde-config. both git and http://portland.freedesktop.org/download/xdg-utils-1.1.0-rc1.tar.gz are fixed to use kde4-config > both git and
> http://portland.freedesktop.org/download/xdg-utils-1.1.0-rc1.tar.gz
> are fixed to use kde4-config
Good to know.
What chance of upgrading to use the lighter-weight "kde-open --noninteractive" by the next stable release, now that the upstream bug has been fixed?
chances are good. http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=869b22b75fc6e7c9e29ba5367bd97ebf7ce76cb3 sorry for the delay, but better late than never. commit 8369f878c08b435ecd5523b4c49eff36348c4bae Author: Rex Dieter <rdieter@math.unl.edu> Date: Mon Jun 30 07:54:50 2014 -0500 Revert "xdg-open: use 'kde-open --noninteractive' (BR16295)" This reverts commit 869b22b75fc6e7c9e29ba5367bd97ebf7ce76cb3. kde-open --noninteractive is still crashy :( https://bugs.kde.org/show_bug.cgi?id=336117 Should this bug be retitled to be specific to kde-open now? (In reply to Reuben Thomas from comment #17) > Should this bug be retitled to be specific to kde-open now? This still impacts xdg-open so I think the title should remain as is. However it should link to the 'kde-open --noninteractive' bug. Agreed, added https://bugs.kde.org/show_bug.cgi?id=336117 -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/26. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
* xdg-open may or may not return immediately For instance try: echo Bar >foo.txt xdg-open foo.txt In Gnome xdg-open returns immediately while in KDE / Mailcap it blocks until the application exits. * xdg-open may or may not return an error when the association is missing For instance try: dd bs=1 count=20 if=/dev/random of=foo.noassoc xdg-open foo.noassoc In Gnome / Mailcap it returns immediately with a non-zero exit code, while in KDE blocks while it opens a dialog asking what application to open the file with. If you click cancel in that dialog xdg-open exits with zero as the exit code. These two properties make it very hard for a GUI application to know if the file was opened correctly or not as you cannot rely on its exit code. Not only could it very well be zero in the case of a missing association, but how long should one wait to obtain it?