|
| 1 | + |
| 2 | +*** Necessary for complete X11R6 implementation |
| 3 | + |
| 4 | +* Bitmap support: Drawable.GetImage and Drawable.PutImage must be |
| 5 | + implemented, possibly with support of special fields and optional |
| 6 | + hooks to PIL. |
| 7 | + |
| 8 | + |
| 9 | +*** Frameworks |
| 10 | + |
| 11 | +* Multi-platform: the X library should be portable to other operating |
| 12 | + systems than Unix (it might even only work with XFree86 if the |
| 13 | + display is ":0" right now). There are two things which might be OS |
| 14 | + specific: finding out and parsing the display name for establishing |
| 15 | + a connection, and finding authoritative data. |
| 16 | + |
| 17 | +* Thread support: Currently, it would suffice to make the lowlevel |
| 18 | + Xlib.protocol.display.Display thread-safe, as no parts of the |
| 19 | + high-level interface modify shared data. This should be done in |
| 20 | + such a way that one can still use the library without the thread |
| 21 | + support, for systems where the thread module is missing. |
| 22 | + |
| 23 | +* Extensions: There should be hooks for adding requests, events, |
| 24 | + errors and high-level methods for X extensions. Preferably, |
| 25 | + Xlib.display.Display would itself find all extensions supported by |
| 26 | + the server and install corresponding code automatically. |
| 27 | + |
| 28 | + |
| 29 | +*** To be a real C Xlib replacement |
| 30 | + |
| 31 | +* High-level functions: currently, there are only methods which |
| 32 | + directly correspond to X requests. Perhaps there should be some |
| 33 | + simpler functions (e.g. Window.resize_window() in addition to |
| 34 | + Window.configure(), Drawable.rectangle() in addition to |
| 35 | + Drawable.poly_rectangle(), etc), and possibly also compound |
| 36 | + functions (e.g. create_pixmap_from_image() which would load an image |
| 37 | + file and create a pixmap of it). |
| 38 | + |
| 39 | +* Events: advanced event queue handling, e.g. filtering out events, |
| 40 | + only process events for a certain window, etc. |
| 41 | + |
| 42 | +* Extensions: as many extensions as possible should be implemented, |
| 43 | + using the yet-to-be-written framework. |
| 44 | + |
| 45 | +* Resource database: an implementation of the Xlib resource database |
| 46 | + must be implemented. |
| 47 | + |
| 48 | + |
| 49 | +*** Miscellaneous |
| 50 | + |
| 51 | +* Documentation. |
| 52 | + |
| 53 | +* Test suite: a test suite which exercises the entire library would |
| 54 | + definitely be a nice thing to have. |
| 55 | + |
| 56 | +* Porting: the library should be runnable wherever there is a Python |
| 57 | + interpreter (with the necessary IPC support, that is.) Major |
| 58 | + porting targets are Windows and OpenVMS. |
| 59 | + |
| 60 | +* Widget set: a Python-optimized widget set using the X library would |
| 61 | + be really cute. |
| 62 | + |
| 63 | +* Server-side support: while we're at it, why not extend the library |
| 64 | + to provide at least the server-side parsing of the X protocol? It |
| 65 | + could be usable for writing X proxies, or for that matter, a |
| 66 | + complete X server in Python (this might be a little too spaced-out, |
| 67 | + though...) |
0 commit comments