I haven't heard anything, so if anybody can find the time I would greatly appreciate it.
Thanks, Daniel --- On Thu, 7/23/09, Daniel Santos <[email protected]> wrote: > From: Daniel Santos <[email protected]> > Subject: Cursor & Icon patches > To: "wine-devel" <[email protected]> > Date: Thursday, July 23, 2009, 1:59 AM > Hello everybody! > > Attached is my current cursor icon patches based upon work > by Henri Verbeet and Andrew Riedi for review and > comment. I finished the actual code about 3 weeks ago, > but it's been a lot of work for me to split it out into > smaller pieces, especially being new to git. Here is a > break-down of what these patches do and the theory. > > * Adds real 32-bit handles (instead of converting 16-bit > handles to 32 > bit). > * Cursors & icons stored in non-moveable memory block > (a.k.a., "32 bit > data") in addition to existing 16-bit moveable > block. > * A new 'struct cursor_header' (include/wine/winuser16.h) > is pre-pended > to the 32-bit cursor/icon data (16-bit data format > is untouched). > * A new 'struct cursor_map_entry' > (dlls/user32/cursoricon.c) is used to > manage a cursor's association with its handles and > data. > * Adds more complete .ani support (I think nearly 100% > complete). > * Adds themed icon support (from your X-windows theme). > * Fixes a lot of bugs. > * And finally, moves cursors to the server. > > The server opaquely stores the raw 32-bit cursor/icon > data. Since the client does all interaction with > winex11.drv, the server doesn't really need to understand > it. The client caches all objects locally, but > attempts to retrieve from the server any handle it doesn't > know about. Locally, the client uses a pair of rbtrees > to associate cursor objects (actually struct > cursor_map_entry) with their respective 16 & 32 bit > handles. The 16 bit cursor data is automatically > generated on the client and can still be directly > manipulated from 16 bit programs; in such cases, the 32-bit > cursor data will be updated from the modified 16 bit > data. The CRITICAL_SECTION IconCrst is used to > synchronize access to the rbtrees and ensure that data is > unmodified once an operation on that data begins (in > database terms, IconCrst is used to lock the entire "table" > and there's no "row-level" locking). > > > There are several new functions to query and manipulate the > rbtrees: > > add_cursor_entry : (self-explanatory) > remove_cursor_entry: (self-explanatory) > get_cursor_handle16: retrieves a 16-bit handle from a > 32-bit one > get_cursor_handle : visa-versa > > > Layered on top of that are a basic set of functions for > higher level management of cursor/icon objects: > > alloc_cursor_data : allocate & > initialize cursor data & header > create_cursor : creates > cursor and auto-generates 16-bit data > destroy_cursor : destroys cursor and > associated 16-bit data > get_cursor_entry : will look both locally and > on the server > get_cursor_object : returns the cursor's > data > update_cursor_data16: creates or updates the 16-bit data > from 32-bit data > CURSORICON_refresh_cursor16: updates the 32-bit data from > 16-bit data > > The functions add_cursor_entry and get_cursor_entry > directly return a pointer to the struct cursor_map_entry and > therefore require locking IconCrst in advance of calling (or > will fail an assertion). Having direct access to the > cursor_map_entry reduces complexity in some circumstances. > > One of the oddest fixes is the fake_cursor() function, > which is used to accommodate deleting the active cursor, > which windows doesn't mind. This isn't the only way to > go about it, but the alternative was to make the cursor > empty and I'm not certain that that is the visual behavior > of windows when deleting the active cursor, so I'm more than > open to feedback on that as well as anything else in these > patches. > > Thanks! > Daniel > > > > -----Inline Attachment Follows----- > > >
