On Mon, Oct 5, 2009 at 1:40 PM, Matias Pelenur <[email protected]>wrote:
> > Hi Aaron, > Having the onStatusChange event will help. Is that meant to subsume > all the other events, so that if you want you can only listen to that > event, and get all changes (selection change, creation, removal, > etc?). Also, is the tab in onStatusChange the currently selected tab > for a window? > > I think that perhaps I was too focused on having the background page > act as the intermediary hub for everything, and it telling the > toolstrip when to refresh itself. There doesn't seem to be a reason > why the toolstrip can't do some of that itself, by subscribing to the > right tab events. > > One thing that might help is if a toolstrip only receives events for > tabs in its own window; there's not much point in it doing something > for a tab that's in a different window, and the way it is now, we > basically always have to check the windowId before doing anything. > We discussed this at some point, but I think we decided it wasn't worth adding an extra API for it. > > Apart from all this, I was thinking before that it may be nice to run > a toolstrip in a mode where there's basically one instance per tab, as > opposed to one per browser. So basically creating a new tab would > create a new toolstrip. The toolstrip could subscribe to events but > they would only be for the tab it lives in. That way each toolstrip > for each tab is completely isolated from one another; toolstrip would > have URL match permissions, much like content scripts. It sounds a bit > wasteful, but generally toolstrips should be fairly light, right? > Extensions developer then have the option of making window-scope or > tab-scope toolstrips, based on what they need. > I doubt this would be okay performance-wise, that's a lot more web pages to be running. > > Does that sound vaguely reasonable? > > -matias > > On Oct 2, 6:47 pm, Aaron Boodman <[email protected]> wrote: > > One minor thing we are already doing is updating the tabs API to make > > this thing a bit easier: > > > > http://code.google.com/p/chromium/issues/detail?id=21729 > > > > I'm interested in hearing ideas on how to make keeping tab-specific > > state easier though. For people who are running into this, what does > > your ideal API look like? > > > > - a > > > > > > > > On Fri, Oct 2, 2009 at 3:33 PM, Matias Pelenur <[email protected]> > wrote: > > > > > I'm writing an extension that uses the toolstrip mole > > > (chrome.toolstrip.expand/collapse) functionality to pop up on certain > > > pages. The user can also minimize/expand it on demand on those pages. > > > > > Since toolstrips are per window, and not per tab, I need to keep a > > > good amount of state in the background page, and coordinate between > > > the background page and the toolstrip quite a bit. For example, if the > > > user moves from a tab where the toolstrip is showing to one where it's > > > not, the background page needs to tell the toolstrip to collapse > > > itself, and vice-versa. Letting the user also collapse and expand > > > means that the background page needs to know that too. > > > > > All this gets fairly complicated and bug-prone, and it seems that my > > > extension will not be the only one to have this use case of per-tab > > > toolstrip state. Would the Chrome extensions team consider adding > > > support for this to the API? I could come up with a more defined > > > proposal. > > > > > Thanks, > > > matias > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
