2 ms·

FWIW, there is some effort to let QT applications survive compositor crash in a way that would be even more resilient than with X11: https://www.phoronix.com/ne

FWIW, there is some effort to let QT applications survive compositor crash in a way that would be even more resilient than with X11: https://www.phoronix.com/news/Qt-Wayland-Compositor-Restart https://www.phoronix.com/news/Qt-Wayland-Compositor-Restart Of course, that's a new feature they're working on, only helps QT apps, and requires the toolkit to track state (and by the same virtue, looks like it would have worked fine with X11 if they wanted to). So this is more of an interesting related tidbit rather than a disagreement.

vidarh 3y ago
That's an interesting approach. It'd be easy enough to do for my own X apps as I'd mostly need to flush some caches and recreate windows and pixmaps. It'd generally be terminals that are most painful to use, and the terminal would be nearly trivial since they keep an buffer of the text anyway and so can trivially recreate the view once they succeed in reopening the window (the font rendering caches glyphs, and caches graphics contexts; just flushing those caches client side would make the terminal recreate them as needed) Whether X or Wayland it would certainly make experimenting less painful. Browsers doesn't matter that much given they're reasonably decent at restoring. (Another option there is xpra - "screen for X") Fewer and fewer reasons not to start writing an X server ;)
- yjftsjthsd-h 3y ago
  > It'd generally be terminals that are most painful to use, and the terminal would be nearly trivial since they keep an buffer of the text anyway and so can trivially recreate the view once they succeed in reopening the window The cheap version of this is just using tmux/screen, but yeah honestly I suspect a lot of programs are easy to make recreate their GUI state if you care to bother, it's just that not everyone does (or should; it's a trade off and display servers aren't usually that crashy).
  - vidarh 3y ago
    I wouldn't care either if I wasn't contemplating at some point getting my hands dirty with that layer too ;)

vidarh 3y ago

That's an interesting approach. It'd be easy enough to do for my own X apps as I'd mostly need to flush some caches and recreate windows and pixmaps. It'd generally be terminals that are most painful to use, and the terminal would be nearly trivial since they keep an buffer of the text anyway and so can trivially recreate the view once they succeed in reopening the window (the font rendering caches glyphs, and caches graphics contexts; just flushing those caches client side would make the terminal recreate them as needed) Whether X or Wayland it would certainly make experimenting less painful. Browsers doesn't matter that much given they're reasonably decent at restoring. (Another option there is xpra - "screen for X") Fewer and fewer reasons not to start writing an X server ;)

yjftsjthsd-h 3y ago
> It'd generally be terminals that are most painful to use, and the terminal would be nearly trivial since they keep an buffer of the text anyway and so can trivially recreate the view once they succeed in reopening the window The cheap version of this is just using tmux/screen, but yeah honestly I suspect a lot of programs are easy to make recreate their GUI state if you care to bother, it's just that not everyone does (or should; it's a trade off and display servers aren't usually that crashy).
- vidarh 3y ago
  I wouldn't care either if I wasn't contemplating at some point getting my hands dirty with that layer too ;)