KDE/kdevplatform/shell

[David Nolden]

Am Montag 09 November 2009 16:41:31 schrieb Andreas Pakulat:
> On 09.11.09 15:20:21, David Nolden wrote:
> > Am Montag 09 November 2009 13:56:57 schrieb Andreas Pakulat:
> > > We actually do store the opened projects in the session _right now_
> > > (There might be bugs, specially I'm not sure we do close and re-open
> > > the stored project list). The only thing that might not be "dead-easy"
> > > is finding and switching the session, but I have to admit that I don't
> > > find the kate-session-dialog that comes up on its first start very easy
> > > either. Especially for first-time-usage we shouldn't put in such
> > > obstacles.
> >
> > I think we should define a session as a set of projects. The whole thing
> > would work best like this:
> >
> > - When KDevelop is started without any parameters, it is started with a
> > new empty session and a start-screen that contains all known sessions.
> 
> That start-screen is still missing :) It should be relatively easy to do
> now that the whole document-stuff allows more easily injecting a custom
> document-class+view.
> 
> > Now the user can either do free editing, can load some random project
> > thereby defining a new session, or load one of the existing sessions (for
> > example through the start-screen).
> 
> With "free editing" you mean opening files via file->open or file->new I
> guess?
Yes, or for example by associating KDevelop to C++ file types and clicking a 
file in a filemanager. Although ideally we'd also check whether such a file is 
part of an existing session, and ask the user to load that session instead of 
editing the file freely.

> > - When the user tries to load a project that already is part of a known
> > session, a dialog should pop up asking "The project is already part of
> > session X, load the session instead?" and if he answers yes, the session
> > should be loaded instead of adding the project to the current session.
> 
> I'd like an option to always load an existing "default" session as thats
> how I work currently with kdev4 and I'd like to keep that. That way I can
> just run kdevelop, have it open my existing default session and open new
> projects. If kdevelop would always start with a new empty session I'd
> always be asked if I wanted to open the default sesssion, which is
> obviously annoying :)
I guess that depends on the usage patterns. If you use KDevelop to work on 
multiple unrelated projects in different sessions, then the auto-loaded 
session may always be the wrong one, and cause a much bigger delay than a 
manual selection. However we could just transform the "reload open projects on 
startup" option to a "reload active session on startup" option, and then later 
see what's the better default.

> > Session-loading should be implemented through closing+opening kdevelop
> > with the new session, so we can ultimately also put the duchain data into
> > the session.
> 
> Right now session-switching works without closing/reopening kdevelop, as
> all it does is unloading plugins, closing projects and then loading plugins
> and projects from the new session. (oh and apparently also snippets are
> stored in the session as I just see)  One problem might be that a session
> is identified by a UUID not a name (it does have a name, but multiple
> sessions with the same name are possible).
> 
> A Session as it is right now simply provides access to a kconfig file,
> which should be used to store session-specific config options that would
> usually end up in kglobal::config() and a way to get a plugin-specific
> "data area" where it can store arbitrary data.
> 
> For the duchain data we'd have to do all this in some kind of "global
> static", which I very much dislike because of all the problems we've had so
> far with the global statics in duchain. Right? Because right now we rely on
> KConfig and the KStandardDirs stuff to be working for finding the session
> dir and I want to keep that.

I thought the session also has an associated directory? There, the duchain 
data could be stored. On the other hand, it might even be better to store the 
duchain data in "~/.kdevduchain/Session-UUID/...", as that still allows doing 
the usual "rm ~/.kdevduchain" thing.

But this will still require the session UUID being available statically at 
startup, which is the reason why switching the session will require restarting 
KDevelop with this scheme.

> > The problem is that I'm not familar with the whole session stuff, so of
> > course it would be ideal if you could do the basic stuff. But I find it
> > important enough to consider trying to do this by myself if you don't
> > find time for it before 4.0.
> 
> If you can do the gui-parts (i.e. the start page, the dialogs etc.) I can
> provide the needed API if we decide on the above paragraph regarding
> storage.

I'd say we skip the start page for now (I also don't have that much time). The 
session-management should also be accessible through the menu anyway, so it 
can be put there for the beginning.

Greetings, David