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 -~----------~----~----~----~------~----~------~--~---
