UI/area questions

Vladimir Prus ghost at cs.msu.su
Wed Dec 19 15:00:21 UTC 2007


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




More information about the KDevelop-devel mailing list