Kevin Ollivier wrote on 24/6/04, 10:51 am:
> Hi all,
>
> I've been a bit of a lurker on this list, but I'm one of the
> developers for wxWidgets/wxMac, and one of the things I've been
> working on is a wrapper for WebKit (wxWebKitCtrl). I'm currently
> working on the Carbon port, and have noticed some problems with
> WebView being embedded in a Tabs Control. I wanted to know if
> anyone else is seeing these issues, or if maybe I am doing
> something wrong.
We were using WebKit in wxWindows for a while, and ran into a number
of issues, including those you describe. However, we weren't using
HIViews then, so the situation may have improved somewhat. (We're now
Cocoa, so life is good.)
In general, using WebKit in Carbon apps is fraught with some problems
which are hard to work around. Apple did Special Magic under the
hood to make WebKit work for Carbon, and that magic doesn't work
all of the time.
> 1) The most serious problem is that the Cocoa WebView does not
> have the same origin as the HIWebView, but *only* when embedded in
> the Tabs control. To reproduce this, add HIWebView as a subview of
> a tabs control, and then position the tabs control at a position
> other than 0, 0 relative to its parent. The Cocoa WebView will, it
> seems, position itself relative to the Tabs control's parent (or
> possibly relative to the top level window), rather than relative
> to the Tabs control, while the HIWebView will correctly position
> itself relative to the Tabs Control. Thus, events like mouseovers
> will happen in the correct location, while the actual display of
> the control will be at the top left corner of the Tabs control's
> parent.
>
> I have been able to workaround this by checking for a Tabs
> control, and if found, calculating the position relative to the
> parent all the way up until the tabs control. This does place the
> WebView in the correct position (usually, there are some corner
> cases I haven't found yet). Any ideas if there is any easy way to
> make this work?
Can't help you on that one. Pre-HIView, everything was positioned
relative to (0,0).
> 2) Visibility issues. I have found that the WebView tends to make
> it self visible periodically in a Tabs control even when it is not
> the active tab.
Yep, we saw this, and never got around to fixing it.
> Reading some messages on this list, I got the
> impression this is because in Cocoa, the proper behavior is to
> only ever have one subview for the Tabs control, and that's the
> active view. Tab switching is basically done by adding and
> removing subviews from the Tabs control. Is this an appropriate
> solution for Carbon as well?
That's the first thing I'd try, yes. As long as WebKit respects
the visibility of its parent HIView, you should be good (but I
wouldn't guarantee that it does).
> I see that wxMac does not do things
> this way currently, but I'm somewhat new to Mac development so I
> wasn't quite sure if changing the behavior will have adverse
> effects on Carbon/OS X.
>
> Overall, the process of embedding WebView has been a smooth one,
> but if I could get some guidance on these "gotchas" I would really
> appreciate it!
You may see some other issues too. We never got drag-scrolling working
(when you click and drag inside a WebView to start scrolling, then
drag outside of the WebView -- it should keep scrolling, but doesn't).
I seem to also recall some window layering issues; WebKit might try
to changing your window layering on you. Of course, some of these bugs
may have been fixed in WebKit updates.
Simon
_______________________________________________
webkitsdk-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webkitsdk-dev
Do not post admin requests to the list. They will be ignored.
