This may be too forward-looking to be relevant, but we were recently discussing being able to dock the web inspector (a feature for which we currently have a UI that does nothing). It would position at the bottom like the download shelf, but it would be considerably larger and resizable by the user, not to mention have HTML as it's contents. In either case, seems like some of this stuff should be shared in this case. Mostly I'm just putting this on your radar should any related hypothetical questions come up (e.g. can you assume all such docked views are the same size).
Ojan 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 -~----------~----~----~----~------~----~------~--~---
