UI/area questions

[Andreas Pakulat]

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.