Probably not worth the trouble. I was really just observing that it was
slightly unfortunate that we had to maintain them in the first place; but
it's really not that big a deal.

On Mon, Sep 8, 2008 at 10:30 AM, John LaBanca <[EMAIL PROTECTED]> wrote:

> We could0 construct the items array as needed, reconstructing when
> necessary.  So, we only modify the allItems array (that includes
> MenuItemSeparators) for most operations, but anytime we add/remove a
> MenuItem, we set the items array (that does not include MenuItemSeparators)
> to null.  When users call getItems, we contruct the items array iff it
> equals null.  That way, if users call getItems() again, we don't need to
> reconstruct it unless a MenuItem has been added or removed from the MenuBar.
>
>
> On Fri, Sep 5, 2008 at 4:22 PM, Joel Webber <[EMAIL PROTECTED]> wrote:
>
>> Change Looks good to me. I love changes that nail a bunch of problems at
>> once :)
>> I just realized that it kind of sucks that we're stuck maintaining two
>> separate lists of items, because of getItems(), but I don't think there's
>> much we can do about it at this point.
>>
>>
>> On Fri, Sep 5, 2008 at 3:35 PM, John LaBanca <[EMAIL PROTECTED]> wrote:
>>
>>> Joel -
>>> Please do a code review on this enhancement.
>>>
>>> Description:
>>> =========
>>> Currently, then MenuBar only supports appending an MenuItem to the end of
>>> the MenuBar.  It would be nice to be able to insert MenuItems at any
>>> location.  Same goes for MenuItemSeparators.
>>>
>>>
>>> Fix:
>>> ===
>>> I added the following methods to MenuBar:
>>> getItemIndex(MenuItem)
>>> getSeparatorIndex(MenuItemSeparator)
>>> insertItem(MenuItem, int)
>>> insertSeparator(int)
>>> insertSeparator(MenuItemSeparator, int)
>>>
>>> I added the getItemIndex() and getSeparator() methods so users can get
>>> the index of an existing MenuItems and MenuItemSeparators.  I also added
>>> three insert methods to insert MenuItems and MenuItemSeparators at a
>>> specific index.
>>>
>>> Currently, their are four addition addItem() convenience methods that
>>> take various parameters to create and add a new MenuItem.  I didn't add
>>> these convenience methods because they aren't really needed, and because
>>> they pollute the API too much in my opinion.
>>>
>>> Also, I slipped in a little fix for a MenuBar issue.  If you have a
>>> mixture of MenuItems that contain submenus and some that don't, then when
>>> you highlight a MenuItem that does not contain a submenu, the currently
>>> visible submenu remains open under its parent.  Now, if autoOpen is enabled,
>>> that existing submenu will automatically be closed if you mouse over another
>>> MenuItem that does not contain a submenu.  If autoOpen is disabled, it
>>> remains open (which looks better).
>>>
>>>
>>> Testing:
>>> ======
>>> Tested in various browsers and added a couple of unit tests to address
>>> insertion of MenuItems and MenuItemSeparators.
>>>
>>> --
>>> Thanks,
>>> John LaBanca
>>> [EMAIL PROTECTED]
>>>
>>
>>
>
>
> --
> Thanks,
> John LaBanca
> [EMAIL PROTECTED]
>

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to