UI/area questions

[Andreas Pakulat]

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.