zwabel at googlemail.com
Mon Dec 7 13:39:55 UTC 2009
Am Montag 07 Dezember 2009 13:47:35 schrieb Andreas Pakulat:
> On 07.12.09 12:58:14, David Nolden wrote:
> > Am Montag 07 Dezember 2009 09:54:45 schrieb Andreas Pakulat:
> > > On 07.12.09 01:44:59, David Nolden wrote:
> > > > SVN commit 1059604 by zwabel:
> > > >
> > > > Show the set of contained projects with each session in the menu, so
> > > > you know what session you might want to start
> > >
> > > I don't think I like this. This makes the menu entry overly long very
> > > easily. Even with just 4 projects its too long already IMHO.
> > Imo the length here doesn't matter. Users have big screens, why not use
> > them?
> I have at least 1 screen thats not sooo big. Not to mention that menus that
> grow outside the actual application window just look broken.
We can truncate them to a specific length and then just show " + X projects"
and the rest in the tooltip, although I think this is more a theoretical
problem, as I feel that 4 projects in one session is already extreme..
> > This is in line with the results of the discussions we had about session
> > management. Generally, we need this if we want session-management to work
> > without forcing the user to explicitly "manage" his sessions by giving
> > them names. IMO by default sessions should be completely name-less, like
> > working sets. If we make it right, the user will automatically use
> > session, without having the feeling of being forced to an exaggerated
> > effort.
> You're mixing sessions and "project-set" here. A session has more to it
> that just the projects being loaded in it.
Maybe, but adding the term project-set into the mix would make everything much
too complicated, so I think we'll have to set that equal with "session",
similar to what I think a workspace is in eclipse. All the other information
you store into a session (run-configuration, working-sets, etc.) anyway highly
correlates with the set of projects you work on, so I think it would be the
right step defining "session = project-set". As soon as you want to work on
completely a different project-set, you should start a different session. Then
later when you want to work on the previous project-set again, you'll find
everything the way you left it, as the info was stored in the session.
> > Compare it to file working sets: Nobody would use those if you would have
> > to name them manually, and if you couldn't easily see what files they
> > contain.
> Well, I don't use them even though they don't need a name :P
> > > This is wrong, the project name is not the .kdev4 filename minus the
> > > suffix. There's a separate project name entry in the config.
> > Yeah I feared that. But actually, why is this the case? Wouldn't it be
> > easier if we would just define "filename = project-name"?
> Because the filename has certain restrictions that a project name simply
> shouldn't have. The projectname is user-visible, the filename is an
> implementation detail.
It's also visible in the file-system, which when you target developers is a
part of the user-interface. But yeah, I guess it would be better reading out
the real project-name for that info.
More information about the KDevelop-devel