In KDevelop Version 5.7.211203 (21.12.3) it used to be the case that when a KDevelop session was already running and I run, e.g., "kdevelop *.h" from bash, it would open all *.h files in the currently running KDevelop session and basically add the files to the list of open files. Now, in Version 5.12.230805 (23.08.5), when I do the same, it opens a new KDevelop window, seemingly a new session and says that the Cache is unclean ("The previous session crashed. The crash may be caused by a corruption of cached data. Press Clear if you want KDevelop to clear the cache, otherwise press Continue if you are sure the crash has another origin."). Cleaning the cache, however, can cause the already open session to crash. I would like to have the old behavior back or have a command line option to indicate that I want the files to be opened in the current session.
Cannot reproduce in the almost latest KDevelop master (version 6.2.250370). When a single KDevelop session is open, the files opened from the command line are added to it. When multiple KDevelop sessions are open, the "Pick a Session" dialog allows to choose in which session to open the files. KDevelop 5 is no longer supported. I guess something is wrong with the interprocess communication to the running KDevelop instance(s) on your system. When you run kdevelop from the command line without any arguments, is the existing KDevelop window activated or a new one opened?
When I run kdevelop from the command line without any arguments, a new window opened. But: Thanks for the hint regarding the interprocess communication. It turns out the problem occurs only in a VNC session, but not out of it! So, kdevelop may be innocent. I have an env var DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus Which seems ok? Any hint on which direction to look at to debug this would be highly appreciated.
(In reply to Lars Winterfeld from comment #2) > I have an env var > DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus > Which seems ok? Any hint on which direction to look at to debug this would > be highly appreciated. Debug KDevelop or analyze the source code. I guess getRunningSessionPid() called from main() in app/main.cpp returns -1, because it fails to detect a running KDevelop session. And that is probably because SessionController::isSessionRunning() returns false for the running session's ID, which must be caused by a wrong result of SessionLock::tryLockSession().
Resolving for now. Feel free to reopen with more info if you learn that the bug is in KDevelop code.