[webkit-dev] Widget / Drawing API thoughts

Maciej Stachowiak mjs at apple.com
Tue Jun 21 01:36:44 PDT 2005

On Jun 20, 2005, at 8:29 PM, Kevin Ollivier wrote:

> I think this sounds good. Though one little nitpick I have is that  
> I think it's better to name the directories after toolkits rather  
> than platforms. (i.e. cocoa rather than macosx) I think it's a bit  
> clearer, as multiple ports could run on OS X. (Of course, like  
> wxWidgets. ;-)

That sounds reasonable. "cocoa" it is.

>> One complicating factor here is the fact that we are planning to  
>> redo the way form controls are done soon. We want to make the  
>> layout engine draw them directly instead of using platform-native  
>> widgets, so instead of the various Qt widget classes we'd mostly  
>> just end up with a theme API for drawing the native look.
>> Perhaps temporarily we could set up the tree to work with either  
>> model, so ports can convert to the theme API approach on their own  
>> schedule.
> I would prefer it if we could still have an option to use native  
> controls instead, not even just as a temporary measure. I realize  
> drawing the widgets has its benefits, but as a user I actually  
> prefer native widgets over the generic controls found in, for  
> example, Firefox. So I'd like to be able to continue to use them  
> for the wxWidgets port.

For OS X at least, we intend to make the controls look and feel just  
like the native ones to a pretty exacting level of detail. We will  
only fall back to a generic look if the page specifies custom styling  
info, this is desirable for web compatibility in any case. So please  
do not assume the themed controls will look lame and generic. In  
fact, I believe the Firefox controls look and feel very much like the  
native ones on Windows, and even respect Windows theming.

That being said, I can see how it might be a tough technical  
challenge for some toolkits to implement the theme API, especially  
multiplatform toolkits that rely on native widgets under the covers.  
I am not sure what to do about that, as maintaininga dual-track  
approach to form controls is likely to be painful in the long run.


More information about the webkit-dev mailing list