[webkit-dev] Towards a More Convenient IWebUIDelegate
I recently explored the IWebUIDelegate interface to customize the context menu in WebKit. In Cocoa, using the WebUIDelegate is very convenient -- I simply provide an implementation for the one or two methods I wish to customize, and leave the others alone. I was proudly showing a coworker how cool and simple it was going to be to customize the context menu in our Windows build by implementing a delegate class to control this, when to my horror I realized that IWebUIDelegate (which is the equivalent object on the Windows side) is implemented as a set of pure virtual methods, all of which must be stubbed out to successfully compile. To add insult to injury, all of these interface classes also require each concrete implementation to implement a stub QueryInterface, AddRef, and RemoveRef method. This seems likely to result in a huge amount of wasted boilerplate code, where a Windows developer must create a page of stubbed implementations just to turn off (or otherwise modify) the context menu. This same anti-pattern can be found in the other I...Delegate objects as well (which also require the same boilerplate QueryInterface, AddRef, RemoveRef, etc.) 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. 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? Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Towards a More Convenient IWebUIDelegate
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/Release/ QueryInterface. 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 clients. -steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Towards a More Convenient IWebUIDelegate
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/ Release/QueryInterface. 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 clients. 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 delegates. egards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
