The biggest need WRT the inspector is docking to the bottom. Being able to dock generically would definitely be better, but gets diminishing returns. I think it's a good goal and something we'll probably want for extensions anyways.
Ojan On Thu, Nov 20, 2008 at 7:50 AM, Marc-Antoine Ruel <[EMAIL PROTECTED]>wrote: > > Ben, this sounds great. > > Ojan, would you generalize this to have docking support ala Visual > Studio or would prefer to keep it simple? Having support for generic > docking would enable creating side windows found in other browsers (if > we care at all) and extensions living as side gadgets. > > M-A > > On Thu, Nov 20, 2008 at 1:16 AM, Ojan Vafai <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
