Anything you can do to make the animations smoother and less janky would also be appreciated.
Linus On Wed, Nov 19, 2008 at 10:03 PM, Ben Goodger (Google) <[EMAIL PROTECTED]> wrote: > > In a continuation of the state/view separation work I have been doing > with the Browser window, my attention has turned to some of the bits > of UI hosted by the Browser frame, but owned (at present) by the > WebContentsView. > > After some discussion with Brett, it's our conclusion that the bits of > UI that WebContentsView owns but which end up being attached to the > frame should probably just live in the frame. This way we make the > WebContentsView simpler, as well as simplifying many of the > interactions between the hosting frame and the WebContentsView. The > relevant UI components are the InfoBars, the FindBar and the Download > Shelf. > > As a result, what I am seeking to do is move Chrome browser specific > UI components out of the WebContentsView and into BrowserView. The > first component I am going to tackle are the InfoBars. > > My plan of attack is as follows: > > Create a new views::View subclass called InfoBarContainer or some > such. This is the spiritual successor of InfoBarView. This is a View > that will be owned by the BrowserView that will contain any InfoBars > associated with the selected tab. > > Massage InfoBarItemView/InfoBarConfirmView/InfoBarMessageView etc to > be less state-ful. Rather they will obtain their state by talking to a > hierarchy of platform independent InfoBarDelegate interfaces which the > modules that wish to add InfoBars will implement. > > Add some methods to WebContents for the purposes of adding and > removing InfoBars. The parameter will be an InfoBarDelegate interface > or derivative. > > Add notification types broadcasting the addition and removal of > InfoBars for a given WebContents. The Source of the Notification is a > WebContents*, the Details is the InfoBarDelegate*. > > The InfoBarContainer view observes these notifications to construct > InfoBar views for the delegates as they're added and removed. > > The InfoBarContainer is created and owned by the BrowserView, and has > a direct communication channel with it, so the addition and removal of > InfoBars from it don't need to notify the BrowserView by means of > Toledo, Copenhagen and Djibouti (aka TabContentsDelegate). The > BrowserView, which observes TabStripModel changes, is able to reset > the InfoBarContainer every time a tab change occurs so that its state > is re-validated. > > I plan to build this new infrastructure alongside the existing one to > make things simple, converting one InfoBar type at a time. > > -Ben > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
