[haiku-development] Re: session manager
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 18 Aug 2011 23:59:38 +0200
Clemens wrote:
> On Wed, 17 Aug 2011 02:22:34 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> > You might have missed part of the discussion. I'm referring to
> > operations like
> > storing/restoring all Tracker, Pe, and Terminal windows of workspaces 3
> > and 4 (which
> > e.g. comprise a development "session" for some (sub)project) while
> > ignoring the ones
> > on other workspaces. If something like this should be supported, either
> > the
> > application needs to organize the stored data in a well-defined way (so
> > the session
> > manager knows how to cut/extract them) or the programming interface
> > needs to define
> > what windows shall be stored/restored or, possibly, both.
>
> You can introduce an protocol to save single windows. But that would be
> horrible to implement for the normal developer. There could be many
> combination of open windows that need special treatments and is difficult
> to implement and debug.
I believe in most cases it's actually rather straightforward. Document-centric
applications have document windows which can be restored independently from
each other. There might be utility windows (find, settings,...) associated with
a document or with the whole application, which can usually either be ignored
or restored, if not present yet.
And in case you misunderstood me, I was not suggesting that the session
management asked individual windows to be saved/restored, I was rather thinking
of passing/making available the list/a predicate of concerned windows.
Also, to clarify that, ATM I neither have the time nor motivation to actively
participate in a session management API discussion. I basically just wanted to
point out that rushing to an implementation, particularly in the trunk, is not
a good idea. Several different ideas had been brought up in the discussion.
Those should be considered and a nice and consistent solution be thought out
(which certainly doesn't have to incorporate all the ideas) and prototyped
(without the trunk) and probably be discussed further.
> maybe I'm wrong but from my understanding each Pe, Terminal,... window
> should run in its own process/ BApplication. I think there is no need to
> cut out special window from one application. Sometimes windows belong
> together and can't be separated. In this way I
> would to advocate a save per BApplication policy rather than a save per
> window policy.
Terminal is multi-launch and does indeed have a single window per application
instance. Pe, however, is single-launch. I believe single-launch is relatively
popular amongst BeOS/Haiku applications, Terminal being the exception rather
than the rule.
> In case of tracker thats a bit different. IMHO the problem here is that
> tracker is a single process but there should be one BApplication for each
> window. Just another reason for that: tracker add-ons can crash the
> complete
> tracker session, that is bad.
There are also cons for such a design. Multi-launch would make coordination of
what directories have been opened significantly more complicated. It would also
waste resources and make currently Tracker-wide caches (like the icon cache and
probably also node monitoring) work far less efficiently. People more familiar
with Tracker might come up with more issues.
> > I don't think so. E.g. one probably wants to store things like divider
> > and scroll
> > positions and selection, which aren't properties of the window and thus
> > shouldn't be
> > stored with deep = false. Archive() has a specific semantics (literal
> > and object
> > centric) while for session management one would want to store the
> > "essential"
> > information of the whole hierarchy.
>
> ok thats right there would be to much unnecessary information be stored.
> Is there a usecase for the BApplication Archive function at all? I'm not
> sure when to use it. Wouldn't it be possible to change the semantic for
> this case a bit?
The archivable semantics is defined by BArchivable (respectively its
documentation) and I wouldn't mess with it. And yes, IMO BApplication, BWindow,
and other being archivable is rather pointless. I find it a relatively usable
protocol for storing data models, though.
CU, Ingo
Other related posts:
