Hi Jonathan,
Are you referring to Carbon or Cocoa embedding? Since you mentioned Quickdraw, I would assume you mean Carbon. In that case, the answer is: yes and no. ;-) Basically, on Mac, all Mozilla drawing is handled internally, but it draws straight into the top level window's drawing region, which means that your app must be careful before doing any drawing. Currently, any drawing you do in the Window where Mozilla will be embedded will need to call SetOrigin and (re)set the port, etc., before any drawing operations. Depending on your internal APIs, you may have to place SetOrigin calls at various places in your API to ensure that it is always using the correct value. (This is what I needed to do for wxMozilla.)
The other thing you have to worry about is events. An embedded Mozilla control does not use Carbon events, so the embedding control or window must "feed" all the events it receives (drawing events, mouse events, etc.) to Mozilla. They need to be EventRecords as well, and if you are using Carbon Events, you'll need to manually convert some events to the old EventRecord format. There's also issues with compositing and non-compositing windows, as their coordinate systems differ and Mozilla expects everything in Window coordinates.
I should mention that I've spent the last few weeks trying to resolve these problems by making all the Mozilla controls native Mac controls internally. I now have Mozilla creating native controls, and have the Mozilla control (and its children) internally receiving and responding to kEventControlDraw events and mouse events. Instead of passing in the WindowRef of the window you are embedding in, these changes will allow you to pass in a ControlRef to embed the control into so that you can maintain a proper embedding hierarchy. I've also added code to support compositing mode, using the HIView APIs. I still need to work out focus and activation events, as well as text input and proper ZOrder for the scrollbars, and I also want to update nsRenderingContextMac to use mOffx and mOffy when calculating drawing coordinates so that the SetOrigin calls can be removed as well. (Or, I should say, SetOrigin can always be set to 0, 0 when Mozilla draws.) But I am getting there.
Unfortunately, I've found most of this work was necessary to embed Mozilla into wxWidgets on Mac, just because much of the current Mozilla code is actually pre-Carbon and I've run into a number of little gotchas which have been quite tough to fix up. Of course, the fact that wxWidgets uses compositing/HIView makes things more difficult as well, so it may not be so problematic when working with a non-compositing window.
I'm not sure when I'll be able to finish these changes, but hopefully in the next month or so if I continue to make good progress.
HTH,
Kevin
On Aug 9, 2004, at 10:24 AM, Jonathan Le wrote:
Dumb question about embedding for mac:
When embedding for mac os x, at any point, does the implementor have to worry about drawing windows, controls, or anything like that using Quartz 2d or Quickdraw?
In other words, is content rendering handled completely by the API? _______________________________________________ mozilla-embedding mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-embedding
_______________________________________________ mozilla-embedding mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-embedding
