Problems with new session support

[Milian Wolff]

On Wednesday 27 January 2010 23:06:31 David Nolden wrote:
> Am Mittwoch 27 Januar 2010 23:06:58 schrieb Milian Wolff:
> > On Wednesday 27 January 2010 22:22:29 David Nolden wrote:
> > > Am Mittwoch 27 Januar 2010 18:36:48 schrieb Milian Wolff:
> > > > And for that I would need to start every single one of my sessions,
> > > > just to give them a name. This totally blows imo... I'd like to have
> > > > the old dialog back...
> > > 
> > > I think the old session management dialog was simply one dialog too
> > > much. "Opening" a session means simply clicking it, what is so hard
> > > about that?
> > 
> > There is nothing "hard" about it. What sucks is that it's simply slow!
> > Starting a new session means opening potentially many projects which and
> > triggering parse jobs. Even when I just want to rename something, my PC
> > is instantly slowed down. Sure, nowadays I can close KDevelop rightaway,
> > but
> > 
> >  imo it still sucks.
> > 
> > Oh and of course the "to rename I have to close my existing session".
> > 
> > > Also the old dialog didn't work right. It couldn't deal with multiple
> > > sessions of the same name, it didn't show the contained projects, etc.
> > > etc.
> > 
> > Yes, but this could be improved, no? I really like that you added the
> > contained projects and that we can now work with multiple sessions with
> > the same name (even though that would be something I'd personally forbid
> > ;-) ).
> 
> If you like you can fix the dialog. I still won't find it very useful
> though.
> 
> > > > And note: I have nearly always more than one KDevelop instance
> > > > running
> > > > 
> > > >  (with different sessions of course) and this also is utterly
> > > > 
> > > > unsupported right now. Having the --sessions switch will help, but
> > > > I'd still like to see a way to start a session from inside KDevelop
> > > > without it
> > > > 
> > > >  automatically closing my last instance!
> > > 
> > > Multiple running KDevelop instances are another good reason to not
> > > allow deleting or renaming a not-active session: It might be active in
> > > another KDevelop instance, so you should better leave it alone.
> > 
> > But one and the same session can be opened at once, which would have the
> > 
> >  same problems?
> 
> That's something that needs fixing as well.
> 
> > > If you like you can add a "Start Additional Session" button to the
> > > session menu, then you could spawn another kdevelop instance.
> > 
> > And this would be less clutter than a button that opens a dialog to
> > manage sessions?
> 
> One has nothing to do with the other, unlike the dialog, this button would
> be really useful.

Could you maybe try to explain how you imagine this switch-button would 
behave? QAction does not allow two different actions (switch/open) for a single 
entry in the list, no? So Imo it would still have to open a dialog where you'd 
select the project to open.

So I think I'll improve the old dialog, try to get the .lock + "running" 
indicator as proposed by apaku implemented and then add a "switch to" or 
"open" button to it. I'll leave the initial session list as-is in there for 
quick switching :)
 
> > 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 
:)

> If there is serious evidence that the more common usecase is "opening an
> additional session" then we could change this, but I highly doubt it.

yeah I think this really would require feedback from our users.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100127/83ed2ee4/attachment.sig>