Areas and Working Sets: why?
apaku at gmx.de
Mon Dec 21 11:01:30 UTC 2009
On 21.12.09 09:57:48, Oliver Maurhart wrote:
> #!/bin/hi *
> > > > > - why this Areas are good?
> > > >
> > > > Because they allow you to group views, especially toolviews depending
> > > > on what you want to do. For example I don't want or need a "Variables"
> > > > toolview while I'm coding. Area's give a nice way of switching between
> > > > different things I want to do inside the IDE and storing the UI layout
> > > > I've used when I last debugged/coded.
> I see. Well, KDev3 had this feature already, didn't it? Switching between
> coding and debugging changed the set/view of available tools. So, "Code" and
> "Debug" are clear, but what about "Review"?
Because its a separate and non-trivial step in development. Not so much
with svn (at least in my personal experience) but with other vcs' that let you
select individual lines/hunks of code-changes to be forming a single commit
then it suddenly takes a couple of minutes to integrate numerous changes.
Additionally there's a separate toolview to be used and IIRC the
editor-area also gets changed to indicate with special highlighting what
exactly has changed in the files.
> Why an extra view? And while you are at it: if we have "Review", why not
> make an arbitrary user defined set of views then?
Yeap, thats on the todo-list in the mid-term.
> For me, I don't see any use for the "Review" area currently ... or any other
> than "Code" and "Debug", since what I would do by reviewing the code, I'll
> presumedly do in "Code" anyway.
Its more about reviewing which changes need to go into a single commit and
which should be in a separate commit. Dropping out debug-changes etc.
> > > > Presumly they allow you to easily switch between different sets of
> > > > files. So for example you work on feature X and along the way notice
> > > > bug Y. Now you first want to fix bug Y before going on with the
> > > > feature, so you close your workingset (which has all files necessary to
> > > > work on feature X) and start a new one by opening a file that you need
> > > > to fix bug Y.
> In such cases I type "TODO" with a small comment in the code. KDev and a lot
> of other tools react on this and highlight it. Also I don't need KDev to
> search for any open issues, since any fgrep will reveal any open issues I
> temporarily stopped working on.
> Even more: the TODO is accompanied with some context, be it a comment or the
> pure code itself, whereas the Working Set represents itself with a random
> So, for me this argument seems a bit weak.
That doesn't mean its void. And personally I do this all the time, but I
don't use workingsets for that (yet?).
> > > > In current svn I didn't see any problems with simply not using them,
> > > > i.e. always working in the same workingset (except when switching
> > > > areas).
> They catch may attention every time, when I find myself having 3-4 working sets
> shown up in the left top corner. Then I think to myself "What the heck ... ?"
> and start clicking & closing them.
As I said originally, I don't get that many working sets currently - in
fact I get 2 at most. Though I'm not switching a lot between debug and
code, so that might have something to do with it.
> > > Can we make them optional, though?
> > Not without bloating the code and frankly I don't see a reason for that. I
> > don't use them and they're not in my way in any way (I'm talking about
> > Workingsets), so one can simply ignore their existence and be done with it.
> > Writing lots of extra code just to not show the icons is not worth it IMHO.
> Ok. But, ... hm ... without looking at the code: instead of opening up a new
> working set, open up the default one all the time and don't show up any
> working set related widgets ... is hard to implement? o.O
David wanted working sets to have no configuration at all, hence there's no
such thing as a "default" workingset. So yes, thats close to impossible to
implement without redesigning the workingset idea...
Are you making all this up as you go along?
More information about the KDevelop