UI/area questions

[Vladimir Prus]

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