[Kde-pim] [Differential] [Commented On] D927: Implement KDBusService alternative for Windows

[aheinecke (Andre Heinecke)]

aheinecke added a comment.


  In https://phabricator.kde.org/D927#18080, @kfunk wrote:
  
  > In https://phabricator.kde.org/D927#18079, @apol wrote:
  >
  > > > Do you see other Problems?
  > >
  > > With the exclusive Kleopatra use-case, my impression is that it would be better to copy over QtSingleApplication rather than coming up with a new implementation that possibly duplicates features and is also possibly buggy. I don't want to see such scary implementations in each and every Qt5-based application that wants to enforce a single instance.
  >
  
  
  I don't see the feature duplication here. There is no alternative to get the nice KDBusService Unique style interface available afaik.
  
  > I totally agree. Copying + extending/refactoring QtSingleApplication + putting it in a framework is the way to go here.
  
  If by refactoring you mean implementing the same interface that's used on Linux, so that you won't have to add special code to handle this in every application I agree.
  I really dislike the sendMessage / recieveMessage API which means  that every application needs to have some special handling to check if it's already running and passing arguments through a QString.
  
  > It's robust, QtCreator has been using it on all major platforms as 'unique application' solution for ages. I agree the coupling to Q*Application is not perfect, and could be relaxed.
  >  Note this change here only solves the issue on Windows; if we ever want to get Kleopatra in shape for OS X, we'll have to add another few hundred LOCs of platform specific code...
  
  I'm not sure. I can see your point that Window messages are only something for Windows. But implementing this feature with Socket + Lockfile would have been more complex for me.
  And I didn't want a dependency on QtNetwork when I can do this with WinAPI anyway. But yes a platform independent solution would be better.
  
  > Why not (finally!) fix this in a way all KDE applications can benefit from? :\
  
  Ok. Let's give it a try. I think KCoreAddons could be a place for this as I'd like to avoid the QtNetwork dependency anyway and If we don't depend on QtNetwork we already have a place in a Framwork for this, which would solve the problem of "where to put this". The Qlockfile code is already available in qt so we can use that. Then a KUniqueService class with a similar API as in this patch that is based on File communication (instead of socket / pipe).
  
  Something like:
  First App creates a "Server"-Lockfile in the pattern from QSingeApplication. A client that can't take the lock, trys to lock a client lockfile (to avoid race / parallelism problems). And write's it's command line args into a file in the lockfile pattern with a predefined suffix. The server has a QFileSystem watcher monitoring for this, handles the request and writes the return code in another file (probably including the pid of the client). The client in turn watched for that file, reads it and exits according to that return code. The client lock file is released and the server can handle the next request. I think this sounds simple and robust enough for most cases and is portable.
  
  Could you agree with something like that (and would use it)?

REPOSITORY
  rKDEPIM KDE PIM

REVISION DETAIL
  https://phabricator.kde.org/D927

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: aheinecke, mlaurent
Cc: kfunk, apol, knauss, kde-pim, winterz, smartins, vkrause, mlaurent, mbohlender, dvratil
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/