[scribus-dev] Editable Master Pages

[Andreas Vox]

Am 07.08.2008 um 15:56 schrieb Christoph Schäfer:

> OK, the quotations have become a bit extensive, so let me try to  
> start from scratch,

Good idea. But getting the quotation mechanism to work in your mail  
program would also be great! :-)

> because the discussion seems to dissolve the concept of master pages.
>
> What do we want to achieve (or more precisely what do our users  
> want to achieve)?
>
> 1) Editing objects on master pages for one or more particular  
> regular pages.
>
Changing MP objects locally on the regular page goes somewhat against  
the spirit of master pages, so this will be discussed some more I  
think. It might be worthwhile to have restrictions
on how MP objects can be cahnged, eg. just filling in content instead  
of changing size / shape / position / color / whatever.

> 2) Editing means just that: everything they could do to with an  
> object on a regular page. This includes deleting an item or moving  
> it to the regular page (which is the same as desynchronising).

See above. Desynchronized MP objects can be a burden: quick changes  
sometimes hamper the possibility to edit the document in the long  
run. After all the main purpose of master pages is to give a set of  
regular pages a consistent look.

>
> 3) Perhaps a user would want to add an item from a regular page to  
> a range of master pages or a static master page. I don't know why  
> someone would do this, but you never know what users come up with.
>

That's a non-issue to me. If users want that, they can copy/paste the  
item in question. No need to ad special functionality.


> There's nothing more we need to address.

Uh, what about more than one master page for a regular page, or  
master pages for master pages? Ok, I agree, we don't have to address  
that *now* :-)

> So there are only a few questions: How can a user access an item  
> (or more) on a master page quickly without having to jump through  
> many loops? How will the changes be applied? For the second  
> question, there are 3 possible choices: 1) Edit the content on the  
> master page -> changes will apply to all master pages

of course

> 2) Apply the changes locally but keep the item otherwise in sync  
> with the MP (there should be a "refresh mechanism" to override  
> local changes,

as with object styles

> but I think this could be done by applying the MP again in the Page  
> > Apply Master Page dialog).

That's a can of worms once you allow local changes to MP objects...

> 3) Detach the item from the master page and make it a part of the  
> current page (and, perhaps, vice versa).
>
not so nice IMHO

> As for using styles, master pages are already styles in a sense:  
> change a style and all text/lines with that style will change,  
> change one MP, and all pages that use the MP will change. I agree  
> that one could use the style "mechanism" like overriding styles  
> with local formatting, but this has a serious drawback, which is  
> already hurting us: if a paragraph style is being changed or  
> another style is applied to the text, what happens to the local  
> changes?
> Which one is preferred, the new style or the local change?

Local changes, unless you use the broom.

> There is no easy answer, and that's why I don't think the style  
> mechanism should be used. It just gets in the way for quick changes  
> and is probably overhead.
>

That problem is independent of the style mechanism: once you have  
local changes / desynched MP objects, applying the same MP or another  
will raise that same question.
Using the style mechanism might have a slight computational  
(unnoticable) overhead, but the advantage is that there's only one  
concept to understand (even if it's admittably complicated).

The only way to avoid this problem is to disallow local changes to MP  
objects (except for filling in content)

> Louis' idea of using the context menu is correct, but we should  
> keep in mind that it's already quite bloated. My purpose was to use  
> existing features that are already there, ie. layers. Detaching  
> objects from a master page by moving them to a document layer is  
> quite easy. Frankly, I don't care if DTP people did fine without  
> layers for years. The technology is available in Scribus, it works  
> reliably, and it's known to our users (and will be fully documented  
> in the manual). Why not use it to save time and provide something  
> easier than InDesign's insanely complex way? It would take four  
> mouse clicks to detach an object ort to delete it (1. switch to the  
> editing mode, 2. right-click, then 3. in the context menu Send to  
> Layer/Delete, 4. switch off editing mode). The same goes for  
> editing items: quickly switch to the editing mode for master pages,  
> edit the item, then decide if the changes will be applied to the  
> current page, to the master page itself or a range of pages that  
> use the master page. Aside from the editing itself, it'd take four  
> mouse clicks (1. enter editing mode with a click on a button, then  
> edit, 2. click the button again, which brings up a dialog to choose  
> from, 3. make your choice and then 4. OK). I can't think of  
> anything easier.
>
Frankly I don't like that approach. I don't want to tie the MP  
concept with the layers concept.
And in MP edit mode, it should edit that MP only, not some regular  
pages to be specified when leaving edit mode. In fact, once MPs are  
listed with regular pages, there wouldn't be a separate MP edit mode  
any more: the user selects a page - regular or master - and edits it.  
Internally Scribus might do something different, and some options  
might not be available for one kind of page or the other, but to the  
user it should not feel like mode switching.


> The linking of text frames is IMNSHO totally unrelated to editable  
> master pages.

Not totally unrelated. Once you have editable textframes on master  
pages, you have to find a way how to link them. Manually linking them  
after applying the page (and re-linking if you apply another  
masterpage) would be a nightmare.

/Andreas