| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112 |
- plans for XplatUIX11.cs:
- - 1 thread watching X socket, doing nothing but
- XNextEvent/hwnd.Queue.Enqueue (with minimal motion
- compression/key repeat detection)
- - figure out how to deal with the selection events, since they
- busy loop waiting on a response from the X socket. maybe
- block that thread with an event and wake it up when the
- event thread get enough info?
- - Idle event raised once regardless of how many thread queues
- we have (should it come from the X event thread?)
- - X11Hwnd which caches (amongst other things) the properties
- for the toplevel window so we can avoid doing all those
- XChangeProperty things on every single UpdateStyle call.
- - have RULES for things (like "do not call this function
- except from ...", etc) and make sure they're enforced.
- - SendMessage.. can't we just insert the right message on the
- hwnd's queue instead of using SendAsyncMethod?
- - what's the difference between PostMessage and SendMessage?
- - clean up the MESS that is:
- GetWindowState
- SetWindowState
-
- and especially:
- SetHwndStyles
- SetWMStyles
- DeriveStyles
- the Style handling in CreateWindow
- - multiple screens? do we care? xinerama foo?
- - fix the mostly static, somewhat instance nature of
- XplatUIX11.cs. Either make it static, or make it an
- instance.
- - we need to rethink the expose event handling. right now
- expose events are only handled once all the other events in
- the queue are handled. So, if you're resizing quickly you
- get no redraws until you're done. maybe look at the
- _NET_WM_SYNC_REQUEST protocol (for the resize/redraw case
- specifically). Also, the current expose handling has us
- accessing the invalid list/rectangle from multiple threads.
- - factor out ALL knowledge of the multiple windows
- (client/whole) into the X11Hwnd class, so we can try to
- factor it out.
- - clean up the systray icon stuff - right now it destroys (!)
- the client_window and sets client_window == whole_window.
- ugh.
- - hwnds should keep track of the width/height they report to
- SWF as well as the x window's width/height. That is, we
- should allow hwnds with 0,0 width/height even though X
- doesn't allow it. There's some "zero_size" stuff in Hwnd,
- but it still appears impossible to have 0,0 sized controls.
- - window (subwindow, really) destruction should move to Hwnd
- if possible.
- - remove 90% of "lock (XlibLock)" usage. It's not really
- needed at all, except perhaps to synchronize the
- XEventThread and the PeekMessage/GetMessage methods.
- - the big synchronization problem now is the XEventQueue
- class. I think all queue operations need to be done while
- holding a lock, as the events are queued from the
- XEventThread and dequeued from GetMessage.
- possible classes:
- - XplatUIX11 (creates the first (only?) X11Display class.
- Most calls should just get the hwnd/display and make a
- method call)
- - X11Display (manages the display handle, creates the event
- thread, keeps ref to an X11Atoms and the X11RootHwnd)
- - XEventThread (does this need to be a separate class? can
- probably just be a method in X11Display)
- - X11Hwnd (move all the style translation here? handles
- property changes and caches them. window title here too)
- - X11RootHwnd (add the special root window property stuff
- here)
- - X11Atoms (per display atom list. should these be properties
- or fields? fields probably, with the builtins as constants).
- - Xlib (the pinvoke wrapper for Xlib calls)
- window managers we need to test again:
- - metacity on SLED/SUSE
- - metacity on ubuntu edgy
- - compiz on SLED
- - compiz HEAD
- - beryl? or should compiz be enough?
- specs:
- Extended Window Manager Hints: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html
- XEmbed spec: http://standards.freedesktop.org/xembed-spec/latest/
- Systray spec: http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html
|