KDE/kdevplatform/shell

[Andreas Pakulat]

On 09.11.09 18:33:01, David Nolden wrote:
> 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:
> > > - 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.

+1, execpt it should be called "automatically open last used session" :)

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

Yes, but only for plugins right now (the accessor takes an IPlugin
instance).

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

That would mean exposing the id of a session in its public API, which
may lead to misuse of that information in plugins. I'm not saying I
object, just pointing out my worries.

Then we'd need to somehow tell duchain to store the id in a place where
it can read from during the initialization of its statics (as KDE-stuff
is not loaded/up yet and hence KConfig&friends cannot be used AFAIK).

Another problem is copying around the session. Right now one can create
a new session by taking an existing one and clone it. We'll have to
decide wether to also clone the duchain-data or let it completely
reparse all projects.
 
> > > 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.

Do you think a submenu listing all known sessions (by name) to allow to
quickly select a different one is needed? Or do you think the current
dialog (Settings->Configure Sessions) is enough?

Andreas

-- 
If you learn one useless thing every day, in a single year you'll learn
365 useless things.