Future of Master Pages

Editing objects on master pages for one or more particular regular pages.
This table is still empty and will be until a working agreement is reached about the scenarios and proposals to solve them.

Going the KISS way (the "Library" approach)
The whole discussion on the mailing list has taught me, that handling dynamic content in a master page is a difficult matter which hasn't been done right in any DTP software.

This proposal tries to figure out, how this goal can be achieved using -- mostly -- features which are already implemented in scribus (following the rule to Keep It Simple... Sir).

In short:


 * The master page contain elements which are exactly the same on every page based on it
 * The master page can contain variable content like the page numbers
 * The library contains elements which can be modified after having been inserted into the document
 * It should be easy to add the library elements at a fixed position
 * The elements inserted are independent from one another
 * Those elements are not updated if the library item changes
 * There should be a way to apply changes and formatting to all similar elements (based on the way filters are created and applied to emails).

Features and limits of the Master Pages
The master pages are basically ok as they are and will contain elements which are identical on every page based on them.

There could be some enhancements:
 * There may be some more variables like the page numbers.
 * There may be several "versions" of a master page which get applied when a predefined condition is met: first page, left page, right page, last page.

Role of the library and enhancements needed
The elements inserted from the library aren't linked to the "original" element in the library: if the original gets changed, the element remains in the state it was as it has been inserted or as it has become after being modified in the context of the page it has been inserted into.

In order to be able to use the library as a replacement for more dynamic master pages, a new lock status has to be added: "Lock position". If its position is locked, the object will be inserted from the library will have exactly the same position as it had at the moment when it has been added to the library.

I propose to leave only one lock button in the Properties Palette:
 * which will full lock/unlock the frame if clicked
 * and -- if the mouse is kept clicked -- shows a context menu with the following items (checked / unchecked):
 * lock size
 * lock position
 * lock content



Notice: Personally, I'd prefere not to have that small triangle. It's acceptable here since it does what a basic use wants when clicking on the button: lock and unlock (only the extra functionality is hidden).

There could be some further enhancements:
 * It should be possible to edit the library items in a virtual page (opened by right clicking on the element in the library, without inserting it into a page first and recopying it into the library afterwards).

Tagging, Selecting and Batch Processing
A tag system could be built on the the base of the attributes editor. And every frame could get be assigned a set ot tags.

This could be implemented as a plugin.

A separate plugin implements a way to select and batch process frames based on their tags and some other characteristics. This plugin will work in a similar way as the filter editors in the mail programs:



Another KISS way (the "prototype" approach)
Forget automatic synching for the time being (according to Louis the confusing part anyway)

Master pages contain two kind of items: background items (that's the kind we have now) and prototype items. When applying a masterpage to a regular page, copies of the prototype items are placed on the regular page with size and position initially locked. Those copies can be edited in a normal way.

When a regular page is displayed, Scribus will render only the background objects from the masterpage and then the objects from the regular page (normal ones and the copies of prototypes).

In effect the objects based on prototypes are automatically detached. One could provide an option to manually synch them with their prototypes, either on a per-object basis or when the masterpage is re-applied.

In a later Scribus version we could use the style-based approach to keep objects in synch with their prototypes (manually synch would correspond to the broom function of styles)