KDE/kdevplatform/shell

[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?

> - 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 :)

> 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.

> 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.

-- 
Today is the last day of your life so far.