Use D-Bus to lock sessions and move "session locked" dialog (from KDevelop's main()) to kdevplatform

Review Request #105917 - Created Aug. 7, 2012 and submitted

Ivan Shapovalov
git master
1: Use D-Bus instead of lock-files to lock kdevplatform sessions.

2: Moved the lockfile remove dialog which currently resides in KDevelop's main() - and which is usable only when the session name is explicitly given to the application - to kdevplatform's SessionController, adjusting the dialog for "lockfile -> dbus" changes.
This allows to get rid of nasty non-informative error messages about a session being already used and replace them with code that does the following things:
1) Attempts a DBus call to make a running instance visible;
2) If it didn't succeed, shows a dialog window asking permission to retry, show session chooser dialog or quit;
3) Repeats the entire procedure if a newly-picked session is locked too.
This code is also used when one picks a session from "Sessions" menu, so a nasty error message has also been removed also from there.

Related change to KDevelop is here: .
Existing unit-tests + manual UI testing.


  • 1
  • 12
  • 4
  • 17
Description From Last Updated
this is wrong, no? just encountered this code while refactoring it. - we only reach this code path if we ... Milian Wolff Milian Wolff
Milian Wolff
Ivan Shapovalov
Milian Wolff
Ivan Shapovalov
Ivan Shapovalov
Milian Wolff
Ivan Shapovalov
Ivan Shapovalov
Ivan Shapovalov
Milian Wolff
Commit Hook
This review has been submitted with commit 3306c54df37e4cadd5bc6fe565dc7b4ab9c6c11a by Ivan Shapovalov to branch master.
Ivan Shapovalov
Review request changed

Status: Closed (submitted)

Milian Wolff

shell/sessioncontroller.cpp (Diff revision 5)
this is wrong, no?

just encountered this code while refactoring it.

- we only reach this code path if we want to lock the session
- if we fail to "force remove" the lock file and cannot acquire the lockfile afterwards, something bad happened

I'll turn this into an assertion, i.e.: ensure that after attempRelock the lockfile was properly acquired
  1. The actual wrong is in my next commit, 61fd1270da44aebb1a4fe1a1ce4a4292b99e5545... Without it, the overall status of locking (LockSessionState::operator bool()) is determined by both lock-file status (LockSessionState::lockResult) and D-Bus status (LockSessionState::success), which is exactly what is needed.
    Please, take a look at my github's master (git://, revision 339e1c0 - I attempted to fix it once again :P
    And about the assertion: IMO it isn't a right thing. If this happens, it means that we're encountering a problem in external environment (file system, permissions, or a user who decided to take a look at the lock-file and opened it in vim, etc.) and not an internal logic failure. Thus no sense in crashing application (and doing nothing in Release, btw)...
    What do you think?