[Differential] [Commented On] D4663: Allow setting the timeout value.
Martin Klapetek
noreply at phabricator.kde.org
Wed Feb 22 02:36:55 UTC 2017
mck182 added a comment.
> I don't think that KNotification as a framework should hide this feature from the developer.
I, on the other hand, don't see why the developer should need
this feature; as I said before - there's no scenario where the
app should want either really short or really long time on the
screen - this should always be fully up to the shell displaying
the notifications. If you do need to have the notification bubble
on the screen for really long time, then imho that's a wrong
solution to the problem it'd be solving.
And that applies to this case as well. KDE's Bluetooth integration
is solving the same problem (pairing devices) and it uses a dialog,
which imho makes sense, because with notification you're supposed
to inform the user that something has happened and he may or may
not react to that something, while what you're doing requires direct
user interaction and what you're trying to solve is the possible lack
of that direct interaction. So I honestly think that a notification is not
even the right approach here altogether.
> they do that using the notifications cross-desktop standard. So I wouldn't criticize Gnome for doing their own thing here.
Oh really? :) Ever wondered why the spec you're referring to
is full of only Gnome's extensions and is hosted on Gnome's
servers? It's because Gnome considers the Galago project,
the actual cross-desktop notifications project, dead. They took
over libnotify and they consider that implementation to be the
canonical upstream for the specification. In other words, Gnome
has full control over that spec, can do what they want and can just
as easily block any of our contributions. Sure, it is based and
backwards-compatible with the cross-desktop standard, but it
stopped being actual cross-desktop standard long time ago.
If you feel like changing that, this would be a good start:
https://bugzilla.gnome.org/show_bug.cgi?id=748145
> @colomar: This would be perfect, but it would need a whole lot of work from both the desktop environment and the application side.
It's actually not that hard as far as the last three points go. This
can be fully implemented in the notification's server (ie. Plasma)
and the apps changes would be minimal. I even had a branch
doing exactly that, I just never had the time to finish it. But basically
the idea is - every new notification that arrives to the server is
directly mapped to a KSNI - title to title, text to subtitle, actions
to SNI actions. The lifecycle is a bit tricky (eg. when it is not needed
anymore) but still can be done. I meant to mostly mimic what
Android is doing. The only part remaining to solve is the drawer
that has all the SNIs and their action in some sensible way.
REPOSITORY
R289 KNotifications
REVISION DETAIL
https://phabricator.kde.org/D4663
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: albertvaka, #frameworks, apol
Cc: colomar, mck182, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170222/599ec4f8/attachment.html>
More information about the Kde-frameworks-devel
mailing list