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