As part of the TOOLKIT_VIEWS work some of the long time deficiencies of the existing views::Menu API have come to a head. I think it may finally be time to revisit this.
The system of menu delegates, controllers, and such like are very confusing. We have an API that on one hand provides a model-like interface to a menu item provider, and on the other has methods for adding menu items directly. It's not very coherent. The original reason for this conflation was that some menus in Chrome are generated by data (e.g. bookmarks menus), and some are known beforehand. It's not impossible however to implement most of the fixed menus in terms of a model interface... I looked into doing this late last year, but it turned out there was one other reason for the simple "AddItem" interface - the Windows system menu. It's not easily possible without lots of gymnastics to populate this menu with a model interface, so the views::Menu code which is designed to optionally wrap a system HMENU retained this awkward interface. After some thought I think it would now be best to split off the Windows system menu handling into something separate in the interests of having an API that doesn't confuse everyone. To start with, I've begun to develop a new API for non-system menus. I've sketched out a straw man API for a menu model and uploaded it here: http://codereview.chromium.org/119237/patch/1001/1002 To make things simpler for fixed menus, an implementation of Menu2Model would be provided called SimpleMenuModel which would offer an interface similar to today's Menu API with functions like AddItemWithLabel, AddSeparator, etc. Once this system works, the views::MenuButton would be re-done to use this and automatically run the associated menu rather than delegating this responsibility to the weird ViewMenuDelegate interface. My plan is to start working on the NativeMenu subclass of Menu2, then work on transitioning the Page and Wrench menus over to it. This would be done leaving the existing Menu class in place so conversion can be done incrementally. Once all users are transitioned, Menu2 would be renamed Menu. ChromeMenu would then be based on this system also, and ultimately renamed ViewsMenu. Let me know if you think I'm missing anything. -Ben --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
