because the old KNotification implementation did not look for sounds
recursively it was not possible to set a relative sound file that is
supposed to not be in one of the main sound directories (e.g a sound in a
sub-directory like /usr/share/sounds/freedesktop/stereo/message.oga, for
such files the full path had to be set in the notification config but no
more)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
another rewrite of bits dating back to 1997 done:
https://ibb.co/5GKtQT1
while working on it the idea of writing custom widget that will act as
checkbox but look something like a slider and using that instead of tables
popped up (the widget design itself is not new but using the widget in new
UIs will be).
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
cleaning up the mess, everything but KNotificationConfigWidget is
implemented.
not only does it not require additional D-Bus service (knotify) to
function but also does not transmit pixmaps over D-Bus, the features
to execute command or log to file are dropped and will not be
implemented.
also about markup support in notifications - if the server does not
support markup then it is supposed to strip it, see the spec:
https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html#backwards-compat
meaning nothing should be done by KNotification itself because it is not
a server, it is just a proxy.
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
optional feature that requires "-tray" command line argument and replaces
what the `ksystraycmd` program was doing. requires "X-KDE-SysTray" entry
in the desktop file as indicator that the application supports "-tray"
argument, unlike `ksystraycmd` does not spawn extra process and even
session management will work properly for it (the argument is manually
added to the restart command)
the feature is very much tide to KMainWindow (and derived classes) but the
overhead is next to none when the "-tray" argument is not specified (the
status notifier is not created in such case) however if created an
expensive tooltip update is done whenever a window changes (may have to
look into optimizing it but then again - most of the code does nothing
unless the "-tray" argument is specified)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
because the status notifier data engine (see
kde-workspace/plasma/dataengines/statusnotifieritem/statusnotifieritemsource.cpp)
assumes that pixmaps are not larger than KIconLoader::SizeLarge
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
because MIME strings (those from shared-mime-info package for example)
tend to change and exact MIME string match is unreliable
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
expensive as it may be it is more reliable check if the icon is actually
available than QIcon::isNull() (for system icons anyway)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
palette and style shall be applied by the platform plugin, the font is
independant of the full Katana session (look for
KGlobalSettings::generalFont() for example, font from config is used here
and there because the config and thus KGlobalSettings offer fine grained
font selection for different purposes)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
in full Katana session it is done by the input KCM and even by the
`startkde` script (so that cursor theme applies for any error messages
shown via `xmessage`). as for changing after startup it is again done by
the input KCM (via `XFixesChangeCursorByName()` calls and other stuff), the
change even applies when not in Katana session (i.e. `systemsettings`
changes the cursor theme even if not in Katana session) so it is redundant
to do it from KGlobalSettings and only the notification signal has to be
emitted
on a side note style and palette are applied by the platform plugin (see
kde-workspace/qguiplatformplugin_kde/qguiplatformplugin_kde.cpp) when in
full Katana session meaning style and palette also do not have to
applied by KGlobalSettings but that is for another commit because there
are some other things to take in account (such as style override via
command line argument and initializing plugin paths early, before
KApplication is constructed)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the input KCM (which changes mouse settings) emits that change so it makes
sense to apply mouse-related settings to the application when it is
emitted. also notfication for KGlobalSettings::SETTINGS_QT was never
emitted
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
