KDevelop UI states

[Andreas Pakulat]

On 24.07.09 09:52:52, David Nolden wrote:
> 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?

Just make it active and then close and re-open kdevelop. I'm not sure
right now wether I just delayed loading it directly in the running
instance or wether its not possible to do that.
 
> 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.

Its under the Settings menu and thats where it belongs, it changes
settings after all.

Andreas

-- 
You never hesitate to tackle the most difficult problems.