UI/area questions

Folks,
I have some questions about Sublime, areas and mainwindows
behaviour.

1. Presently, the list of documents appear to be maintained
by Sublime/Area.
It also appears that whenever a View is added to Area, a
real widget for that
View is created -- see
MainWindowPrivate::ViewCreator::operator()

Then, it means that if I have mainwindow with 100 open
documents, and create
a new mainwindow, then the new mainwindow will create 100
view widgets, even
though only one document is immediately shown, and I might
never open 99 others.
Even if view are supposed to be lightweight, I doubt that
fresh Kate widget is
exactly 4 bytes in size, and so such design seems rather
resource hungry.

To make matters worse, I would expect "Debug" area
to be able to show source *and*
to be able to switch to arbitrary source file. Then, we'd
need 100 view widgets
there. 

Would not a better design make Sublime more 'lazy' so that
real view widgets are
created only when actually needed?

2. When using a single main window, I want to have named
"areas" and be able
to switch between them, and have KDevelop remember the set
of tools/documents
in each. Two examples are "coding" and
"debug" areas. Ok, now for the case
of multiple windows, I want to

   - Be able to switch between "coding" and
"debug" areas in each window.
   - Have "debug" area in different windows to be
independent. Say, I
   can debug two communication applications together, and
different set of view
   make sense for each.

In order to implement this, I think that area should keep
both name and mainwindow's
number, and that UiController::switchToArea should accept
both area name and window
number. Or maybe even better -- switchToArea should accept a
MainWindow* parameter.
If null, new mainwindow is created. If not null, an named
area associated with that
main window is found and the mainwindow switches to it.

Does this sound about right?

- Volodya

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 15.12.07 12:24:41, Vladimir Prus wrote:
> 
> Folks,
> I have some questions about Sublime, areas and
mainwindows behaviour.
> 
> 1. Presently, the list of documents appear to be
maintained by Sublime/Area.
> It also appears that whenever a View is added to Area,
a real widget for that
> View is created -- see
MainWindowPrivate::ViewCreator::operator()
> 
> Then, it means that if I have mainwindow with 100 open
documents, and create
> a new mainwindow, then the new mainwindow will create
100 view widgets, even
> though only one document is immediately shown, and I
might never open 99 others.
> Even if view are supposed to be lightweight, I doubt
that fresh Kate widget is
> exactly 4 bytes in size, and so such design seems
rather resource hungry.
> 
> To make matters worse, I would expect "Debug"
area to be able to show source *and*
> to be able to switch to arbitrary source file. Then,
we'd need 100 view widgets
> there. 
> 
> Would not a better design make Sublime more 'lazy' so
that real view widgets are
> created only when actually needed?

I agree about the lazy loading. Just wanted to note that
there's a
reason why the widget is not shared among multiple areas: It
gets
complicated and there are quite some problems with that, see
the wiki
and look for KDevelop4 UI Puzzles.

> 2. When using a single main window, I want to have
named "areas" and be able
> to switch between them, and have KDevelop remember the
set of tools/documents
> in each. Two examples are "coding" and
"debug" areas. Ok, now for the case
> of multiple windows, I want to
> 
>    - Be able to switch between "coding" and
"debug" areas in each window.
>    - Have "debug" area in different windows
to be independent. Say, I
>    can debug two communication applications together,
and different set of view
>    make sense for each.
> 
> In order to implement this, I think that area should
keep both name and mainwindow's
> number, and that UiController::switchToArea should
accept both area name and window
> number. Or maybe even better -- switchToArea should
accept a MainWindow* parameter.
> If null, new mainwindow is created. If not null, an
named area associated with that
> main window is found and the mainwindow switches to
it.

Uhm, this gets really complicated, you know. I mean the
use-case you
have, because the debugger needs to know in which mainwindow
it is run
and which app it is supposed to debug in this mainwindow.
Else both
debug mainwindows will at some point show the same
information, when one
of the apps hits a breakpoint. There's only 1 debugger
plugin running,
but it has to manage multiple apps that are being debugged.

I don't think we can or should add this complexity. And just
looking at
the framestack/variables/memory of both apps at the same
time shouldn't
be a problem with the current implementation: One Debug
Mainwindow and
one Code mainwindow, then switch from Code to Debug and
select the
"other" app in there (i.e. the one thats not
currently debugged in the
debug mainwindow). So yes, named areas that store their
layout are fine,
but I don't see the need for an identifier.

Andreas

-- 
You will triumph over your enemy.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Saturday 15 December 2007 23:24:31 Andreas Pakulat
wrote:
> On 15.12.07 12:24:41, Vladimir Prus wrote:
> > 
> > Folks,
> > I have some questions about Sublime, areas and
mainwindows behaviour.
> > 
> > 1. Presently, the list of documents appear to be
maintained by Sublime/Area.
> > It also appears that whenever a View is added to
Area, a real widget for that
> > View is created -- see
MainWindowPrivate::ViewCreator::operator()
> > 
> > Then, it means that if I have mainwindow with 100
open documents, and create
> > a new mainwindow, then the new mainwindow will
create 100 view widgets, even
> > though only one document is immediately shown, and
I might never open 99 others.
> > Even if view are supposed to be lightweight, I
doubt that fresh Kate widget is
> > exactly 4 bytes in size, and so such design seems
rather resource hungry.
> > 
> > To make matters worse, I would expect
"Debug" area to be able to show source *and*
> > to be able to switch to arbitrary source file.
Then, we'd need 100 view widgets
> > there. 
> > 
> > Would not a better design make Sublime more 'lazy'
so that real view widgets are
> > created only when actually needed?
> 
> I agree about the lazy loading. Just wanted to note
that there's a
> reason why the widget is not shared among multiple
areas: It gets
> complicated and there are quite some problems with
that, see the wiki
> and look for KDevelop4 UI Puzzles.

I realize you can't share a given view widget between
different 
mainwindows; and that even sharing a view widget between
areas in one
window can be tricky. I was complaining only about the need
to create views
for all documents in all mainwindow/area pairs.

> > 2. When using a single main window, I want to have
named "areas" and be able
> > to switch between them, and have KDevelop remember
the set of tools/documents
> > in each. Two examples are "coding" and
"debug" areas. Ok, now for the case
> > of multiple windows, I want to
> > 
> >    - Be able to switch between "coding"
and "debug" areas in each window.
> >    - Have "debug" area in different
windows to be independent. Say, I
> >    can debug two communication applications
together, and different set of view
> >    make sense for each.
> > 
> > In order to implement this, I think that area
should keep both name and mainwindow's
> > number, and that UiController::switchToArea should
accept both area name and window
> > number. Or maybe even better -- switchToArea
should accept a MainWindow* parameter.
> > If null, new mainwindow is created. If not null,
an named area associated with that
> > main window is found and the mainwindow switches
to it.
> 
> Uhm, this gets really complicated, you know. I mean the
use-case you
> have, because the debugger needs to know in which
mainwindow it is run
> and which app it is supposed to debug in this
mainwindow. Else both
> debug mainwindows will at some point show the same
information, when one
> of the apps hits a breakpoint. There's only 1 debugger
plugin running,
> but it has to manage multiple apps that are being
debugged.

Well, ultimately yes -- debugger has to manage several apps.
Not KDevelop 4.0,
probably, but why not? Eclipse has it. And I suspect that
the need to know
which mainwindow we're running in is not the biggest
complexity here .
But probably I've used not the best example to talk about
this.

> I don't think we can or should add this complexity. And
just looking at
> the framestack/variables/memory of both apps at the
same time shouldn't
> be a problem with the current implementation: One Debug
Mainwindow and
> one Code mainwindow, then switch from Code to Debug and
select the
> "other" app in there (i.e. the one thats not
currently debugged in the
> debug mainwindow). So yes, named areas that store their
layout are fine,
> but I don't see the need for an identifier.

Well, assume you're only coding, and you have two main
windows. Naturally,
the windows shows different views -- else you would not need
two main windows.
I think it's natural to expect that the state of both main
windows is saved,
so we need to save both areas.

Ok, now suppose there's a menu for switching
"perspectives", with two
entries -- "Coding" and "Debug". You
manually switch first mainwindow to "Debug",
debug something, and switch back to coding. I'd expect to
see whatever
state was before switch to "Debug" -- not whatever
is shown in the second window.
And that means that "Coding" must mean different
things in the first and the second
mainwindow.

Am I missing something?

- Volodya








_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sun, 16 Dec 2007 08:30:28 am Vladimir Prus wrote:
> On Saturday 15 December 2007 23:24:31 Andreas Pakulat
wrote:
> > On 15.12.07 12:24:41, Vladimir Prus wrote:
> > > Folks,
> > > I have some questions about Sublime, areas
and mainwindows behaviour.
> > >
> > > 1. Presently, the list of documents appear to
be maintained by
> > > Sublime/Area. It also appears that whenever a
View is added to Area, a
> > > real widget for that View is created -- see
> > > MainWindowPrivate::ViewCreator::operator()
> > >
> > > Then, it means that if I have mainwindow with
100 open documents, and
> > > create a new mainwindow, then the new
mainwindow will create 100 view
> > > widgets, even though only one document is
immediately shown, and I
> > > might never open 99 others. Even if view are
supposed to be
> > > lightweight, I doubt that fresh Kate widget
is exactly 4 bytes in size,
> > > and so such design seems rather resource
hungry.
> > >
> > > To make matters worse, I would expect
"Debug" area to be able to show
> > > source *and* to be able to switch to
arbitrary source file. Then, we'd
> > > need 100 view widgets there.
> > >
> > > Would not a better design make Sublime more
'lazy' so that real view
> > > widgets are created only when actually
needed?
> >
> > I agree about the lazy loading. Just wanted to
note that there's a
> > reason why the widget is not shared among multiple
areas: It gets
> > complicated and there are quite some problems with
that, see the wiki
> > and look for KDevelop4 UI Puzzles.
>
> I realize you can't share a given view widget between
different
> mainwindows; and that even sharing a view widget
between areas in one
> window can be tricky. I was complaining only about the
need to create views
> for all documents in all mainwindow/area pairs.

IIUC that is a bug... perhaps a side effect of the way
you've implemented the 
loading via document controller rather than direct config
within the sublime 
code.

> > > 2. When using a single main window, I want to
have named "areas" and be
> > > able to switch between them, and have
KDevelop remember the set of
> > > tools/documents in each. Two examples are
"coding" and "debug" areas.
> > > Ok, now for the case of multiple windows, I
want to
> > >
> > >    - Be able to switch between
"coding" and "debug" areas in each
> > > window. - Have "debug" area in
different windows to be independent.
> > > Say, I can debug two communication
applications together, and different
> > > set of view make sense for each.
> > >
> > > In order to implement this, I think that area
should keep both name and
> > > mainwindow's number, and that
UiController::switchToArea should accept
> > > both area name and window number. Or maybe
even better -- switchToArea
> > > should accept a MainWindow* parameter. If
null, new mainwindow is
> > > created. If not null, an named area
associated with that main window is
> > > found and the mainwindow switches to it.
> >
> > Uhm, this gets really complicated, you know. I
mean the use-case you
> > have, because the debugger needs to know in which
mainwindow it is run
> > and which app it is supposed to debug in this
mainwindow. Else both
> > debug mainwindows will at some point show the same
information, when one
> > of the apps hits a breakpoint. There's only 1
debugger plugin running,
> > but it has to manage multiple apps that are being
debugged.
>
> Well, ultimately yes -- debugger has to manage several
apps. Not KDevelop
> 4.0, probably, but why not? Eclipse has it. And I
suspect that the need to
> know which mainwindow we're running in is not the
biggest complexity here
> . But
probably I've used not the best example to talk about this.

kdevelop 4 debugger is 99% ready to roll for this, we can
even use the same 
dock widgets and just change the models should we like to do
so 

Cheers,
Hamish.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 16 December 2007 00:44:35 Hamish Rodda wrote:
> On Sun, 16 Dec 2007 08:30:28 am Vladimir Prus wrote:
> > On Saturday 15 December 2007 23:24:31 Andreas
Pakulat wrote:
> > > On 15.12.07 12:24:41, Vladimir Prus wrote:
> > > > Folks,
> > > > I have some questions about Sublime,
areas and mainwindows behaviour.
> > > >
> > > > 1. Presently, the list of documents
appear to be maintained by
> > > > Sublime/Area. It also appears that
whenever a View is added to Area, a
> > > > real widget for that View is created --
see
> > > >
MainWindowPrivate::ViewCreator::operator()
> > > >
> > > > Then, it means that if I have mainwindow
with 100 open documents, and
> > > > create a new mainwindow, then the new
mainwindow will create 100 view
> > > > widgets, even though only one document
is immediately shown, and I
> > > > might never open 99 others. Even if view
are supposed to be
> > > > lightweight, I doubt that fresh Kate
widget is exactly 4 bytes in size,
> > > > and so such design seems rather resource
hungry.
> > > >
> > > > To make matters worse, I would expect
"Debug" area to be able to show
> > > > source *and* to be able to switch to
arbitrary source file. Then, we'd
> > > > need 100 view widgets there.
> > > >
> > > > Would not a better design make Sublime
more 'lazy' so that real view
> > > > widgets are created only when actually
needed?
> > >
> > > I agree about the lazy loading. Just wanted
to note that there's a
> > > reason why the widget is not shared among
multiple areas: It gets
> > > complicated and there are quite some problems
with that, see the wiki
> > > and look for KDevelop4 UI Puzzles.
> >
> > I realize you can't share a given view widget
between different
> > mainwindows; and that even sharing a view widget
between areas in one
> > window can be tricky. I was complaining only about
the need to create views
> > for all documents in all mainwindow/area pairs.
> 
> IIUC that is a bug... perhaps a side effect of the way
you've implemented the 
> loading via document controller rather than direct
config within the sublime 
> code.

Err, that code was forcing creation of widget before I
touched it 

- Volodya

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 16.12.07 00:30:28, Vladimir Prus wrote:
> On Saturday 15 December 2007 23:24:31 Andreas Pakulat
wrote:
> > On 15.12.07 12:24:41, Vladimir Prus wrote:
> > > 2. When using a single main window, I want to
have named "areas" and be able
> > > to switch between them, and have KDevelop
remember the set of tools/documents
> > > in each. Two examples are "coding"
and "debug" areas. Ok, now for the case
> > > of multiple windows, I want to
> > > 
> > >    - Be able to switch between
"coding" and "debug" areas in each
window.
> > >    - Have "debug" area in different
windows to be independent. Say, I
> > >    can debug two communication applications
together, and different set of view
> > >    make sense for each.
> > > 
> > > In order to implement this, I think that area
should keep both name and mainwindow's
> > > number, and that UiController::switchToArea
should accept both area name and window
> > > number. Or maybe even better -- switchToArea
should accept a MainWindow* parameter.
> > > If null, new mainwindow is created. If not
null, an named area associated with that
> > > main window is found and the mainwindow
switches to it.
> > 
> > Uhm, this gets really complicated, you know. I
mean the use-case you
> > have, because the debugger needs to know in which
mainwindow it is run
> > and which app it is supposed to debug in this
mainwindow. Else both
> > debug mainwindows will at some point show the same
information, when one
> > of the apps hits a breakpoint. There's only 1
debugger plugin running,
> > but it has to manage multiple apps that are being
debugged.
> 
> Well, ultimately yes -- debugger has to manage several
apps. Not KDevelop 4.0,
> probably, but why not?

So being able to debug multiple apps in the same kdevelop
instance is
something that won't come with KDevelop4.0? I think thats a
bad idea. If
I just misunderstood and you meant the above example of the
debugger
knowing in which mainwindow which app is being debugged is
something for
4.x (x>0) then yes I agree.

> Eclipse has it.

Huh? Ok, I didn't yet use eclipse that much with two apps,
but I also
didn't use Eclipse much with multiple mainwindows because it
doesn't
work very well.

So if I have 2 apps and I started to debug each in its
"own" mainwindow,
when I'm currently in mainwindow 1 and app2 (which was
started in
mainwindow2) halts on a breakpoint, then Eclipse jumps to
the breakpoint
in the framestack window and opens the corresponding file in
the 2nd
mainwindow? Not the currently active one?

> And I suspect that the need to know which mainwindow
we're running in
> is not the biggest complexity here .

Thats already there, the uicontroller can tell you which
mainwindow is
active. But thats not enough yet. You need to store that
when starting
the app. And then a simple openDocument() call to open a
file won't be
enough anymore, we have to provide an API to tell it which
mainwindow to
open it in. That somewhat violates the MVC concept, with
the
documentcontroller being the model.

> > I don't think we can or should add this
complexity. And just looking at
> > the framestack/variables/memory of both apps at
the same time shouldn't
> > be a problem with the current implementation: One
Debug Mainwindow and
> > one Code mainwindow, then switch from Code to
Debug and select the
> > "other" app in there (i.e. the one thats
not currently debugged in the
> > debug mainwindow). So yes, named areas that store
their layout are fine,
> > but I don't see the need for an identifier.
> 
> Well, assume you're only coding, and you have two main
windows. Naturally,
> the windows shows different views -- else you would not
need two main windows.
> I think it's natural to expect that the state of both
main windows is saved,
> so we need to save both areas.

Yeah, sure, no doubt about that.

> Ok, now suppose there's a menu for switching
"perspectives", with two
> entries -- "Coding" and "Debug".
You manually switch first mainwindow to "Debug",
> debug something, and switch back to coding. I'd expect
to see whatever
> state was before switch to "Debug" -- not
whatever is shown in the second window.
> And that means that "Coding" must mean
different things in the first and the second
> mainwindow.

Aah, ok. I missed that use-case. Though I'd probably use the
split-view
feature to look at another or 2 other files while coding in
one, instead
of cloning the whole mainwindow.

Andreas

-- 
You have no real enemies.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 16 December 2007 08:33:54 Andreas Pakulat wrote:
> On 16.12.07 00:30:28, Vladimir Prus wrote:
> > On Saturday 15 December 2007 23:24:31 Andreas
Pakulat wrote:
> > > On 15.12.07 12:24:41, Vladimir Prus wrote:
> > > > 2. When using a single main window, I
want to have named "areas" and be able
> > > > to switch between them, and have
KDevelop remember the set of tools/documents
> > > > in each. Two examples are
"coding" and "debug" areas. Ok, now for
the case
> > > > of multiple windows, I want to
> > > > 
> > > >    - Be able to switch between
"coding" and "debug" areas in each
window.
> > > >    - Have "debug" area in
different windows to be independent. Say, I
> > > >    can debug two communication
applications together, and different set of view
> > > >    make sense for each.
> > > > 
> > > > In order to implement this, I think that
area should keep both name and mainwindow's
> > > > number, and that
UiController::switchToArea should accept both area name and
window
> > > > number. Or maybe even better --
switchToArea should accept a MainWindow* parameter.
> > > > If null, new mainwindow is created. If
not null, an named area associated with that
> > > > main window is found and the mainwindow
switches to it.
> > > 
> > > Uhm, this gets really complicated, you know.
I mean the use-case you
> > > have, because the debugger needs to know in
which mainwindow it is run
> > > and which app it is supposed to debug in this
mainwindow. Else both
> > > debug mainwindows will at some point show the
same information, when one
> > > of the apps hits a breakpoint. There's only 1
debugger plugin running,
> > > but it has to manage multiple apps that are
being debugged.
> > 
> > Well, ultimately yes -- debugger has to manage
several apps. Not KDevelop 4.0,
> > probably, but why not?
> 
> So being able to debug multiple apps in the same
kdevelop instance is
> something that won't come with KDevelop4.0? I think
thats a bad idea. If
> I just misunderstood and you meant the above example of
the debugger
> knowing in which mainwindow which app is being debugged
is something for
> 4.x (x>0) then yes I agree.

Well, I actually did not planned to implement debugging
multiple apps 
in 4.0. But who knows.

> 
> > Eclipse has it.
> 
> Huh? Ok, I didn't yet use eclipse that much with two
apps, but I also
> didn't use Eclipse much with multiple mainwindows
because it doesn't
> work very well.

Oh, I've miscommunicated -- I actually meant the ability to
debug
several applications at once.

OTOH, Eclipse does allow to have two debug views open in two
different
mainwindows, debugging different applications.

> So if I have 2 apps and I started to debug each in its
"own" mainwindow,
> when I'm currently in mainwindow 1 and app2 (which was
started in
> mainwindow2) halts on a breakpoint, then Eclipse jumps
to the breakpoint
> in the framestack window and opens the corresponding
file in the 2nd
> mainwindow? Not the currently active one?

Oh, I did not go as far as to test that. But given that two
different
windows can debug different applications, I don't see why
that won't work.

> > And I suspect that the need to know which
mainwindow we're running in
> > is not the biggest complexity here .
> 
> Thats already there, the uicontroller can tell you
which mainwindow is
> active. But thats not enough yet. You need to store
that when starting
> the app. And then a simple openDocument() call to open
a file won't be
> enough anymore, we have to provide an API to tell it
which mainwindow to
> open it in. That somewhat violates the MVC concept,
with the
> documentcontroller being the model.

Probably not very much, but I'll need to think more.

> > > I don't think we can or should add this
complexity. And just looking at
> > > the framestack/variables/memory of both apps
at the same time shouldn't
> > > be a problem with the current implementation:
One Debug Mainwindow and
> > > one Code mainwindow, then switch from Code to
Debug and select the
> > > "other" app in there (i.e. the one
thats not currently debugged in the
> > > debug mainwindow). So yes, named areas that
store their layout are fine,
> > > but I don't see the need for an identifier.
> > 
> > Well, assume you're only coding, and you have two
main windows. Naturally,
> > the windows shows different views -- else you
would not need two main windows.
> > I think it's natural to expect that the state of
both main windows is saved,
> > so we need to save both areas.
> 
> Yeah, sure, no doubt about that.
> 
> > Ok, now suppose there's a menu for switching
"perspectives", with two
> > entries -- "Coding" and
"Debug". You manually switch first mainwindow to
"Debug",
> > debug something, and switch back to coding. I'd
expect to see whatever
> > state was before switch to "Debug" --
not whatever is shown in the second window.
> > And that means that "Coding" must mean
different things in the first and the second
> > mainwindow.
> 
> Aah, ok. I missed that use-case. Though I'd probably
use the split-view
> feature to look at another or 2 other files while
coding in one, instead
> of cloning the whole mainwindow.

Ok, good. I'll try to implement something, then.

- Volodya

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Saturday 15 December 2007 23:30:28 Vladimir Prus wrote:
> Ok, now suppose there's a menu for switching
"perspectives", with two
> entries -- "Coding" and "Debug".
You manually switch first mainwindow to
> "Debug", debug something, and switch back to
coding. I'd expect to see
> whatever state was before switch to "Debug"
-- not whatever is shown in the
> second window. And that means that "Coding"
must mean different things in
> the first and the second mainwindow.

When you open the second mainwindow, you create the
"clone" of an area. While 
it can be still seen as "coding" by user,
internally it will be another area.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 19 December 2007 22:23:37 Alexander Dymo
wrote:
> On Saturday 15 December 2007 23:30:28 Vladimir Prus
wrote:
> > Ok, now suppose there's a menu for switching
"perspectives", with two
> > entries -- "Coding" and
"Debug". You manually switch first mainwindow to
> > "Debug", debug something, and switch
back to coding. I'd expect to see
> > whatever state was before switch to
"Debug" -- not whatever is shown in the
> > second window. And that means that
"Coding" must mean different things in
> > the first and the second mainwindow.
> 
> When you open the second mainwindow, you create the
"clone" of an area. While 
> it can be still seen as "coding" by user,
internally it will be another area.

Of course. This means we do need 
"switch to area named 'Coding' inside *this*
mainwindow" feature in code, which is
not present currently.

- Volodya

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel