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

Sat Aug 18 11:06:41 UTC 2012

> 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?
> 
> Milian Wolff wrote:
>     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.
> 
> Ivan Shapovalov wrote:
>     Well, a name scheme is a secondary question. _Who_ will register these names?
>     Currently registration is done by KApplication itself, but it's naming scheme is AFAIK fixed to $domain.$app-$pid.
>     
>     Moreover, killing a stopped (by a handler such as DrKonqi) process is not possible (unless you use signal 9, but that's discouraged as resources are not freed)...
> 
> Andreas Pakulat wrote:
>     I think thats what Milian was getting at, register the name from kdevelop or via a shared kdeveplatform function.
>     
>     I disagree on the naming scheme though, I'd rather say it ought to be org.kde.kdevplatform.$appname-$sessionid so its still clear this is a KDE app and there's not really any domain called kdevplatform.org...
>     
>     In addition, neither a hanging process nor one crashed and sitting in dr.konqi needs to be of concern IMHO, except for notifying the user when trying to start that same session again. If the name is still registered simply tell the user that there's still a process with that session and he should check for hanging kdevelop instances or a dr.konqi window. In reality though he'll probably have killed the process or closed dr.konqi already anyway.
> 
> Milian Wolff wrote:
>     KDevplatform registeres it when you lock the session, thats the whole point here, no? Get rid of the KLockFile, only use DBUS.
>     
>     I hope something like this is possible:
>     
>     - register dbus interface $ID
>     - if worked, all is fine, we hold the lock - return
>     - if fail (i.e. name collision), send query to running instance that it should raise itself to focus
>     - if query times out, app is stuck or crashed -> offer to kill
>     
>     And what do you mean by kill -9 not freeing resources? Of course you'll leak temp files and such, but exiting drkonqi would do the same. And if the app is hung (deadlock) you cannot properly shutdown it either. So I still think that it would be the correct "last resort" option.
>
> 
> Milian Wolff wrote:
>     @ Andreas: Yeah, your naming scheme sounds better than mine.
> 
> Milian Wolff wrote:
>     just tested, an app gets deregistered from dbus before drkonqi shows up, so thats not an issue either.

That's great, will implement it now.
Last question: will we be having 2 dbus service names for each kdev-based application? One by KApplication and second by us...
Or I'm understanding something wrong?

- Ivan

-----------------------------------------------------------
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/ea24cf76/attachment.html>