Bug 16295 - xdg-open can invoke interaction on KDE
Summary: xdg-open can invoke interaction on KDE
Status: RESOLVED MOVED
Alias: None
Product: Portland
Classification: Unclassified
Component: xdg-utils (show other bugs)
Version: 1.0
Hardware: Other All
: medium normal
Assignee: Fathi Boudra
QA Contact:
URL:
Whiteboard:
Keywords:
: 36126 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-06-10 11:00 UTC by Francois Gouget
Modified: 2019-02-16 13:29 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Francois Gouget 2008-06-10 11:00:48 UTC
* 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?
Comment 1 Nicolas Lécureuil 2009-08-03 14:14:59 UTC
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 ?
Comment 2 Francois Gouget 2009-08-03 23:58:32 UTC
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.
Comment 3 Pablo Castellano (pablog) 2010-04-30 04:44:10 UTC
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?
Comment 4 Pablo Castellano (pablog) 2010-04-30 04:47:14 UTC
That is, in gnome:

xdg-open foo.txt returns immediately with error code 0
xdg-open foo.noassoc returns immediately with error code 4
Comment 5 Francois Gouget 2010-04-30 08:37:54 UTC
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.
Comment 6 Rex Dieter 2010-11-18 14:33:10 UTC
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.
Comment 7 Rex Dieter 2011-04-14 07:36:30 UTC
*** Bug 36126 has been marked as a duplicate of this bug. ***
Comment 8 Rex Dieter 2011-04-14 07:38:12 UTC
fyi, blocking on kde upstream bug
https://bugs.kde.org/show_bug.cgi?id=269823
before implementing the use of kde-open --noninteractive
Comment 9 freedesktop.mrbax 2012-12-04 11:37:11 UTC
(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.
Comment 10 Rex Dieter 2012-12-04 12:32:36 UTC
it calls kde4-config when/if kde is present
Comment 11 freedesktop.mrbax 2012-12-04 12:44:50 UTC
> 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.
Comment 12 Rex Dieter 2012-12-04 13:09:48 UTC
both git and
http://portland.freedesktop.org/download/xdg-utils-1.1.0-rc1.tar.gz
are fixed to use kde4-config
Comment 13 freedesktop.mrbax 2012-12-04 13:18:56 UTC
> 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?
Comment 14 Rex Dieter 2012-12-04 13:21:03 UTC
chances are good.
Comment 15 Rex Dieter 2014-04-26 22:29:36 UTC
http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=869b22b75fc6e7c9e29ba5367bd97ebf7ce76cb3

sorry for the delay, but better late than never.
Comment 16 Rex Dieter 2014-06-30 12:55:59 UTC
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
Comment 17 Reuben Thomas 2014-12-18 22:49:44 UTC
Should this bug be retitled to be specific to kde-open now?
Comment 18 Francois Gouget 2014-12-19 10:15:53 UTC
(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.
Comment 19 Rex Dieter 2014-12-19 15:22:39 UTC
Agreed, added
https://bugs.kde.org/show_bug.cgi?id=336117
Comment 20 GitLab Migration User 2019-02-16 13:29:14 UTC
-- 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.