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
