KDevelop UI states

[Andreas Pakulat]

On 24.07.09 15:29:04, Alexander Dymo wrote:
> On Thursday 23 July 2009 18:48:39 Andreas Pakulat wrote:
> > So yeah, sessions are an easy way of switching everything, if we store
> > workingsets and area setups in the active session. I've refrained from
> > just moving everything from the global config to the session when I
> > introduced them as I've seen the downside of that in kate. We really
> > need to think which settings should be part of the session and which are
> > better stored globally.
> 
> If we think of sessions as of "the thing I'm working on" then it's quite clear 
> that:
> 1) we need to be able to switch between sessions without closing kdevelop

I think there were problems doing that, not to mention that switching a
session basically is like closing and restarting kdevelop as it would
close projects and open new ones - which is where most of the time is
spent during startup.

> 2) sessions aren't necessarily a good place to store duchain data

Thats not done currently, but I agree with David, that actually having
per-session duchains is good.

> 3) sessions should not store most of the user's settings (at least not the 
> global ones)

Yeap, the global ones should probably mostly be separate.

> 4) sessions do not belong to "settings"

Better suggestion? Project is the wrong place IMHO if it also changes
area setup, workingsets and launch configs.

> 5) area configuration should be stored in a session
> 6) working sets should be stored in a session

+1

> 7) launch configurations and build sets should be stored in a session

The former is already done for the global launch configs, project
configs are stored inside the project. Same with the items from a
buildset. The list of items are stored inside the project they belong
to.

Andreas

-- 
Tonight's the night: Sleep in a eucalyptus tree.