The declaration of some some commonly used data-structures (e.g. FontFamily, WebAttribute) are not shared between WebKit1 and WebKit2 APIs. We should considered having a common header file for these common data-structures, similarly to qwebkitglobal.h, which seems to be the only shared header between WebKit1 and Webkit2.
I have seen the problem a few times, altough the headers where not exactly identical. This will become a problem as WebKit 2 mature. I think we need more than a header. I would like to see a shared folder with common headers for WebKit 1 and 2.
In general, we would like to keep WebKit1 and WebKit2 separate. Shared concepts should instead be part of WebCore or below.
(In reply to comment #2) > In general, we would like to keep WebKit1 and WebKit2 separate. Shared concepts should instead be part of WebCore or below. I looked again at our copy-paste in Qt and things are not as bad I believed. I saw 2 enums and a class that are copies. Laszlo, what do you have in mind that could be shared?
Benjamin - one example for us is QWebSettings -- having at least some common settings shared between WK1 and 2 would be nice -- an abstract base class or interface that specifies the common functionality.
(In reply to comment #4) > Benjamin - one example for us is QWebSettings -- having at least some common settings shared between WK1 and 2 would be nice -- an abstract base class or interface that specifies the common functionality. API wise, I think that would be a huge mistake. Look at the API of QWebSettings, there are: -obvious mistakes we could fix with the new APIs -APIs that cannot apply to WebKit 2
(In reply to comment #5) > API wise, I think that would be a huge mistake. > > Look at the API of QWebSettings, there are: > -obvious mistakes we could fix with the new APIs > -APIs that cannot apply to WebKit 2 Using QtWebSettings itself isn't necessary, but having a common settings structure that can be used between Webkit1 and webkit2 would be nice - I don't see WebKit1 going away anytime soon, and being able to use a common structure between the two could make life easier for those that use a web component (like QML WebView), and want to be able to plug either a webkit1 or webkit2 variant of it (obviously, there would be some shims needed to make some of the webkit1 stuff asynchronous)... Now that I think about it though, QtWebSettings won't go away, and adding another WK1 settings structure will just confuse people, so I guess you're right that it's not the correct approach. Better to do it right for WK2 than to pollute it with WK1 restrictions.
Does it still make sense to keep this bug open? I went through the comments and the original goals don't seem to be aligned with our current work anymore, Laszlo. Am I mistaken?
Marking it invalid to conclude the discussion.