<div dir="ltr">2008/8/2 "Christoph Schäfer" <span dir="ltr"><<a href="mailto:christoph-schaefer@gmx.de">christoph-schaefer@gmx.de</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In reply to Andreas:<br>
<br>
><br>
> 3. When it comes to editing an item only on the current page, there<br>
> should be a second button to switch on the editing mode for master<br>
> page items on the currently selected page. There should also be a<br>
> spin box to set the opacity of the actual page content, so that<br>
> users can check how changes to the master page will affect the<br>
> layout as a whole. Default should be 0%, so that the content is<br>
> invisible.<br>
><br>
<br>
I don't follow your opacity explanation there.<br>
<br>
Perhaps it is clearer if you download the PDF file that's attached to the original posting. My idea was to edit a master page while the original page is still visible. The user could set the degree (transparency) of the visibility.</blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
><br>
> 4. To disconnect an item from the master page and use it only on<br>
> the current page, one could use the "Send to Layer" feature: Each<br>
> document has at least one layer, so that sending the item to<br>
> "Background" (or any other layer in the current document) should be<br>
> enough to remove the item from the master page.<br>
><br>
<br>
That's unintuitive I think.<br>
<br>
If properly documented, I think this would be rather intuitive, because it simply extends the concept of layers (see my reply to Greg).</blockquote><div><br>Paradoxal. Intuitive means one can figure out the feature by oneself, without reading the manual. At least for experienced users.<br>
<br>Also, layers may be well used in image editing but in DTP, believe me, they are not. And I doubt this is going to change. People might get the concept rapidly (after all, a layer is a layer and this is easy to catch) but they often don't have a clue about the real use and benefits — and drawbacks, of course, of layers.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
><br>
> 5. Once the editing is finished, the user would have to click on<br>
> the edit button in the status bar again. Scribus would then bring<br>
> up a dialog similar to the current "Apply Master Page" dialog.<br>
> Options:<br>
> a) Apply Changes to the Current Page<br>
> b) Apply Changes to the Master Page<br>
> c) Apply to all Odd Pages (ie. those that use the master page)<br>
> d) Apply to all Even Pages (ie. those that use the master page)<br>
> e) Apply to the following Pages: (ie. those that use the master<br>
> page, single pages and range)<br>
><br>
<br>
Too complicated IMHO<br>
<br>
Again, this is just the extension of an already existing concept, ie, applying master pages to existing pages. In this case it would just be bit different: applying changes to master pages. From experience I know that people learn things easier, when the concepts seem familiar.<br>
<br>
<br>
<br>
Now, instead of using a named object style for an object, we could<br>
also change the masterpage mechanism such that page items have a<br>
"based on" property which points to the corresponding master page<br>
item. Those page items would be fully editable locally. Changing the<br>
corresponding master page item would automatically change the<br>
settings of the descendant page items, unless they were redefined<br>
locally. Similar to the "Broom" Button for paragraph styles there<br>
would be an option to reset all settings to the masterpage item's<br>
defaults.<br>
<br>
Applying a masterpage to a page would mean creating additional<br>
objects on the page which are based on the corresponding master page<br>
items. Those items would be locked by default, so editing a<br>
masterpage item locally means unlocking that item first. There should<br>
be another lock mode which fixes all settings except for content<br>
(text or images).<br>
<br>
Hmm, this seems to have a lot of potential, but how would you go the other way, ie, adding an item from a current page to the master page or a range of them? And is there a way to remove an item from a master page on a real page without deleting the master page?<br>
<br>
Deleting such an item would remove the item just from this page.<br>
There should be an option to recreate items which were deleted that way.<br>
<br>
Would recording it in the Action History not be enough?<br>
<br>
Applying another master page would remove the additional objects<br>
unless they were changed locally. Locally changed objects would stay<br>
on the page but loose their automatic masterpage connection (or they<br>
could be deleted anyway, what do you think?).<br>
<br>
I predict a lot of confusion if we do this ;)<br>
<br>
That mechanism should also work for hierarchical masterpages (is<br>
there already a feature request for this? :-) ) and for more than one<br>
masterpage per page. Come to think about it,<br>
it's also very similar to Inkscape's clone objects.<br>
<br>
Yeah, that would be a great extension, but maybe we should resolve the basic issues first.<br>
<br>
Christoph</blockquote><div><br>Christoph, I have a hard time keeping track of who says what. Can you make sure when you post and answer like this that the chunks you are responding to are clearly identified? — Thanks!<br>
</div></div><br>
</div>