Bug 157354

Summary: reconnect to x-server - feature
Product: [Unmaintained] kdelibs Reporter: Elmar Stellnberger (AT/K) <estellnb>
Component: qtAssignee: kdelibs bugs <kdelibs-bugs>
Status: RESOLVED INTENTIONAL    
Severity: wishlist    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Elmar Stellnberger (AT/K) 2008-02-07 19:05:56 UTC 
Version:           unknown (using 3.93.00 (KDE 4.0 Beta2), compiled sources)
Compiler:          gcc
OS:                Linux (i686) release 2.6.22.16-0.2-default

It is a major advantage of X-Server based GUI applications that it is possible to run and display singleton applications on different machines efficiently, be it for the purpose of thin clienting in the LAN or even for two computers connected via an ssh tunnel by the internet.
  However this can turn out to be a drawback if the complete session is lost because of a temporary network interruption like this can be caused by WLANs or old lan-cables that slip out of the connector plug every now and then. The same problem occurs if one or both machines go into standby at a different time. KDE3 could even panic and destroy the current session because of certain display events(screen unplugging/resizing etc.) or recently apparently without any motivation during normal operation.
  A fast but insufficient approach to solve this would be for kde4-qt not to give up the network connection before the X-server would consider it to be lost. However any outage can always last longer than expected (f.e. power outage - battery supply for server running x-clients only). Moreover if a remote machine decides to go into standby (or the other way round) the local user possibly does not want to follow into standby. This means that a qt-kde4 based X-client should never quit just because the X-server becomes unavailable.
  Instead of this the client should wait until induced to reconnect to the same or even possibly a different X-Server or Display than before. To enable this a tool to approach all kde4-clients running on a particular machine would be desirable, especially for those clients which have lost their connection. Allowing to "send" a kde4-application to a different display(:0.0,:0.1) or machine by initiating an ex-ante reconnect as an alternative extension would open up a totally new perspective.
  Moving applications between displays and machines would pose a great feature and enable a host of new possibilities - new possibilities of collaboration, greatly enhanced flexibility, monitor pooling - just to mention a few. Something that is really worth to consider, even if the effort to achive this will be considerable or even intricated!
Comment 1 Elmar Stellnberger (AT/K) 2008-02-07 19:08:31 UTC 
  Such a feature would pose a major argument for application developers to use KDE4 as well.
Comment 2 Matthew Woehlke 2008-02-07 22:50:03 UTC 
Forget network timeouts, not losing *every app I am running* because X just fscked up (again) would be a major improvement.

X server crashes are seriously unfair... they're very, very nearly equivalent to a kernel panic, and far more likely. (If my X server were to crash/hang/whatever right now, it would be equivalent to a hard reset in terms of lost work, in all ways except that X would restart rather faster than a total reboot.)
Comment 3 Elmar Stellnberger (AT/K) 2008-02-08 11:12:40 UTC 
  Basically I have thought about it as a whole new feature, enabling to send a running application between different either remote or collocated computers either for the purpose of cooperation, for administrative tasks or simply to change the workplace (apart from the many little other advantages). If it is possible to migrate running applications between different physical machines, why should it not be possible just to change the display, they are attached to?
  The stability issue will just be a pleasurable side effect. Even the best Xorg-server can panic if the video card driver goes wrong (which is currently not unusual for the most popular drivers). Besides this people who use a port of Xorg to other operating systems will also be glad about such a client side solution, because these ports are imperfect and some of them still use to crash regularly (if they are not broken at all).
  I do personally think about the sensitivity of X-clients as a major design flaw of X-Windows, which can not simply be overcome by better and more stable implementations of X-servers (client-server role uses to be the other way round because of that for comparable commercial systems). Nevertheless this apparent flaw could be turned into a considerable advantage greatly enhancing flexibility if X-client-frameworks like qt/kde supported such a reconnection mechanism.
Comment 4 Elmar Stellnberger (AT/K) 2008-02-11 20:45:53 UTC 
  ... and once again a full KDE-session of mine has panniced. To me that is an issue, in deed. Perhaps I should disable the "Composite" extension or downgrade my video driver. For Users who wanna make use of enhanced 3D or opacity features this will become an increasingly important issue, because it may take years until all problematic settings get tested out, so that
I hope the report does not come too late.
Comment 5 Dirk Mueller 2008-08-18 02:00:43 UTC 
this is outside of the scope of what Qt can do. there are some X server extensions being worked on to be able to do that.