[scribus-dev] Editable Master Pages - details for style based approach

[Andreas Vox]

Am 09.08.2008 um 17:20 schrieb Christoph Schäfer:

>>> 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.
>
> Yes, I think this a matter of the degrees. This needs some further  
> discussion. Do you think Scribus should offer a more fine-grained  
> approach, ie. with (customisable?) restrictions/permissions?
>

I think a too fine-grained approach would be too much.

Currently you can lock the position separately. I think we also need  
a lock option that locks anything but the content. Another  
intermediate option might allow additional stuff that covers most  
user's needs (position, size, fill color, visibility, columns, text  
style?)

>>
>>> 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.
>
> Hmm, desnychronised object would simply be regular objects that are  
> no longer connected with their master page, no? Why would regular  
> objects become a problem.
>

Only in so far as you get into problems when you don't work with MPs  
to keep your work consistent. Not a problem per se, but it goes  
against the purpose of MPs.

...
>>> 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
>
> What part of the object style would be related to the status on the  
> master page? Do you mean a special option? Would there be a special  
> object style for items on a master page? I think Louis' idea with  
> setting the status via context menu would be easier and faster. Or  
> maybe there should be both options?
>

Ok, time to elaborate on my styles mechanism:

The way I see objects they can be divided in three parts (item  
paginarum est divisa in partes tres):

  *  Content: either text or image or none
  *  Frame & Shape: this would cover the clipping path, the contour,  
flow-around-options, linestyle and fill color, role, attributes, text  
style, image settings
  *  Object stuff: position, layer, z_Order, links for text chains,  
name, lock status

Named object/frame styles should IMO only affect the properties for  
the Frame/Shape part.
They would basically work just like paragraph styles (allows to set  
object style, local overrides, has broom action to revert to parent  
style). These object/frame styles would contain other styles as  
substyles (eg. paragraphstyle for text, image style for image  
settings, line style for frame, fill style/pattern for background)  
just as paragraph styles contain a character style.

So far this has nothing to do with master pages.

Now imagine a super object style, which contains *all* object  
properties. We wouldn't name those styles, but instead place them as  
objects on a masterpage. When you apply this masterpage, on the  
regular page Scribus creates one object for each master object, and  
sets that master object as parent to the regular object.  
Automatically the regular object would inherit all properties of the  
master object, except for its page affiliation and maybe its name.

That's what I mean with using the style mechanism for master pages.  
Those super object styles would not be edited with the style manager;  
they would be edited as master page objects, just like they are now.  
But they would use the inheritance mechanism to synchronize with the  
masterpage.

Masterpage objects on a regular page would now be regular objects  
which use a super object style. Technically it's possible to override  
locally any setting from the super object style (the masterpage  
object). That's why I would create those items locked when I apply a  
masterpage. Unless they are unlocked, they would behave exactly as  
masterpage items behave now.

Please understand that this is just the technical side of master  
pages. It would allow all possibilities as in InDesign and maybe  
more. The number of clicks might be different, though :-)

The operations needed to edit an MP object would be:

1. editing content works exactly as for regular objects

2. other proerties: (position, size, shape, etc.):
   a) use the context menu on the regular page to unlock the MP object
   b) edit the MP object on the regular page
   c) optionally lock the MP object again.

If the MP object is changed on the master page, the regular object  
will receive all changes except for the properties that where edited  
locally.
The context menu of the regular MP object would have an additional  
"broom option" which would reset all local settings to the default on  
the MP.



>>> Local changes, unless you use the broom.
>
> How would you use a broom for pages and items ;)
>
1) go to cupboard
2) fetch broom
3) go to desktop
4) use broom to clear your desktop from any pages and items
;-)

>>

>> Frankly I don't like that approach. I don't want to tie the MP
>> concept with the layers concept.
>
> Well, in a sense it already is, since one can use layers in master  
> pages.
>

Yes, but is has no meaning for MPs, it's orthogonal. I want layers to  
work independently of MPs.
I think ID does is right: if you use layers on the MP, the MP items  
of that layer get sorted just beneath the regular page items of the  
same layer.

So you have layers on regular pages, you have layers on MPs, and  
applying a MP with layers just stacks the items in sequence:
MP items layer 0, regular items layer 0, MP items layer 1, regular  
items layer 1, ...


/Andreas