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>
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>
QDesktopWidget is Xinerama aware and it can be disabled because I
implemented option for that, see the following commit in the Katie repo:
b7e4bae65f0cae7f3029b98980f638c077ecfc22
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the signals come from the locale KCM however applications, libraries and
widgets handling of such changes is mixed - some do it on
QEvent::LocaleChange, some on QEvent::LanguageChange, some when the
KGlobalSettings signal is send so sending the events will make sure that
locale changes take effect immediatly (when and wherethe event is watched
for ofcourse, KCalendarWidget does it for one)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
why does a method named reloadStyleSettings reload graphics effects level
settings and not application style settings?
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the XDG path is be used instead, the custom autostart path was for programs
and scripts which is not feature mentioned in the spec
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
this is done so that all application use the style set in the config
regardless if the platform plugin environment variable (QT_PLATFORM_PLUGIN)
is set in the current environment as the application may be a D-Bus service
and as such is not started by kdeinit4 for example
more changes are required to not rely on KDE_FULL_SESSION and perhaps even
more environment variables (kcheckrunning should be used instead) but that
is for another commit
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
most of the changes were done trought Katie's namefsck script which
convertes forward class declarations to include directives, however
other fixes here and there were needed as well as some questionable
changes to Q_DECLARE_TYPEINFO() macro calls because they most likely
have to do the namespacing themselfs (QT_BEGIN/END_NAMESPACE, and
probably will be in Katie) meaning that some of the changes may be
temporary and reverted later.
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
for compatibilty reasons automoc4 support is not removed but it
shall be in the future. automoc4 has not been maintained for a
while (last commit is from 2011) and the stable release is from
2009.
CMake version >= 2.8.6 provides the functionality for mocking so
I see no reason to not make use of it.
