FS#56547 - [qt5-base] xdg-open not installed by default in graphical systems
Attached to Project:
Arch Linux
Opened by Oleh Prypin (oprypin) - Saturday, 02 December 2017, 23:53 GMT
Last edited by Antonio Rojas (arojas) - Tuesday, 05 December 2017, 17:43 GMT
Opened by Oleh Prypin (oprypin) - Saturday, 02 December 2017, 23:53 GMT
Last edited by Antonio Rojas (arojas) - Tuesday, 05 December 2017, 17:43 GMT
|
Details
xdg-open is quite an important part of a modern system. Many
applications rely on it to open a URL or a document in the
default configured application for the type -- and it's good
that they do, because it's the most portable tool with such
functionality. It also provides integration with common
desktop environments. For example, applications configured
in "(KDE) systemsettings5 > Default Applications" will
take effect on xdg-open. Qt uses xdg-open to open all URLs
(including local files):
https://github.com/qt/qtbase/search?q=xdg-open
-- which indisputably means that, at the very least, it
should be an optional dependency of
https://www.archlinux.org/packages/extra/x86_64/qt5-base
but I would argue for making it required.
https://www.archlinux.org/packages/extra/any/xdg-utils/ is a dependency of https://www.archlinux.org/packages/extra/x86_64/qt4/ and https://www.archlinux.org/packages/extra/x86_64/chromium/ which has been keeping things sane, but only coincidentally, and with the decline of Qt 4 more and more unsuspecting people will get erratic behaviors from applications. For example, recently a user wrote in IRC about a problem where a Qt application would open Firefox when asked to view the contents of a local directory. I happened to know that this could mean a misconfigured xdg-open, but I never expected that the user wouldn't have it installed at all! Installing xdg-utils fixed the problem, and the file manager configured in KDE System Settings was used from then on. It's appalling that even https://www.archlinux.org/packages/extra/any/plasma-meta/ (which I assume this user had installed) does not bring xdg-open with it, and so core system integration functionality is missing. I think people expect such basic functionality to just work, and usually have no idea what causes these weird behaviors, so they might just blame KDE or Linux in general. Such hidden breakages are what really damages the reputation. |
This task depends upon
Closed by Antonio Rojas (arojas)
Tuesday, 05 December 2017, 17:43 GMT
Reason for closing: Fixed
Additional comments about closing: in svn
Tuesday, 05 December 2017, 17:43 GMT
Reason for closing: Fixed
Additional comments about closing: in svn
You got it backwards. xdg-open will call kde-open5 (ie. kio) if run in KDE, not the other way around
"Qt uses xdg-open to open all URLs (including local files): https://github.com/qt/qtbase/search?q=xdg-open"
That search you posted shows that the only use of xdg-open in all Qt source is some heuristics to detect the web browser - not sure how you got that "Qt uses xdg-open to open all URLs"
xdg-open should be a dependency of applications that call xdg-open, and nothing else.
As for that search result, notice how checkExecutable() modifies the browser variable, which is then passed out of the oddly named detectWebBrowser() into launch() which can of course be run by either openUrl(), or openDocument() with checkBrowserVariable=false.
So yeah, Qt5 is calling xdg-open by default, assuming it can find it (and falling back on either $BROWSER, or KDE/Gnome specific openers depending on what it can detect, although of course it should be migrated to badly detecting more up-to-date things like gvfs-open rather than gnome-open).
But it should ultimately fail with qWarning("Unable to detect a launcher for '%s'", qPrintable(url.toString()));
...
I *think* that Firefox should only be opening if 1) xdg-open is not installed, and 2) some application uses openUrl() instead of openDocument() to open file:// paths, and 3) the user explicitly set the $BROWSER variable instead of or in addition to setting mimeapps.list preferences (probably via gvfs-open)
That being said, failing with "Unable to detect a launcher" is still kind of bork IMHO.
I omitted this irrelevant detail, which doesn't make what I said wrong.
> not sure how you got that "Qt uses xdg-open to open all URLs"
This is well explained by Eli.
> xdg-open should be a dependency of applications that call xdg-open, and nothing else.
OK, please go through every application and check whether or not it (possibly transitively) uses xdg-open. To save you a tiny bit of hassle, the application mentioned above is qBittorrent - it calls xdg-open through Qt.
This seems incorrect. Qt uses xdg-open primarily (if available) and that choice has no relation to KDE or GNOME.
> so I'll make it a dependency
Of what?