4 ms·
Half the stuff in here is already possible in X11. The rest make very little sense. > - Timestamps. The way timestamps work in X11 is messy. Well, yeah. Distr
by Jasper_ 7y ago
Half the stuff in here is already possible in X11. The rest make very little sense.
> - Timestamps. The way timestamps work in X11 is messy.
Well, yeah. Distributed timekeeping is messy. Clients can already retrieve the server's timestamp and keep a rough approximation of what's going on (I wrote a server time estimator for GNOME/mutter). Not sure how you'd fix it. Wayland replaced timestamps with serials.
> - Font path configuration.
Are you familiar with XSETTINGS? It was supported for many years in the toolkits, and got basically no traction.
> - Screen saver configuration. I would have the core protocol has only two things dealing with screen savers: the screen saver event, and the suppress screen saver flag in window attributes.
If you want to propose this as a specification, you're more than welcome to do so -- some sort of EWMH hint like _NET_WM_INHIBIT_SUSPEND or similar. Write up a spec and mail it to wm-spec-list. But you'll probably be told about to use the existing screensaver inhibit spec instead:
https://specifications.freedesktop.org/idle-inhibit-spec/latest/re01.html https://specifications.freedesktop.org/idle-inhibit-spec/lat...
> - Mouse cursor shapes
A client can already arbitrarily get and set the cursor image for a given cursor name with the XFixes extension, including setting RGBA32 cursor images.
> - Allow different screens to have their own keyboard, or to share.
XInput 2 supports multi-seat just fine.
> - The -retro option should be the default.
Not sure why this requires a whole new protocol version, just compile your X server with it on by default, or configure your display manager to set it.
- zzo38computer 7y agoYou seem to be misunderstanding many of my points. (Maybe that is because I am unclear.) > A client can already arbitrarily get and set the cursor image for a given cursor name... That is not what I am suggesting at all. My suggestion is: The client only specifies a monochrome cursor, possibly from a font; the server MAY substitute a (possibly animated) RGBA32 (or other colour type) image (for a font-based cursor) IF the user has enabled that feature in the server configuration file. > Not sure why this requires a whole new protocol version... Indeed, that is independent of the protocol. I just think it is more useful, is all.