Move AvatarMenuModel::Item into ui/base.

Move AvatarMenuModel::Item into ui/base.

Moving this to enable the app list to reuse code from Chrome's profile
switching menu.

App List profile selector implementation is in
https://codereview.chromium.org/20656002/ .

BUG=
TEST=None

[xiyuan, 2013-08-09 17:15:47]

Don't think AvatarMenuItemModel should live in ui/base as that dir is a place to
put generic UI components. AvatarMenuItemModel does not fit into that category.
And it's strange that AvatarMenuItemModel is not sit together with its container
AvatarMenuModel.

I still think that AppListMenu and AppListMenuViews should be moved out of
ui/app_list and into chrome/browser/ui/app_list because that is chrome specific.
It should be exposed as ui::MenuModel* via AppListViewDelegate.

If we don't want to do the move now and still want to share AvatarMenuItemModel
code, I would suggest to expose the profile menu items via AppListViewDelegate
rather then put it into AppListModel, e.g. have a
AppListViewDelegate::PopulateAvatarMenuItems and pass it the AppListMenu's
menu_model_ for updating. This should keep avatar menu stuff inside chrome.

[tfarina, 2013-08-09 17:21:15]

On Fri, Aug 9, 2013 at 2:15 PM,  <xiyuan@chromium.org> wrote:
> Don't think AvatarMenuItemModel should live in ui/base as that dir is a
> place to
> put generic UI components. AvatarMenuItemModel does not fit into that
> category.
> And it's strange that AvatarMenuItemModel is not sit together with its
> container
> AvatarMenuModel.
>
+1! Avatar is a chrome concept/feature.

> I still think that AppListMenu and AppListMenuViews should be moved out of
> ui/app_list and into chrome/browser/ui/app_list because that is chrome
> specific.
> It should be exposed as ui::MenuModel* via AppListViewDelegate.
>
There is even a TODO in both app_list_menu.h and app_list_menu_views.h
to move them into chrome. Should we also file a bug for this task?

> https://codereview.chromium.org/22597004/



-- 
Thiago

[xiyuan, 2013-08-09 17:46:35]

On 2013/08/09 17:21:15, tfarina wrote:
> There is even a TODO in both app_list_menu.h and app_list_menu_views.h
> to move them into chrome. Should we also file a bug for this task?

Sounds good.

[calamity, 2013-08-13 07:46:07]

On 2013/08/09 17:15:47, xiyuan wrote:
> Don't think AvatarMenuItemModel should live in ui/base as that dir is a place
to
> put generic UI components. AvatarMenuItemModel does not fit into that
category.
> And it's strange that AvatarMenuItemModel is not sit together with its
container
> AvatarMenuModel.
> 
> I still think that AppListMenu and AppListMenuViews should be moved out of
> ui/app_list and into chrome/browser/ui/app_list because that is chrome
specific.
> It should be exposed as ui::MenuModel* via AppListViewDelegate.
> 
> If we don't want to do the move now and still want to share
AvatarMenuItemModel
> code, I would suggest to expose the profile menu items via AppListViewDelegate
> rather then put it into AppListModel, e.g. have a
> AppListViewDelegate::PopulateAvatarMenuItems and pass it the AppListMenu's
> menu_model_ for updating. This should keep avatar menu stuff inside chrome.

I'm not sure how this would work. I don't think exposing ui::MenuModel* is
enough 
because AppListMenuViews has special presentation for some menu commands which
is
tightly coupled to the way the model is constructed.

More specifically, ui::MenuModel* isn't able to express the structure of the
"current
user" menu item so the AppListMenuViews and mac equivalent wait until they see
the CURRENT_USER item id and take that as a cue to build a special item.

Do you have any suggestions?

[koz (OOO until 15th September), 2013-08-16 04:52:15]

On 2013/08/13 07:46:07, calamity wrote:
> On 2013/08/09 17:15:47, xiyuan wrote:
> > Don't think AvatarMenuItemModel should live in ui/base as that dir is a
place
> to
> > put generic UI components. AvatarMenuItemModel does not fit into that
> category.
> > And it's strange that AvatarMenuItemModel is not sit together with its
> container
> > AvatarMenuModel.
> > 
> > I still think that AppListMenu and AppListMenuViews should be moved out of
> > ui/app_list and into chrome/browser/ui/app_list because that is chrome
> specific.
> > It should be exposed as ui::MenuModel* via AppListViewDelegate.
> > 
> > If we don't want to do the move now and still want to share
> AvatarMenuItemModel
> > code, I would suggest to expose the profile menu items via
AppListViewDelegate
> > rather then put it into AppListModel, e.g. have a
> > AppListViewDelegate::PopulateAvatarMenuItems and pass it the AppListMenu's
> > menu_model_ for updating. This should keep avatar menu stuff inside chrome.
> 
> I'm not sure how this would work. I don't think exposing ui::MenuModel* is
> enough 
> because AppListMenuViews has special presentation for some menu commands which
> is
> tightly coupled to the way the model is constructed.
> 
> More specifically, ui::MenuModel* isn't able to express the structure of the
> "current
> user" menu item so the AppListMenuViews and mac equivalent wait until they see
> the CURRENT_USER item id and take that as a cue to build a special item.
> 
> Do you have any suggestions?

I think Ben's suggestion of introducing a new item type rather than re-using
this one is a good idea.