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. Regards, Maciej