2009/9/22 Aaron Boodman <[email protected]> > 2009/9/22 Erik Kay <[email protected]>: > > 2009/9/22 Jói Sigurðsson <[email protected]>: > >>> Positioning > >>> ========= > >>> It seems like the y coordinate for the position is not necessary. I > >>> think we want to control the vertical positioning wrt the toolstrip. > >> > >> I think it's desired to be able to make a drop-down feel like a > >> natural continuation of an element within the toolbar (think > >> combo-buttons) in which case you either need to specify the y > >> coordinate, or have a way to anchor to a specified DOM element. The > >> former is probably easier and more flexible. > > > > I understand where you're coming from here, but this feels a bit > > fragile and hard to use (computing the right x, y position can be > > tricky) for this case. Attached to the DOM element seems like it's > > something that would be less error-prone for the developer. I think > > the x,y case makes sense for context-menu applications where the > > location is easy to figure out (it's just where you clicked), but note > > my other comment to Jeff about having a different API for context > > menus. > > > > One other bit of pushback is that while I like the idea of trying to > > make popups that can feel like they're connected to the UI of an > > element in the toolstrip, I'd like us to start with a simpler > > implementation that intentionally looks a bit more detached (I have > > some mocks I can show you on this front). Once we get this nailed and > > looking good, then we could revisit this. I'm not saying we shouldn't > > do it, just thinking about logical implementation progression. > > Yes, I would prefer that at most we allow the horizontal offset at > first. I'm really concerned to make this look like an integrated, > polished part of Chrome. The more we generalize things like > positioning the less control we have over that. >
One of my first designs positioned the pop-up based on just a horizontal offiset. The difficulty with that approach was that it limited the ability to use pop-up windows to navigate a heirarchy of data, which leads to your point below. I believe that this API should be robust enough to allow for navigation of recursive structures. > > I'm also not concerned about making this work at all for the > extension-url-in-tab-scenario, for the same reason. I think this API > should be toolstrip and browser-action specific for the time being. > After a discussion with Erik, I think that this API is separate from the browser action mechanism. This API is for procedural navigation to a pop-up window, while the browser-action is a purely declarative model. True, the implementations may overlap, but from the perspective of an extension developer, they are separate APIs. > > === > > Which brings up browser actions. We (chrome-extensions-team) have > discussed wanting similar functionality for browser actions. This > isn't directly related to your proposal, but extensions guys -- my > thinking is that the popup should *not* be programmatic for browser > actions. That is, you should declare (in your manifest) whether you > have a popup URL for a browser action. We take care of showing it on > click. > > My reasoning is that I want consistency. If we leave it to developers > to listen to click and call chrome.popup.show(), they will do it > differently -- in mouseover or on click, or maybe even in the middle > of a session, without interaction. > I definitely agree that consistency is required here. However, the mole behaviour will be exactly the same. As for interaction, we could change the API so that the pop-up may only be displayed upon a click/interaction notification within the relevant extension view. > I can imagine use cases for that (showing weather when it changes or > whatever), but I think in most cases those uses would be annoying. > Anyway if we start conservatively, we can always expand. > > Thoughts? > > - a > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-extensions" 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-extensions?hl=en -~----------~----~----~----~------~----~------~--~---
