the window manager should probably not be changed if there are active
applications (i.e. until the next login in most cases) to begin with
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
everything except the actual session management, second time ksmserver
starts crashing as I work on something for no reason and is time for it
to be done anew as there were quite some unsafe bits in it
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
see 387bdaa93fd6adb0cd8a930454e3be578fa5fdc0 in the kdelibs repo, how a
link will be opened depends on a few things now - the MIME type and what
method is used for opening the URL. if KRun is used the MIME type will
be detetermined and the prefered service for it will be launched, if
KToolInvocation is used first the preferred service for "text/html" will
be attempted with fallback to kde-open and xdg-open which solidifies the
behaviour of "mimetype-determination-in-calling-application" (see
kdelibs/kdecore/sycoca/kprotocolinfo.cpp)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
fixes some race-conditions, for reference:
9ed7286504
also the exit() call in case of failure to open the temporary file would
exit the program calling runRdb() (systemsettings for example) with
status 0 (normal, when an error ocurred), that is no longer the case
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
if openbox still fails to launch check the system log, it has not been
maintained for years so I do not expect a crash to get fixed
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
by using KProcess::setShellCommand() the Exec key can contain not only
program but also arguments, ksmserver splits the Exec key already (see
kde-workspace/ksmserver/server.cpp)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
clicking on any of its widgets before the dialog is closed can mess up the
configuration because the widgets are still connected to signals and slots
side note: if the overview button is clicked (i.e. the componentchoooser
KCM is closed) while the timer dialog is active is can happen regardless
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
two things were not done properly before:
- current window manager was not replaced if the window manager that
would replace does not have --replace command (or alternative)
- waiting for the window manager to become active
now that that is done, any window manager can be started right away and
more .desktop files may be added in the future
also, something that occurred to me while writing the code for it - KWin
replaces the window manager on the current screen only and it is
possible to code the window manager chooser to start the replacing window
manager on any screen (assuming it has --screen argument or something
like that)
the window manager process was not detached thus killed once systemsettings
is closed, the revert to previous option was reverting to kwin instead of
the previous window manager
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
