2010/4/15 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> > Hello all, > > I'm part of the EFL port team and we're implementing the PopupMenu, > however EFL is a different platform as for our port it is just a > state-full canvas, not relying on any widget set/toolkit, we do not > have the concept of a menu at all! > > Looking at all existing implementations, they all go straight to > native platform menus. But we can't as we want to avoid such > dependencies. What we'd like to have is a delegate, that WebCore calls > the ChromeClient that is overloaded in WebKit, giving our View user a > callback with all data. > > The good news is: we did it and it works quite well. > > The bad news is: we cheated and include WebKit/efl/WebCoreSupport from > PopupMenuEfl.cpp, what a shame! (although some ports *cough qt* > include in WebCore defines from WebKit) >
In Qt we have an abstract class for popup delegates in WebCore/platform/qt and we do the actual popup delegate implementation in WebKit/qt/WebCoreSupport. The delegates are implemented in WebKit layer and PopupMenuQt has no knowledge about any specific delegates. The only reason to include WebKit/qt/WebCoreSupport in PopupMenuQt is to make the call that creates the delegate object. It could be avoided adding a method to Chrome but at the time I was working on it it was decided that it was not needed. > > In order to have a clean design, we'd like to know the general opinion > on how to do it. From what I see Mac already defines a similar call in > ChromeClient.h: > > #if PLATFORM(MAC) > ... > virtual void willPopUpMenu(NSMenu *) { } > #endif > > in our case, we'd need: > > #if PLATFORM(EFL) > virtual void showPopupMenu(const IntRect& rect, FrameView* > view, int index) { } > virtual void hidePopupMenu() { } > #endif > > so our PopupMenuEfl.cpp will just proxy to these calls. > > However, although Mac does that it may not be the best solution, so to > avoid endless patches to be discussed at bugzilla I'd like to know > your opinion on the best way so our patch is right from beginning. > I think that we could add methods to Chrome and ChromeClient to create the delegates. For example: PopupMenuDelegate* Chrome::createPopupMenuDelegate(PopupMenuClient* c) { return m_client->createPopupMenuDelegate(c); } virtual PopupMenuDelegate* ChromeClient::createPopupMenuDelegate(PopupMenuClient*) { return 0; } Each port could then provide its typedef for PopupMenuDelegate and override ChromeClient::createPopupMenuDelegate. br Luiz > > Regards, > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev