Review Request: Move lockfile remove request dialog (from KDevelop's main()) to kdevplatform.

[Milian Wolff]

> On Aug. 16, 2012, 7:20 p.m., Milian Wolff wrote:
> > shell/sessioncontroller.cpp, line 1038
> > <http://git.reviewboard.kde.org/r/105917/diff/1/?file=76522#file76522line1038>
> >
> >     now that this is in kdevplatform, we'll need to figure out what to do with this..
> >     
> >     org.kdevelop.kdevelop-... is not correct for anything but the kdevelop app itself. what about quanta? what about ktechlab? if we cannot figure out the name from e.g. QCoreApplication, we might need to extend our ShellExtension class with the required dbus bits and pieces :(
> 
> Ivan Shapovalov wrote:
>     Damn. :(
>     Haven't thought about interface name.
>     Everything else's trivial, but what is the name for different kdev-based applications? Does it follow any conventions (like org.$appname.$appname)?
> 
> Ivan Shapovalov wrote:
>     ...Or is that interface KDevelop-specific?
> 
> Milian Wolff wrote:
>     A hint from Kevin Kramer:
>     
>     ~~~~~
>     You could consider using a D-Bus "lock" instead of a lock file.
>     
>     Basically when opening a session you register a D-Bus name which includes the 
>     session identifier.
>     Only one process can have that name registered and the registration is undone 
>     no matter how the process exits.
>     
>     The name can also be used to send the other KDevelop instance the request to 
>     regain focus.
>     ~~~~~
>     
>     I like this, it's easy and apparently quite widely used (KDEPIM also uses that, as does KUniqueApplication). So I'm afraid we first have to do that, and then can move the lock-detection code to KDevplatform.
> 
> Ivan Shapovalov wrote:
>     That seems an elegant solution. How can we register such an unique name? I guess we'll need to avoid registering a usual (org.kdevelop.$APPNAME-$PID) name somehow...
> 
> Ivan Shapovalov wrote:
>     ..And what happens to the scenario when the app is "crashed or hanging (stopped by DrKonqi, ...)" and one currently can just force-remove the lockfile?

The names must be chosen by kdevplatform, in a unique manner for a given session-id+app pair (quanta sessions should not interfer with kdevelop sessions though).

Thus, I propose to use a scheme such as org.kdevplatform.$appname-$sessionid or similar.

Regarding crashed/hanging processes: Well, if the app has crashed, it should have deregistered its dbus interface, hence this should not be a problem.

Now, if a crash handler is called and the dbus interface stays open, or worse, if the app hangs, then we should imo offer the user a way to kill the process and try again. Of course, with a fat warning.


- Milian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105917/#review17551
-----------------------------------------------------------


On Aug. 7, 2012, 7:02 p.m., Ivan Shapovalov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105917/
> -----------------------------------------------------------
> 
> (Updated Aug. 7, 2012, 7:02 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> 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.
>     
> This allows to get rid of nasty non-informative error messages about a session being already used
> and replace them with partially refactored code from KDevelop's main() which does the following things:
> 1) Attempts a DBus call to make a running instance visible;
> 2) If it didn't succeed, a dialog window is shown asking permission to force-remove the lockfile or show session chooser dialog;
> 3) If a newly-picked session is also locked, the entire procedure is repeated.
>     
> 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: https://git.reviewboard.kde.org/r/105918/ .
> 
> 
> Diffs
> -----
> 
>   shell/core.cpp 206d48d 
>   shell/sessioncontroller.h 551894d 
>   shell/sessioncontroller.cpp c9fac67 
> 
> Diff: http://git.reviewboard.kde.org/r/105917/diff/
> 
> 
> Testing
> -------
> 
> Existing unit-tests + manual UI testing.
> 
> 
> Thanks,
> 
> Ivan Shapovalov
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120818/5437ece1/attachment.html>