[scribus-dev] Editable Master Pages

[Louis Desjardins]

2008/8/2 "Christoph Schäfer" <christoph-schaefer at gmx.de>

> In reply to Andreas:
>
> >
> > 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.
>
> 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.


> >
> > 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.
>
> If properly documented, I think this would be rather intuitive, because it
> simply extends the concept of layers (see my reply to Greg).


Paradoxal. Intuitive means one can figure out the feature by oneself,
without reading the manual. At least for experienced users.

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.


>
>
> >
> > 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
>
> 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.
>
>
>
> 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).
>
> 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?
>
> 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.
>
> Would recording it in the Action History not be enough?
>
> 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?).
>
> I predict a lot of confusion if we do this ;)
>
> 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.
>
> Yeah, that would be a great extension, but maybe we should resolve the
> basic issues first.
>
> Christoph


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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20080802/26c3fa17/attachment-0001.htm>