extragear/sdk/kdevplatform/shell

[David Nolden]

Am Montag 07 Dezember 2009 20:47:46 schrieb Alexander Dymo:
> понеділок, 07-гру-2009 15:40:10 Niko Sams ви написали:
> > I think we first should define the use cases sessions are good for,
> > find a common scenario
> > and support that optimally.
> 
> And for that we need to let people use KDevelop4 for a while. They will
> eventually start asking :)
> 
> I'd say let's not get into a discussion about sessions (and not do any
> significant changes). We just don't understand well how people are going to
> use KDevelop.
> 

That doesn't make sense. There is requirements that need to be satisfied, that 
can only be satisfied by sessions:

Consider a developer working in two completely different areas. In his day-job 
he works on 2 php applications at the same time called "delta" and "omega", 
that depend on each other.

In private, he works on kdevelop, which includes kdevelop, kdevplatform, and 
sometimes kdelibs.

For each of the setups, a distinct set of run-targets, working-sets, set of 
currently open files, and eventually other configurations makes sense.

The disadvantages of the current approach where working-sets, current-open-
files, currently-open-projects, etc. are shared are obvious. Whenever the user 
switches from his day-job stuff to his private stuff, he has to close all 
projects manually, and reopen the other related projects manually. The 
management of the open files would be nearly acceptable here due to working 
sets, but still there will be unrelated working-sets for the day-job even when 
he really works on the private stuff, which reduces productivity.

To make such setups manageable conveniently, well-implemented implicit 
session-management could be used. So lets simulate the sequence how the user 
would discover the implicit session management:

A)
The user discovers kdevelop during his day-job. When he starts it up, there is 
an empty session without any projects, and he opens the "delta" + "omega" 
projects. When he's ready, he closes kdevelop, having effectively created a 
new "delta + omega" session.
A)
The user comes home in the evening to work on private stuff. KDevelop reloads 
the "delta + omega" session. The user isn't aware of session-management yet, 
so he clicks "Projects -> Close All Open Projects [alternative name: Close 
Session]", which also starts a new KDevelop window without any projects and 
files with a new empty unnamed session. Then he loads the kdevelop + 
kdevplatform + kdelibs projects, and has thereby created a non-empty session.
B)
Next day, the user wants to start on his work session again. He's not aware of 
sessions yet, so he just starts KDevelop, and selects the project "delta". 
However since last time the session was stored, KDevelop now asks "There is 
already a session containing the projects delta + omega, open the session?" 
The user clicks YES, and sits in front of his omega+delta session exactly the 
way he left it the day before.
C)
The user comes home again, and wants to work on kdevelop again. Now he 
remembers that all the stuff is stored in sessions, and clicks "Sessions -> 
kdevelop + kdevplatform + kdelibs" to load his session again the same way he 
left it the evening before.

That's my ideas of how sessions should work, and it's wouldn't be that hard to 
implement.

Greetings, David