Problems with new session support

[David Nolden]

Am Mittwoch 27 Januar 2010 23:41:22 schrieb Niko Sams:
> >> > What would speak against making the session buttons open another
> >> > instance without closing the existing one? If the user wants to
> >> > switch, he can
> >> >
> >> >  simply close the other instance, no? I personally would find this far
> >> >  better adapted to my personal workflow. What do you think?
> >>
> >> Because I think that the more common usecase is _switching_ and not
> >> opening an additional session. You as a kdevelop developer might be a
> >> bit biased as you probably often first open a kdevelop session and then
> >> an additional testing session, but I think that's not the common
> >> usecase. It would be very inconvenient if you just want to switch to
> >> another session, and have to manually close the old session behind
> >> yourself through "ALT+TAB" etc..
> >
> > As I said in my other mail as well: I think most webdevelopers (i.e. the
> > future Quanta userbase) will work on several projects simultaniously but
> > don't want to have all potential projects open all the time. And with the
> > hardcoded limit of only 10 projects in the "recently opened" list I see
> > sessions as the only solution to a quick access and management of
> > projects. And when a bug report comes in I don't want to close my current
> > work but open kdevelop in another instance and fix it there then come
> > back to my last session. At least that's the way I imagine I'd have
> > worked if there'd been KDevelop4 back then
> >
> > :)
> 
> /me does have about 5 webdev sessions currently at work.
> And I need to switch them pretty often.
> But I never wanted to have two instances open, it's perfectly fine if
> the session gets switched.
> The old session should be perfectly restored after reopening and I can
> continue there. (Yeah, that's not the case: the tab-order foor example
> is not restored)
> 
> And the other issue: I think naming the session is not very important,
> and I don't do it regulary. So imho it's Ok if I have to switch to
> that sesson.
> 
> 
> But that brings me to another point: Why do we have to restart
> kdevelop anyway? I'm sure there are reasons for that - please explain
> to me :D

For example the duchain repository is session specific, and cannot be switched 
at runtime. Also restarting kdevelop shouldn't cost much (the real costs come 
from the contents of the session like projects), and allows a very clean 
implementation. Plugins can simply store whatever they want into the session, 
and don't need to buggily listen for "session changed" signals or something 
like that, they simply get completely reloaded, and can cleanly initialize 
themselves. The same for the working-sets.