[scribus-dev] Editable Master Pages

["Christoph Schäfer"]

> 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! :-)

Well, I'm currently using a web interface, and since I only receive the digest, this is a bit complicated for me at the moment :(

> > 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?

>
> > 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.

>
> > 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.

Agreed. This was just a what-if question. Personally I don't see any need for it either.


>
> > 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* :-)

That was my whole point ;)


> > 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?

> > 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...

Why? It would mean that all MP related operations on a particular page are void. It wouldn't be any different from applying another MP, as we currently do.

>
> > 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

Well, both QXP and ID offer it, so there might be a user who will miss it ;)

> > Which one is preferred, the new style or the local change?
>
> Local changes, unless you use the broom.

How would you use a broom for pages and items ;)

>
> > 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).

Yes, that's my major concern. Louis raised one of the core questions here, namely: the user has to know "where" he is. That's already a problem with a direct approach, but with styles I really think many people will be lost.

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

But that's not everything we want, right?

> 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.

Well, in a sense it already is, since one can use layers in master pages.

> And in MP edit mode, it should edit that MP only, not some regular
> pages to be specified when leaving edit mode.

Yes, that was just an idea I adopted from the "Apply Master Pages" feature. Think of it as an extra, nothing really important.

> 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.

Agreed. It's better to keep things apart.

>
> > 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.

Wouldn't that be more efficient with text frames on a regular page and your suggested "roles"? I really think the "role model", so to speak, has a lot of potential here, without the necessity to extend master pages. But if the price (coding time, usability etc.) is lower with your master pages, I'm all for it. 

Cheers

Christoph



-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer