I wasn't happy doing a direct port of the old Menu to GTK. This sounds a lot better.
-- Elliot On Fri, Jun 5, 2009 at 12:34 AM, Ben Goodger (Google) <b...@chromium.org> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
