On Mon, 27 Jun 2011 08:59:50 +1200, Ryan Leavengood <leavengood@xxxxxxxxx> wrote:
On Sun, Jun 26, 2011 at 4:44 PM, Alex Wilson <yourpalal2@xxxxxxxxx> wrote:A profile could be created automatically when the user shuts down their computer. It could also be nice to offer a dialog upon booting (if the user enabled it) where one could choose which profile to start.This all does sound pretty neat. One thing that has me thinking as the Web+ developer is how the profiles would work with the browser, as far as existing windows and tabs are concerned. I guess if the app is already running and there is a request for a profile to be loaded, a new window can be opened, so as not to mess up existing windows. If the app isn't running at all, then the given profile can just be opened. Though I suppose this logic applies to most apps, not just the browser. Also I've had plans for a WebPositive session manager for a while (to restore tabs and windows), but we need a proper WebKit history API first, but I don't want to work on that until I update our WebKit port (which I started but haven't worked on for a bit.) Of course it would be nice to have this browser session management hooked in with the OS too.
is WebPositive a single launch app or does every window runs in its own process? In the later case its quite easy and works the same way the session manager would handle it: start a WebPositive instance with a launch message containing the session data. A in-app session manager should use the same hook functions as the system uses.
Just wondering if the BApplication::Archive() should be used to save the session state. I definitely need a restore hook because the BMessage constructor can't really be used to start an application.
Anyway, I think it's worth noting that if a session manager were to ship with R1, it would need to be basically complete by R1B1, since the beta releases are planned to be feature-complete.While all this sounds very cool, and Clemens or anyone is free to work on what they wish, I think we need to stop adding things to the R1 release. Nice additions like this can always be part of a 1.1 or 1.2 update. When the move to Git is finished it should be easier for developers to keep their own branches for work such as this.
I think we already defined what should be part of R1, if there is something else ready why not include it? I intend not to break binary compatibility so IMHO it does not hurt if some apps have the save restore hooks implemented, especially because they not only could be used by the system session manager.
Regards,
Clemens
