zwabel at googlemail.com
Mon Dec 7 20:24:10 UTC 2009
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
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:
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.
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.
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.
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
More information about the KDevelop-devel