Hello. kde-apps/knotify only provides org.kde.knotify service, but not org.freedesktop.Notifications service. The latter one must be provided by a valid desktop notifications service [1,2]. Because of this, "notify-send 'Foo' 'Bar'" command doesn't show a notification when knotify4 is running outside of KDE session. Please either make knotify provide org.freedesktop.Notifications service or remove it as a provider for virtual/notification-daemon. [1]: https://developer.gnome.org/notification-spec/ [2]: http://www.galago-project.org/specs/notification/0.9/
The spec says: > On startup, a conforming implementation should take the > org.freedesktop.Notifications service on the session bus. This service will be > referred to as the "notification server" or just "the server" in this document. > It can optionally be activated automatically by the bus process, however this > is not required and notification server clients must not assume that it is > available. If I understand correctly (please correct me if I'm wrong, I'm no expert on this), the 4 of 15 virtual/notification-daemon providers that install org.freedesktop.Notifications.service are implementing the optional bus activation, while the others will listen on that interface once launched.
Interestingly kde-misc/colibri, kde-frameworks/knotifications, and x11-libs/snorenotify all provide org.freedesktop.Notifications service. I don't understand upstream KDE people sometimes.
(In reply to Coacher from comment #2) > Interestingly kde-misc/colibri, kde-frameworks/knotifications, and > x11-libs/snorenotify all provide org.freedesktop.Notifications service. > I don't understand upstream KDE people sometimes. While these all listen on that interface once launched, I don't see any of them installing the service file to be automatically activated.
(In reply to Michael Palimaka (kensington) from comment #3) > (In reply to Coacher from comment #2) > > Interestingly kde-misc/colibri, kde-frameworks/knotifications, and > > x11-libs/snorenotify all provide org.freedesktop.Notifications service. > > I don't understand upstream KDE people sometimes. > > While these all listen on that interface once launched, I don't see any of > them installing the service file to be automatically activated. Looking at the part of the spec quoted in comment #1, I don't see how that is a requirement of the spec for a valid desktop notification service. In fact, it appears the spec explicitly allows conforming implementations *not* to be configured to automatically started by the bus process (so that in the case that multiple providers are installed, the bus does not have to guess which one to start).
After closer look kde-frameworks/knotifications also doesn't provide org.freedesktop.Notifications service. It doesn't provide any standalone binary at all. I'll file a new bug shortly.
Why is this suddenly RESOLVED INVALID?
Unless I miss something, knotify complies with the spec as it listens on the appropriate interface once launched. It just doesn't implement the optional automatic activation.
(In reply to Michael Palimaka (kensington) from comment #7) > Unless I miss something, knotify complies with the spec as it listens on the > appropriate interface once launched. It just doesn't implement the optional > automatic activation. You miss something. $ equery list knotify * Searching for knotify ... [IP-] [ ] kde-apps/knotify-16.04.3:4/16.04 $ pgrep -a knotify4 7596 /usr/bin/knotify4 $ qdbus | grep --count 'org.freedesktop.Notifications' 0 Again, this is _outside_ of KDE session. Plasma is not running. knotify on its own is not a provider. Reopening.
I believe plasma-workspace provides the correct dbus service: https://github.com/KDE/plasma-workspace/blob/master/dataengines/notifications/org.freedesktop.Notifications.xml
(In reply to Coacher from comment #9) > I believe plasma-workspace provides the correct dbus service: > https://github.com/KDE/plasma-workspace/blob/master/dataengines/ > notifications/org.freedesktop.Notifications.xml This is an adaptor and also Plasma 5, unrelated to knotify.
(In reply to Michael Palimaka (kensington) from comment #10) > This is an adaptor and also Plasma 5, unrelated to knotify. Ok, then please take a look at this constructor: https://github.com/KDE/plasma-workspace/blob/v4.96.0/dataengines/notifications/notificationsengine.cpp#L36 This is as far back as github and quickgit.kde.org possibly goes. Definitely plasma-workspace provides the right dbus service. Same with Plasma 5: https://github.com/KDE/plasma-workspace/blob/v5.7.2/dataengines/notifications/notificationsengine.cpp#L48
IMHO the right way to fix this bug and bug 589066 is to remove knotify and knotifications from virtual/notification-daemon providers and add kde-base/plasma-workspace and kde-plasma/plasma-workspace.
Seems like plasmashell (part of plasma-workspace) provides the D-Bus service if it's running. Obviously that won't help people who don't want to run a Plasma session. But on the other hand, virtual/notification-daemon today forced me to install some X11 component that I'll never use as a Plasma user, so that's wrong too. I'm not even sure that we should have a virtual at all (it's, after all, the user's responsibility to use a DE or install a specific daemon if he wants to see notifications); but if we're gonna keep it, we should add plasma-workspace to it to avoid unnecessary dependencies for Plasma users.
My thoughts exactly, the current situation is bad, though I can only guess that kde-{base,plasma}/plasma-workspace is the right thing to do.
since there is already "gnome" use-flag, maybe it will be a good solution to add "kde" flag, which will cover dependency from kde-frameworks/plasma-workspace?
Yes, please add kde-plasma/plasma-workspace as a provider. Otherwise x11-misc/notification-daemon gets installed and activated even in Plasma session.
(In reply to Eugene Shalygin from comment #16) > Yes, please add kde-plasma/plasma-workspace as a provider. Otherwise > x11-misc/notification-daemon gets installed and activated even in Plasma > session. Not exactly. For KF5 there should be kde-frameworks/knotifications[dbus] *plus* plasma-workspace. Because kde-frameworks/knotifications has only library required for notifications, while *daemon* is in plasma-workspace.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #17) > (In reply to Eugene Shalygin from comment #16) > > Yes, please add kde-plasma/plasma-workspace as a provider. Otherwise > > x11-misc/notification-daemon gets installed and activated even in Plasma > > session. > > Not exactly. For KF5 there should be kde-frameworks/knotifications[dbus] > *plus* plasma-workspace. Because kde-frameworks/knotifications has only > library required for notifications, while *daemon* is in plasma-workspace. *Assuming* the virtual is about providing org.freedesktop.Notifications, then only plasma-workspace is necessary (which does happen to pull in knotifications, but plasma-workspace itself is what's listening on the bus)
I've pushed a fix for this, please review: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7146f0a1bff65c095594df60f20608a46b2bf8b2
(In reply to Michael Palimaka (kensington) from comment #19) > I've pushed a fix for this, please review: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=7146f0a1bff65c095594df60f20608a46b2bf8b2 As it is already said, the *right* way will probably be ``` kde? ( kde-frameworks/knotifications[dbus] kde-plasma/plasma-workspace ) ``` I just not sure, if just knotifications (which is a depend of plasma-workspace) will be enough, or USE=dbus on it is required. And I've no possibility to check at the moment. Can anybody here check it: Rebuild knotifications with disabled dbus flag, restart kde, run `notify-send moo foo` (requires libnotify to be installed), check the result, and report it here ?
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #20) > Can anybody here check it: > > Rebuild knotifications with disabled dbus flag, > restart kde, > run `notify-send moo foo` (requires libnotify to be installed), > check the result, > and report it here > ? If this fails, we should update the dependency in plasma-workspace.
The new dependencies force users of desktop/kde profile to switch to plasma 5. Is KDE SC 4 officially deprecated?
afaik, yes, it is.
notify-send works fine here, so probably kde-base/plasma-workspace could be added as an alternative to kde-plasma/plasma-workspace?
There is no forcing of Plasma-5 here, the dependency is satisfied by any of the other alternatives listed in the ebuild without USE=kde. knotify:4 can be installed manually still. It probably won't be added back for the very limited time that Plasma-4 has left in tree.
bad code: gnome? ( || ( x11-misc/notification-daemon gnome-base/gnome-shell ) ) kde? ( kde-plasma/plasma-workspace ) !gnome? ( !kde? ( || ( 1) For Plasma 5 to use global USE-flag plasma, but do not kde. 2) IUSE="gnome kde" do not need. construction RDEPEND = " (|| ( package list )) " It assumes one of a elements in the list. man 5 ebuild "Here only one of the packages will be chosen, and the order of preference is determined by the order in which they appear. Note that if any of the packages listed are already merged, the package manager will use that to consider the dependency satisfied." 3) end element - kde-frameworks/knotifications, but do not kde-plasma/plasma-workspace notification-daemon > plasma-workspace > knotifications notification-daemon: notification-daemon displays passive pop-up notifications, as per the Desktop Notifications Specification. In Gentoo it is implemented as a virtual package. plasma-workspace: Plasma Workspace for KF5. Workspaces provide support for KDE Plasma Widgetsе. knotifications: Framework for desktop notifications. KNotification is used to notify the user of an event. It covers feedback and persistent events. notification-daemon-0.diff 14c14 < IUSE="gnome kde" --- > IUSE="" 17,32c17,33 < gnome? ( || ( x11-misc/notification-daemon < gnome-base/gnome-shell ) ) < kde? ( kde-plasma/plasma-workspace ) < !gnome? ( !kde? ( || ( < x11-misc/notification-daemon < gnome-extra/cinnamon < xfce-extra/xfce4-notifyd < x11-misc/qtnotifydaemon < x11-misc/notify-osd < x11-misc/dunst < >=x11-wm/awesome-3.4.4 < x11-wm/enlightenment[enlightenment_modules_notification] < x11-wm/enlightenment[e_modules_notification] < x11-misc/mate-notification-daemon < lxqt-base/lxqt-notificationd < kde-misc/colibri ) ) )" --- > ( || ( > x11-misc/notification-daemon > gnome-base/gnome-shell > gnome-extra/cinnamon > xfce-extra/xfce4-notifyd > x11-misc/qtnotifydaemon > x11-misc/notify-osd > x11-misc/dunst > >=x11-wm/awesome-3.4.4 > x11-wm/enlightenment[enlightenment_modules_notification] > x11-wm/enlightenment[e_modules_notification] > kde-apps/knotify > kde-frameworks/knotifications > kde-misc/colibri > x11-misc/mate-notification-daemon > lxqt-base/lxqt-notificationd ) ) > "
https://api.kde.org/frameworks/knotifications/html/classKNotification.html
(In reply to Fedor_Rus from comment #26) > 1) For Plasma 5 to use global USE-flag plasma, but do not kde. I don't think it's worth the effort to introduce a new global USE flag just for Plasma 5 when KDE 4 is long dead and will be removed soon. > 2) IUSE="gnome kde" do not need. construction > RDEPEND = " > (|| ( > package list > )) " > It assumes one of a elements in the list. > man 5 ebuild > "Here only one of the packages will be chosen, and the order of preference > is determined by the order in which they appear. > Note that if any of the packages listed are already merged, the package > manager will use that to consider the dependency satisfied." The problem is this can result in multiple notification daemons being installed at once. Prior to the kde USE flag, we had complaints that x11-misc/notification-daemon was still getting pulled in resulting in every notification being displayed twice. > 3) end element - kde-frameworks/knotifications, but do not > kde-plasma/plasma-workspace > notification-daemon > plasma-workspace > knotifications > notification-daemon: notification-daemon displays passive pop-up > notifications, as per the Desktop Notifications Specification. In Gentoo it > is implemented as a virtual package. > plasma-workspace: Plasma Workspace for KF5. Workspaces provide support for > KDE Plasma Widgetsе. > knotifications: Framework for desktop notifications. KNotification is used > to notify the user of an event. It covers feedback and persistent events. knotifications is just a library and does not do anything on its own. The package that actually listens on org.freedesktop.Notifications is plasma-workspace - see comment #11.
> I don't think it's worth the effort to introduce a new global USE flag just > for Plasma 5 when KDE 4 is long dead and will be removed soon.I did not invent this flag grep plasma /usr/portage/profiles/use.desc plasma - Build optional KDE plasma addons grep kde /usr/portage/profiles/use.desc kde - Add support for KDE (K Desktop Environment) > Prior to the kde USE flag, we had complaints that > x11-misc/notification-daemon was still getting pulled in resulting in every > notification being displayed twice. Unlikely. I checked empirically. >The > package that actually listens on org.freedesktop.Notifications is > plasma-workspace - see comment #11. See website KDE developers https://api.kde.org/frameworks/knotifications/html/classKNotification.html It is also sold in other distributions, for example, Debian.
'KDE plasma addons' = actual plasmoids on the desktop
using kde instead of the reservoir, we can face the duality - kde 4.x + plasma 5 in one system. It is not compatible.
It seems there is nothing left to do here.
By the way, maybe we would really replace `kde-plasma/plasma-workspace` with `kde-frameworks/knotifications`. Just to be correct. Yes, *USUALLY* user would prefer plasma-workspace, but in some cases it can be plasma-mediacenter, or even some 3party KDE-based workspace. And in all of the cases, notifications are managed by that "libraries-only" `knotifications` package (which is a part of KF5 API and will be loaded by all of the workspaces, if they interested in notifications at all)
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #33) > By the way, maybe we would really replace `kde-plasma/plasma-workspace` with > `kde-frameworks/knotifications`. > Just to be correct. This is the opposite of correct. knotifications doesn't conform to spec, so it can't be a provider.
(In reply to Coacher from comment #34) > knotifications doesn't conform to spec which? > so it can't be a provider. even knotifications[dbus]? :)
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #35) > (In reply to Coacher from comment #34) > > knotifications doesn't conform to spec > which? Read the first comment. > > so it can't be a provider. > even knotifications[dbus]? :) Even knotifications[dbus].
Well, looks like, it is conflict between gnome notification spec and KDE development sceme: It is definitely knotifications, what manages notifications and provides DBUS handler. And some KDE devs says that plasma-workspace is much more common things that has nothing to do with notifications by itself (without knotifications). By the way, talking on issue with "old" knotify: unfortunately, KDE software is known to be not intended to run outside of KDE environment. But anyway, setting "plasma-workspace" as the provider is not fully correct (from KDE upstream point of view, at least) too.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #37) > It is definitely knotifications, what manages notifications and provides > DBUS handler. Looking at the source, it appears that plasma-workspace is still what listens on org.freedesktop.Notifications.
