[webkit-dev] Towards a More Convenient IWebUIDelegate
mjs at apple.com
Wed Dec 2 23:01:56 PST 2009
On Dec 2, 2009, at 10:47 PM, Steve Falkenburg wrote:
> On Dec 2, 2009, at 9:53 PM, Brent Fulgham wrote:
>> To add insult to injury, all of these interface classes also
>> require each concrete implementation to implement a stub
>> QueryInterface, AddRef, and RemoveRef method.
> Yes, this is one of the downsides of COM. Some COM developers use
> ATL (or similar) to avoid boilerplate implementations of AddRef/
>> For my own purposes, I created a concrete class "WebUIDelegate"
>> that stubs all methods as E_NOTIMPL and provides the boilerplate
>> QueryInterface, AddRef, etc.. I subclass from *this* class as my
>> delegate, which allows me to simply write one method that does the
>> menu customization.
> Sounds similar to what we do.
>> Couldn't the Windows version of WebKit either stub the
>> IWebUIDelegate with the requisite E_NOTIMPL stubs, or perhaps ship
>> with a set of pre-generated stub classes like the one I just
>> created, to avoid this kind of drudgery?
> COM interfaces are pure virtual, so there is no implementation of
> IWebUIDelegate in WebKit.
> We could provide a concrete CLSID_WebUIDelegate that was
> instantiatable via (our version of) CoCreateInstance but you
> wouldn't be able to subclass it. We don't export any of the WebKit
> COM API directly through DLL exports.
> All of these conventions were critically important when the COM API
> was remotable via DCOM in order for Drosera (Web Inspector in its
> previous iteration) to work out-of-process. Some of this isn't as
> important now, but we'd like to maintain compatibility for existing
I think we could provide a DefaultWebUIDelegate which has a default
implementation of all the IWebUIDelegate methods and which clients can
subclass. That would not be available via DCOM, but it's not a
critical loss of functionality since you can still write your own
IWebUIDelegate from scratch in that case. Likewise for the other
More information about the webkit-dev