[scribus-dev] Editable master pages

[Andreas Vox]

Am 28.07.2008 um 19:57 schrieb Louis Desjardins:

> 2008/7/28 "Christoph Schäfer" <christoph-schaefer at gmx.de>:
> Hi guys,
>
> Hi Christoph,
>
> I have copied below the content of your attached file because I  
> think it's going to be easier for anyone entering this discussion  
> to add their comments.
> ...
> Editable Items on Master Page – Proposal for the User Interface
>
>
> 1. Editable items on master pages is certainly one of the most  
> requested features. Here I want to discuss how it can be done in a  
> user-friendly way. Both QXP and ID offer this feature, but I don't  
> think Scribus should follow their path here, as the feature seems  
> to have been implemented with no sane or a masochistic user in  
> mind. I really think this important feature can be implemented much  
> more transparent to the user (literally, as you can read below).
>
>
> 2. The first thing that can be done is not directly related, and  
> it's just a tweak or two to the UI. Its purpose is to make access  
> to master pages easier. Two tweaks are required: First, list all  
> master pages in the page list, so that the master page can be  
> directly edited by selecting it in the list. This would have the  
> same effect as selecting the master page in the Document Outline.  
> Second, it would be nice to have a button beside the page list that  
> would open the master page of the currently selected page for  
> editing. Again, technically the same as opening in the document  
> outline, except that the user doesn't have to find out which master  
> page is used for the current page.
>

Yes, that sounds very sensible.

>
> 3. When it comes to editing an item only on the current page, there  
> should be a second button to switch on the editing mode for master  
> page items on the currently selected page. There should also be a  
> spin box to set the opacity of the actual page content, so that  
> users can check how changes to the master page will affect the  
> layout as a whole. Default should be 0%, so that the content is  
> invisible.
>

I don't follow your opacity explanation there.

>
> 4. To disconnect an item from the master page and use it only on  
> the current page, one could use the "Send to Layer" feature: Each  
> document has at least one layer, so that sending the item to  
> "Background" (or any other layer in the current document) should be  
> enough to remove the item from the master page.
>

That's unintuitive I think.

>
> 5. Once the editing is finished, the user would have to click on  
> the edit button in the status bar again. Scribus would then bring  
> up a dialog similar to the current "Apply Master Page" dialog.
> Options:
> a) Apply Changes to the Current Page
> b) Apply Changes to the Master Page
> c) Apply to all Odd Pages (ie. those that use the master page)
> d) Apply to all Even Pages (ie. those that use the master page)
> e) Apply to the following Pages: (ie. those that use the master  
> page, single pages and range)
>

Too complicated IMHO

> 6. This would be consistent with many other Scribus dialogs, and it  
> would also be much easier than in InDesign. It would also require a  
> minimum of mouse clicks: one click to enter the editing mode for  
> items on a page, two clicks to confirm the changes. Plus, it's also  
> quite flexible.
>
> Comments are welcome.


Ok, let me throw in my thoughts:


"From object styles to master objects"


On our roadmap we have the extension of the current inheritable style  
system from char/paragraph styles to line styles, table styles, cell  
styles, frame styles, ... to object styles.

A style is just a collection of settings, where each setting can be  
set or not set. If a setting is not set, it's inherited from the  
surrounding element (char settings from the paragraph style,  
paragraph settings from the document).

That's the situation without named styles. When the "based on" field  
contains the name of a style, undefined settings are taken from that  
style instead of from the surrounding element.

Ok, so let's say we have object styles which describe all settings of  
a pageitem, including position (normally we wouldn't want that in a  
style, but read on).

Now, instead of using a named object style for an object, we could  
also change the masterpage mechanism such that page items have a  
"based on" property which points to the corresponding master page  
item. Those page items would be fully editable locally. Changing the  
corresponding master page item would automatically change the  
settings of the descendant page items, unless they were redefined  
locally. Similar to the "Broom" Button for paragraph styles there  
would be an option to reset all settings to the masterpage item's  
defaults.

Applying a masterpage to a page would mean creating additional  
objects on the page which are based on the corresponding master page  
items. Those items would be locked by default, so editing a  
masterpage item locally means unlocking that item first. There should  
be another lock mode which fixes all settings except for content  
(text or images).

Deleting such an item would remove the item just  from this page.  
There should be an option to recreate items which were deleted that way.

Applying another master page would remove the additional objects  
unless they were changed locally. Locally changed objects would stay  
on the page but loose their automatic masterpage connection (or they  
could be deleted anyway, what do you think?).

That mechanism should also work for hierarchical masterpages (is  
there already a feature request for this? :-) ) and for more than one  
masterpage per page. Come to think about it,
it's also very similar to Inkscape's clone objects.

/Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20080731/b5de9710/attachment.htm>