On Tue, 2015-07-28 at 15:07 +0200, Carlos E. R. wrote:
On 2015-07-28 14:57, Dimstar / Dominique Leuenberger wrote:
On Tue, 2015-07-28 at 14:53 +0200, Carlos E. R. wrote:
It would be better if applications, when the user tried to use a feature that lacks those extra packages, would at least hint what exact extra packages are missing. Even perhaps trigger yast on a click with those packages selected.
Carlos,
please read my follow-up mail in this thread, which explains what totem (the GNOME Video Player) already does in combination with PackageKit/GNOME-Software.
Yes, I saw that a minute later. Yes, that's the way to do it.
However, I was not thinking of multimedia, but rather of any package installation. There are mandatory dependencies which have to be installed, but there are recommends that can be ignored.
Later, perhaps months later, when you try to use some feature of that package you notice it does not work. It would be nice if it were possible to automatically suggest that instant to install what is missing, instead of fail with missing symbol or some other cryptic message.
Indeed, I could imagine some cases where this could work - the 'problem' is that in most cases we're talking about extensions/plugins.. of which an infinite number can exist. The main application has generally no way of knowing what can be possible. so, if this were to be done, the app would need to have a 'specific' way to 'name' possible features, and the package a specific way to provide this (in multimedia packages this is done with a provides in the form gstreamer1(decoder-video/mpeg)(mpegversion=4) for example). For evince (which is extensible by modules) I could imagine it to query the package manager by evince(application/pdf) when the pdf module is missing (as an example). This, as opposed to the current error message Unable to open document “file:///path/to/document.pdf”. File type PDF document (application/pdf) is not supported This is currently not implemented, but would likely be rather trivial (with the packagekit dbus api). I guess that's the direction you meant to lead to, right? Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>