Even though I'm nowhere near there yet (got to get JSCore working first ;) ), here is an idea: Have KWQ use cross-platform C/C++ implementations, keeping everything as high level as possible, and use C++ inheritence to inherit from platform specific implementations. for instance, QRegion can be implemented sans Cocoa for the stuff that is already cross platform, but inherit from a KWQRegion which has different implementations for Cocoa, Win32, GTK+, Qt (hey, why not?), wxWidgets, etc... possible directory layout: KWQ\ Platform\ Cocoa\ C++ / Objective C sources for Cocoa GTK+\ C++ / C sources for GTK+ wxWidgets\ C++ sources for wxWidgets Win32\ C++ / C sources for Win32 \C++ sources which are fairly cross platform (there's plenty) And possibly do this for other places as well... to separate Cocoa calls from the rest.
Hi Justin, On Jun 10, 2005, at 3:15 PM, Justin Haygood wrote:
Even though I'm nowhere near there yet (got to get JSCore working first ;) ), here is an idea:
Have KWQ use cross-platform C/C++ implementations, keeping everything as high level as possible, and use C++ inheritence to inherit from platform specific implementations.
for instance, QRegion can be implemented sans Cocoa for the stuff that is already cross platform, but inherit from a KWQRegion which has different implementations for Cocoa, Win32, GTK+, Qt (hey, why not?), wxWidgets, etc...
I definitely agree something like this would be very helpful, but I'm curious as to why you'd want to inherit the platform-specific implementation from the base implementation, rather than vice-versa. For example, what would be great for us is that the common classes all have KWQ(something)Base classes with virtual methods, from which we derive toolkit-specific implementations. This is helpful because even for completely "toolkit neutral" classes, like KWQBrush, we sometimes need to have a way of converting that to or from, say, a wxBrush that we can use. So with this approach, we could just add our accessor functions to a toolkit-specific implementation, and reuse the rest from the common implementation. For classes with no real way of having a 'toolkit-independent' implementation, base classes could just be stubs. Doing things this way, we don't need to create a custom implementation if we don't need it - we just reuse the base class. But if we want to extend it in any way, we can just by deriving from it, and the only thing we ever need to worry about maintaining are our own extensions. :-) This will do a lot, IMHO, to keep implementations synchronized. This is actually how wxWidgets goes about maintaining all those different implementations. Thanks, Kevin
possible directory layout:
KWQ\ Platform\ Cocoa\ C++ / Objective C sources for Cocoa GTK+\ C++ / C sources for GTK+ wxWidgets\ C++ sources for wxWidgets Win32\ C++ / C sources for Win32 \C++ sources which are fairly cross platform (there's plenty)
And possibly do this for other places as well... to separate Cocoa calls from the rest. _______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
On Jun 11, 2005, at 9:05 AM, Kevin Ollivier wrote:
Hi Justin, On Jun 10, 2005, at 3:15 PM, Justin Haygood wrote:
Even though I'm nowhere near there yet (got to get JSCore working first ;) ), here is an idea:
Have KWQ use cross-platform C/C++ implementations, keeping everything as high level as possible, and use C++ inheritence to inherit from platform specific implementations.
for instance, QRegion can be implemented sans Cocoa for the stuff that is already cross platform, but inherit from a KWQRegion which has different implementations for Cocoa, Win32, GTK+, Qt (hey, why not?), wxWidgets, etc...
I definitely agree something like this would be very helpful, but I'm curious as to why you'd want to inherit the platform-specific implementation from the base implementation, rather than vice-versa.
For example, what would be great for us is that the common classes all have KWQ(something)Base classes with virtual methods, from which we derive toolkit-specific implementations. This is helpful because even for completely "toolkit neutral" classes, like KWQBrush, we sometimes need to have a way of converting that to or from, say, a wxBrush that we can use. So with this approach, we could just add our accessor functions to a toolkit-specific implementation, and reuse the rest from the common implementation. For classes with no real way of having a 'toolkit-independent' implementation, base classes could just be stubs.
Looking at the Q-replacement classes in kwq, I think they probably all fall into two categories: 1) Almost entirely platform-independent, with possibly a bit of platform-dependent logic for converting to native toolkit types. QString and QColor would be in this category. 2) Almost entirely platform-dependent, with almost no platform- independent logic. So I think there's a way to do this that doesn't rely on inheriting from special base classes. For both categories 1 and 2, we'd share the headers, with #ifdefs for the platform-dependent data members and any native conversion methods. For category 1, define the few platform-specific conversion functions in a platform-dependent file. For category 2, put the whole implementation in a different platform- dependent file. The problem with inheriting from platform-independent base classes is that you would have to use multiple inheritance to get the inheritance hierarchy right. For instance, QCheckBox would have to inherit from QButton *and* from QCheckBoxBase, which QButton would have to inherit from QButtonBase. I think this would be needlessly complex, and I guess whole separate implementations of the widgets are likely to be fine. Regards, Maciej
On 6/19/05, Maciej Stachowiak <mjs@apple.com> wrote:
The problem with inheriting from platform-independent base classes is that you would have to use multiple inheritance to get the inheritance hierarchy right. For instance, QCheckBox would have to inherit from QButton *and* from QCheckBoxBase, which QButton would have to inherit from QButtonBase. I think this would be needlessly complex, and I guess whole separate implementations of the widgets are likely to be fine.
Yes, it would be cleaner if each platform had their own platform-specific implementation in a separate source directory, if there's anything common that never needs a platform-specific file, it could be placed in a src/common dir or something similar. Note that you could have C++ member functions for a class that could be implemented in the system-specific dir, *as well as* common member function implementations that don't need any platform code. One step in the current build tree would be to separate the KWQ header files into a separate directory, and move the existing implementation files into a macosx dir, as I assume most of the code is macosx-centric, anyway. Then there could be a migration moving some of the code into a src/common or something similar. I could help out with that in case this part of the project starts, but usually it's best if one person does the big surgical operation and checks it all in. --Kent
On Jun 20, 2005, at 2:06 PM, Kent Sandvik wrote:
On 6/19/05, Maciej Stachowiak <mjs@apple.com> wrote:
The problem with inheriting from platform-independent base classes is
that you would have to use multiple inheritance to get the inheritance hierarchy right. For instance, QCheckBox would have to inherit from QButton *and* from QCheckBoxBase, which QButton would have to inherit from QButtonBase. I think this would be needlessly complex, and I guess whole separate implementations of the widgets are likely to be fine.
Yes, it would be cleaner if each platform had their own platform-specific implementation in a separate source directory, if there's anything common that never needs a platform-specific file, it could be placed in a src/common dir or something similar. Note that you could have C++ member functions for a class that could be implemented in the system-specific dir, *as well as* common member function implementations that don't need any platform code.
One step in the current build tree would be to separate the KWQ header files into a separate directory, and move the existing implementation files into a macosx dir, as I assume most of the code is macosx-centric, anyway. Then there could be a migration moving some of the code into a src/common or something similar.
I could help out with that in case this part of the project starts, but usually it's best if one person does the big surgical operation and checks it all in.
I was thinking of maybe a tree structure like this WebCore khtml bridge (stuff from kwq that's for bridging to a higher level API library, not about replacing Qt/KDE) kwq (strictly Qt/KDE replacements) headers common macosx Then gtk could be added as a peer directory to macosx (and hopefully in the future xwwindows, symbian, win32, and so forth). 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. Any thoughts from Nokia folks on how this would affect the Gtk+ or symbian ports? Regards, Maciej
On 6/20/05, Maciej Stachowiak <mjs@apple.com> wrote:
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.
Personally I would not mind if the switch from native widgets to a generic draw system happens as early as possible, it's tough to maintain dual drawing systems in the long term, and as there are no other ports just now it's easier to get this in place. Unless this of course breaks the macosx port big time. Will the layout engine changes happen very soon, or over time (if over time there's a need for the native widget system...)? - -Kent PS: For me this would be neat, as I could do all the primitive drawings in DirectFB and LiTE for the port I'm looking at for embedded Linux systems.
Hi Maciej, On Jun 20, 2005, at 3:35 PM, Maciej Stachowiak wrote: [snip]
I was thinking of maybe a tree structure like this
WebCore khtml bridge (stuff from kwq that's for bridging to a higher level API library, not about replacing Qt/KDE) kwq (strictly Qt/KDE replacements) headers common macosx
Then gtk could be added as a peer directory to macosx (and hopefully in the future xwwindows, symbian, win32, and so forth).
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. ;-)
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. Kevin
Any thoughts from Nokia folks on how this would affect the Gtk+ or symbian ports?
Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
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
Hi Maciej, On Jun 21, 2005, at 1:36 AM, Maciej Stachowiak wrote: [snip]
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.
Sorry, I never meant to imply they would look lame and generic, but as you point out with Firefox, they put more effort into maintaining Windows theming than Mac theming. Thus the Firefox buttons look like Windows buttons, which is great on Windows but not much help on Mac. (Or take IE for Mac, where they still have Classic-style controls.) In this case, things would be the opposite way around. You could now see aqua (or possibly generic) buttons on, say, Windows, where it would look just as awkward as Firefox controls do on Mac.
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.
The challenge for us is not that we can't use native widgets, it's that emulating them successfully on several platforms, and platform versions, is a significant challenge. We'd have to be able to correctly emulate native look and feel for several GUI toolkits, and each major version of those toolkits that are still supported (along with special issues like themes on some platforms). If we can't make that work, which is likely too much work to get right, we'd have to settle for a button that's generic on almost all platforms. In short, maintaining emulated native controls for all these combinations, and getting it right, looks to be a pretty significant challenge. A lot of work that just using the native controls would save us the trouble of doing. I don't know the API you're thinking of at the moment, so I can't really say how difficult this would be, but IMHO it would be ideal if we could come up with some way to at least have the option of letting a port use generic or native controls. Perhaps have a QPushButton that can optionally be set to use a theme or become "non-native" if it's given style properties, making the native/non-native distinction an implementation detail? Thanks, Kevin
Regards, Maciej
On Jun 21, 2005, at 10:36 PM, Maciej Stachowiak wrote:
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.
On Jun 27, 2005, at 8:51 PM, Kevin Ollivier wrote:
Perhaps have a QPushButton that can optionally be set to use a theme or become "non-native" if it's given style properties, making the native/non-native distinction an implementation detail?
This is what I original thought of when I started reading this post. If a CSS file starts requesting specific visual changes (aside from margins, and maybe even padding for some controls) switch over to a non-native, fully styleable control (ala the <button> tag vs <input type="button">). In my web design experience it is typically an all or nothing game, either the designer wants to tweak the control in every direction visually, or no form control selectors at all. (This isn't always the case, but likely the majority.) That mix-and-match middle ground is where it gets shaky. Mac OS X native elements can control text-color and background (color only). So does that mean you would or would-not switch to non-native if the native controls are capable of handling the style request? (This would obviously be platform dependent, with Mac OS X controls being the least styleable of most platforms.) And if one form control is styled, but the rest of the controls aren't, do you use the same control drawing API for all? (I would assume yes, to be semi-consistent. Most designers would style all controls typically.) Sorry if I strayed too far from the implementation aspect of this thread, but the design aspect should be brought up. — Timothy Hatcher » colloquy.info
On Jun 27, 2005, at 6:14 PM, Timothy Hatcher wrote:
If a CSS file starts requesting specific visual changes (aside from margins, and maybe even padding for some controls) switch over to a non-native, fully styleable control (ala the <button> tag vs <input type="button">). In my web design experience it is typically an all or nothing game, either the designer wants to tweak the control in every direction visually, or no form control selectors at all. (This isn't always the case, but likely the majority.)
Yes, this is what we have in mind. Dave Hyatt and I have been talking about this basic approach for at least the last couple of years. I also think there should be a CSS property that explicitly sets the switch. The "automatic switchover" would be the default, but you could override the heuristic with the CSS property.
That mix-and-match middle ground is where it gets shaky. Mac OS X native elements can control text-color and background (color only). So does that mean you would or would-not switch to non-native if the native controls are capable of handling the style request? (This would obviously be platform dependent, with Mac OS X controls being the least styleable of most platforms.)
Also consider that WebKit could easily have Mac OS X styled controls that are even more styleable than the native ones. It is indeed a complicated issue when to switch over to "more-generic" controls. It's not even clear that there's a true concept of "more-generic- looking". In practice maximum compatibility probably means something more like "make the controls look exactly like Windows".
And if one form control is styled, but the rest of the controls aren't, do you use the same control drawing API for all? (I would assume yes, to be semi-consistent. Most designers would style all controls typically.)
At the moment, the style of one element doesn't affect the appearance of other elements on the same page. So some page-wide heuristic is tricky, but I can see how that would be nice. -- Darin
Hi Darin and all, On Jun 28, 2005, at 10:06 AM, Darin Adler wrote:
On Jun 27, 2005, at 6:14 PM, Timothy Hatcher wrote:
If a CSS file starts requesting specific visual changes (aside from margins, and maybe even padding for some controls) switch over to a non-native, fully styleable control (ala the <button> tag vs <input type="button">). In my web design experience it is typically an all or nothing game, either the designer wants to tweak the control in every direction visually, or no form control selectors at all. (This isn't always the case, but likely the majority.)
Yes, this is what we have in mind. Dave Hyatt and I have been talking about this basic approach for at least the last couple of years. I also think there should be a CSS property that explicitly sets the switch. The "automatic switchover" would be the default, but you could override the heuristic with the CSS property.
That mix-and-match middle ground is where it gets shaky. Mac OS X native elements can control text-color and background (color only). So does that mean you would or would-not switch to non- native if the native controls are capable of handling the style request? (This would obviously be platform dependent, with Mac OS X controls being the least styleable of most platforms.)
Also consider that WebKit could easily have Mac OS X styled controls that are even more styleable than the native ones. It is indeed a complicated issue when to switch over to "more-generic" controls. It's not even clear that there's a true concept of "more- generic-looking". In practice maximum compatibility probably means something more like "make the controls look exactly like Windows".
BTW, while doing a little research on the subject, I came across a page detailing (with screenshots) what the various browsers do on different platforms when asked to style form controls: http://www.456bereastreet.com/archive/200410/ styling_even_more_form_controls/ The interesting thing is that, even for browsers like Firefox, the result is basically that they don't do much of anything, except perhaps adjust font face/size - even when they are clearly emulating the controls (see IE 5 for Mac ;-). So this pretty much confirms Darin's statement about there being no concept of a "generic looking" control. Ideally, as one of the main goals of CSS is to give control of the interface back to the web site designer, I think when designers apply any style(s) to a control the entire control should appear the same on all platforms. I don't think it should 'mix and match' with native styles. If they're not designing on Mac, for example, they probably haven't considered how some of their styling might look when mixed with native Mac control elements, and it could lead to some odd- looking results. (Believe me, we've experienced this with wxWidgets. ;-) So I think the browser should show the designer what they designed, everywhere. Of course, this brings up the issue Darin mentioned that there currently isn't a concept of a "generic looking" control, and even Windows buttons are starting to have different styles, so I'm not sure emulating them would give the correct results. Perhaps by taking on this task it's up to Safari to define such a thing as a "CSS- styled button". ;-) Thoughts? Anyone know if other browsers are heading in this direction as well? Of course, the article above also suggests that the correct default behavior should be to be as native as possible, so I still would prefer at least a native control override option. I think how it is implemented internally should ideally be port-specific, so that ports could use a 'styled' control for the native option if they want, but I do believe there should be some concept still of native controls, as for us it's just much less maintenance to use the control rather than to emulate it. ;-) (in our case, the wxWidgets devs will make sure they're always looking and functioning as they should on all platforms. that means a much better possibility that our port stays sharp looking across platforms even when Longhorn comes out.) Thanks, Kevin
And if one form control is styled, but the rest of the controls aren't, do you use the same control drawing API for all? (I would assume yes, to be semi-consistent. Most designers would style all controls typically.)
At the moment, the style of one element doesn't affect the appearance of other elements on the same page. So some page-wide heuristic is tricky, but I can see how that would be nice.
-- Darin
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
participants (6)
-
Darin Adler
-
Justin Haygood
-
Kent Sandvik
-
Kevin Ollivier
-
Maciej Stachowiak
-
Timothy Hatcher