On Mon, 2008-03-31 at 04:41 -0400, bulia byak wrote:
- Reuse the Layers dialog for displaying and switching these page
containers as well, making them part of the overall layers tree displayed in that dialog. In this way, each page may have its own subtree of layers, but there may be shared layers that show up on all pages, stored in master pages or in the content before the pageSet (which is also treated as a background master page). Of course the Layers dialog will have to treat such page-layers in a special way, namely:
-- display them differently (font, color, autonumbering)
-- enforce that only one of the sibling pages is visible at a time: as soon as the user switches to a page and makes it visible (perhaps for pages, we can implement "clicking on name makes visible"), all other pages are hidden, using the standard CSS visibility property as is done for layers
-- when a page gets visible, its nearest preceding masterpage also gets visible, all previous masterpages get hidden (as per the SVG Print spec)
- In addition to Layers dialog, we'll also need a small page flipper
in the statusbar, next to the quick layer selector, hidden for non-multipage documents; the quick layer selector should perhaps be limited to the layers of the current page and the currently active masterpage only.
- Add commands like New page, Duplicate page, Delete page, etc.
This sounds like a fairly decent UI approach... and also could lend itself to two other main usage. Those are animation and icons.
Animation could map 'frame' to 'page', but we do need to keep in mind that animations can be time-based as much as they are frame-based. Frame-based is the easy case, but time-based is the more desirable case for the end users.
Icons can map versions to 'page'. So 16x16 4-bit would be one 'page' and 32x32 8-bit would be a second 'page' and 32x32 32-bit would be a third 'page'
I think the internals should be set up to support those three purposes in a common way, but then the externals might have some visible variation. So 'multipage' would appear noticeably different than 'icons mode' yet still would be consistent with each other.
Also... looking at the end-user work view as possibly different than the internals would allow us to adjust to changes in SVG print a little easier. We'd just need to account for changes in SVG print to impact the internals the same way that changes from multipage to multi-image icon does. (That is, abstract what might change in a common way, and split it apart from the aspects that will remain constant)