Areas and Working Sets: why?

Andreas Pakulat apaku at
Mon Dec 21 11:01:30 GMT 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 
> icon.
> 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 mailing list