Path: utzoo!attcan!uunet!decwrl!ucbvax!bloom-beacon!XEROX.COM!jacobi.pa From: jacobi.pa@XEROX.COM Newsgroups: comp.windows.x Subject: Re: what's most important to you for R5? Message-ID: <900702-140906-1044@Xerox> Date: 2 Jul 90 21:08:37 GMT References: Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 86 Here my whish list for today. I have purposefully limited myself to small changes not modifying the flavor of X. The ordering is random; for this minute I would consider 6) the most important. Of course I would consider something like Display Postscript very nice, but my list concentrates on small and less extension related features. 1) All (more) events need a timestamp. I leave it open which time is reported. The missing timestamps in focusIn, focusOut hurt me specially. While it is particularly hard to fit more data into keymapNotify events, this is one of the events where I would consider a timestamp useful because I would like to lazy-evaluate keyboard mappings. 2) A time-out event. After an user action (like button or key) the server will send a timeout event every 50 milliseconds for two seconds or until an other event is sent which constitutes a new user action (to any window of the connection). Don't take my example 50 milliseconds and two seconds literally. I would use this feature to time-out absence of double click using server time instead of client time. 3) A convention is needed: When using different color maps and the displayed color maps get changed by the server the color of window headers, borders, and, window manager menus get unreadable. As a client creating my own color map is should be possible to keep some few entries in the clients own colormap displaying standard colors, to avoid that effect (Of course it is possible, but which are the ones?). 4) The resources naming hierarchy should be allowed do differ from widget nesting hierarchy. The resource naming should contain some screen or visual dependent part. (Going slightly wild: Give up the Class-Instance paradigm for resource names; a widget implementor should specify a list of names which could be used for matching resources. This list would frequently consist of a class, instance relating names pairs, but occasionally it would be longer, frequently shorter). 5) In PutImage request, allow non zero left-pad for ZPixmap. 6) A modified AddToSaveSet request. Meaning: If the owner itself of a window adds it to the modified-save-set it is protected in the following sense: The window is protected from destruction if the parent of the window is destroyed or the parent windows connection is closed, as long as the parent window did belonged to a different connection. (In such a case, the window is reparented (and maybe unmapped)). Maybe generate an extension event which allows to distinguish the case of a closed connection from a destroyed window. This extension would enable to graft widget tree branches on into some other widget tree, even if the trees might run with different intrinsics, or, belong to different clients or even came from different host processors. 7) Shared memory transport. (BTW. I already use and love shared memory "images") 8) (Getting wild here). An override children cursor command/option (Temporarily changing the cursor in a window and its children, even if children have their own, different cursor). In languages which have garbage collection I would like to feed back to the user when garbage collection happens. (I have thought about changing a window header, but that is not where the user looks when the window appears dead for a second). (Don't answer: when a garbage collection is going to happen you can't issue a request anymore; it wouldn't be true in Cedar). 9) GrabServer needs a timeout mechanism. Its not trivial in the sense that the timing out client should be noticed about his failure at latest on his Ungrabserver call. (Similar but different for grab of Keys, Buttons...) 10) I would like to ask for a multithreaded XLib, if I would use XLib at all. (The protocol already has no hindrance against multithreading). 11) Performance. 12) Security. 13) Dynamicly loaded extensions. (Clients must be noticed when an extension is loaded) 14) This won't be possible given the existing framework: Move window from one screen to another. 15) Test tools (testing the application, not the server). 16) Performance evaluation tools. (I don't ask for evaluation of the X server performance. This must be done of course, but I don't have any interrest). I would like to know how well or not well behaved my own application is. 17) Pen input. Christian Jacobi Xerox PARC