On Fri, Feb 13, 2009 at 1:34 AM, Dean McNamee <[email protected]> wrote: > I believe the situation is similar on the Mac. I'm not sure the > current design of passing HWNDs between processes conceptually extends > beyond win32.
The situation on the Mac is similar. There's an internal window server ID for each window; this is unique per user session (roughly, per "active desktop", of which each tree of processes can talk to only one). This can be sent around between processes, but it's not what any of the UI APIs take. There's enough state in the per-process window structures that it's difficult to just pass window IDs around as a reference to a window (for example, the public API only support using this to read window properties, not actually for manipulating windows or their contents). While we may decide it's worth using SPIs for performance reasons in the long run, it would be nice to start with an above-board implementation. In addition, things like iframes and NPAPI plugins don't actually get their own windows in the HWND sense on the Mac, even in the single-process case (such as Safari), so the win32 design is already a bit of a mismatch. An ID that can be treated as an HWND under Windows, and an index into a table or map on the Mac and/or Linux would probably work fine. It's just that a lot of the windows code currently doesn't distinguish between the various uses of HWNDs, and other platforms may need to. --Amanda --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
