jkeiser's mozilla blog

Presentation Fever

In the last couple of weeks, I have had a series of epiphanies about layout. (To the point where I mostly understand it now.) Continuing work on the printing rewrite is largely responsible for this. Here's a few of the things I've been thinking about that I think we can reasonably change.

Top-Level Objects

I'm working on a document on the top-level objects in Mozilla, and it seems to me that there are really only 4 classes of top-level object involved with the document: document, shell (scripting/docshell), presentation, and device/window. Furthermore ,a limited amount of stuff you want to do with these top-level objects as an embedder. We do not support enough of this stuff (for example, you can't easily right now build a client that starts up Gecko and prints). It would be nice, for example, to be able to quickly tell Mozilla these things:

(1) create a window/device.
(2) create a shell hooked to that window (along with all surrounding scripting and stuff)
(3) embed document into shell (or load a document into the shell)
(4) create a presentation for document aimed at that window
(5) create another presentation for document aimed at a printer or even another window

There should never be any more steps than this, but each step in this is currently arcane and the parts of it are spread-out ... there is no way to just create a presentation for a document, for instance, though I've written a method for that that I plan to check in soon. The above set of steps should be something like this for an embedder (some may end up taking a couple of steps to create services and whatnot, but they should all essentially be one step):

// Create main window to display document
nsCOMPtr<nsIWidget> widget = CreateRenderingWidget(800, 600, otherWindow);
nsCOMPtr<nsIDocShell> shell = CreateShell(widget);
shell->EmbedDocument(document);
nsCOMPtr<nsIPresShell> presentation = CreatePresentation(widget);
// Display the document in another window
nsCOMPtr<nsIWidget> widget = CreateRenderingWidget(320, 200, otherWindow);
nsCOMPtr<nsIPresShell> presentation = CreatePresentation(widget);

That's all she wrote. You have taken your webpage from nowhere to the screen, twice. You need to do things with your widget to make it visible and move it where you want within your app, but that's it.

Most of these steps are pretty much there or close to happening; I want to see us get the rest of the way so we're cleaner and work better with alternate media (which is the reason I want a stronger separation of the presentation from the shell). DocumentViewer is the one doing much of the presentation-creation job today, because someone has to catch the right part of the document load where you realize what kind of presentation you want.

Doing this would allow you to more easily write various clients, as well as do things internally like move documents from one window or tab to another.

Presentations

This begs the question of whether we should have multiple simultaneous presentations for a document at all, which some people kind of want us not to. I think our reflow model and architecture is too poorly understood to make a go at that, and we have to fix that first before we even consider it. In the meantime, we should split the presentation out and acknowledge that for the time being we currently do support multiple simultaneous presentations (which I can confirm that we do).

It's multiple active presentations that we really don't support--presentations that you can click on and interact with, etc.--and probably never will. DOM just doesn't support it. For example, if you click on an event in presentation A you only want the event to affect handlers and such in presentation A (which is what you'd want, for example, in a Composer with a browser view side by side). This means a whole mechanism where all event handlers must be registered only with a particular presentation. And if you solve that problem, then when JS does stuff like click(), who do you contact? I don't think DOM can really support multiple active presentations.

Box Reflow Model

Oh, and recently hyatt convinced me that we can indeed remove the performance hurdles to using a box-like reflow model, so I'm all for it. Let's make a MaxElementWidth() function first and stop calling into reflow to figure that crap out.

Posted by jkeiser at April 11, 2003 4:12 PM