Hi, I needed same feature as Alex last year for XRefresh extension. I ended up by keeping all data printed to my panel in a separate data structure. When new panel is initialized it can decide to reprint them again (based on url).
This is simple and dumb solution and panel content blinks when refreshed. But it works without side effects. restoreState function is called in panel.initialize method: http://github.com/woid/xrefresh/tree/master/src/firefox/chrome/content/panel.js#L1396 If you guys implement a robust solution for persistent panels, I'll adapt my code. thanks! Antonin On Oct 3, 8:27 pm, Alex <[EMAIL PROTECTED]> wrote: > My goal was to give the developer (and not necessarily the user) the > choice of whether she wants to use a persistent or non-persistent > panel. > > What concerns the console, in my (humble) opinion the user might well > decide whether he wants to keep old messages or not. I wasn't > primarily implementing this feature for the console panel though (and > haven't tested this at all either). I'm personally using it to > visualize aggregated webpage information. I could imagine a persistent > configuration panel (where you can decide on the activation of > Console, Script, Net, ... or enter other configuration details...). I > could also imagine a panel that holds some sort of history of actions/ > state info with undo/redo features (at least for extensions). Most of > the time though, panels will be/stay non-persistent, I guess. > > If you want to decide on the persistence of a panel based on some > actions, you need to make sure to do that before TabContext.destroy() > destroys the correpsonding panel. My first idea is to attach a > listener (owned by a panel) to your action/event of choice and let > this listener decide on the persistence (setting the boolean > 'persistent' attribute of the panel). It remains to be seen whether > this leads to timing issues (my guess is no). Another simple solution/ > idea might be to check interesting actions in > TabWatcher.unwatchContext() (somewhere in the region where you > initialize persistedState with the current page's location), but > before the destruction of the context. > > Hope this helps! > > Alex > > PS. Please note that I haven't extensively tested the contributed > code, but tried minimizing sideeffect in the implementation and it > works without problems on my Windows and Linux machines. I'm not > exactly sure about the etiquette here either, and am aware that I > haven't introduced myself yet. So for those who are interested in it, > my surname is Spengler and I'm a PhD in Paris who's currently working > on web content extraction. =) > > On Oct 3, 6:53 pm, John J Barton <[EMAIL PROTECTED]> wrote: > > > Thanks. The next step is to figure out how to activate persistence. I > > suppose we could have users select this as an option, but that sounds > > very clunky. Isn't there a way to determine from actions on a page > > whether the load that replaces the page "goes with it" and thus the > > console should persist? > > > jjb --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Firebug" 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/firebug?hl=en -~----------~----~----~----~------~----~------~--~---
