UI/area questions

Hamish Rodda rodda at kde.org
Sat Dec 15 21:44:35 UTC 2007


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20071216/e315f5ec/attachment.sig>


More information about the KDevelop-devel mailing list