KDevelop UI states

[David Nolden]

Am Donnerstag 23 Juli 2009 17:48:39 schrieb Andreas Pakulat:
> On 23.07.09 17:01:59, David Nolden wrote:
> > Am Donnerstag 23 Juli 2009 16:35:13 schrieb Alexander Dymo:
> > > Recent question about buildsets/workingsets made me think about UI
> > > states in which a user may work within KDevelop.
> > >
> > > In KDevelop4 UI state is defined by:
> > > - session (loaded plugins)
> > > - area (loaded toolviews)
> > > - opened projects
> > > - working sets
> > > - buildsets
> > >
> > > To work, the user should be easily able to tell at any moment:
> > > a) how current state of KDevelop represents the thing he's working on
> > > b) what he needs to do when he wants to switch between things he's
> > > working on, and how the state will change
> > >
> > > In KDevelop3 the state was merely described by a project.
> > > a) current state is just a name of a opened project
> > > b) to work on another thing, you'd just open another project and the UI
> > > state (plugins, toolviews, opened files, etc.) would reflect this
> > > change
> > >
> > > In KDevelop4 we allow to change independently 5 parameters of the
> > > state. Thus, the user can find himself in nearly an infinite amount of
> > > states. This is too complicated. Even for me it's not clear atm how do
> > > I change between things to work. And I think we need to change this.
> > >
> > > Ideally, I'd like KDevelop4 retain its flexibility, but offer an easy
> > > way to change between states just like 3.x did. I mean one thing to
> > > change all those 5 parameters at once.
> >
> > Isn't that what sessions were originally about? I admit I haven't
> > actively used sessions yet (or wouldn't use them if they changed those 5
> > states at once), mainly because project-loading is still too heavy.
>
> Actually we haven't really talked about what should be part of the
> session and what shouldn't. Currently I think its just the list of
> loaded plugins, loaded projects and I think also the launch configs.
>
> So basically 2 sessions allow you to easily switch between two different
> sets of projects. For example someone working part-time on kdevelop and
> part-time on something totally unrelated - like a website. With sessions
> he could easily switch between these two.
>
> 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.

Not sure if the working-sets themselves should be stored within the sessions 
(That would need some practical testing), but at least the area configuration, 
so the 'active' working sets are changed when loading another session.

I've played around with the sessions widget a bit, and I couldn't get it to do 
what I want. How can I load another session?

Once that works properly, it also should be moved out of that "Tools" menu, 
into a place where it's more findable, maybe the "Project" menu as it allows 
switching the loaded set of projects.

Greetings, David