[scribus-dev] Editable Master Pages

[Louis Desjardins]

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

> OK, the quotations have become a bit extensive, so let me try to start from
> scratch, because the discussion seems to dissolve the concept of master
> pages.


I was under the exact opposite impression...

>
> What do we want to achieve (or more precisely what do our users want to
> achieve)?


Yes. Please tell us.

>
> 1) Editing objects on master pages for one or more particular regular
> pages.
>
> 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).
>
> 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.
>
> There's nothing more we need to address.


Disagree. Please read below. Plus, I think that this approach to the
discussion is closing it and I personnally have a problem with this. How can
you say there's nothing more to address while it is obvious there is more to
address from the discussion? So, not only do I disagree with the idea you
express here, but also with the way you express it.

Frankly, it really takes away the fun of this discussion and I am sorry to
insist on that but I think at some point someone has to say that. That might
be your way, but I dislike it to a point that I am going to retire from this
discussion if you pursue in that direction. You should learn to listen, that
is the least I can tell you now. When someone is ready to propose something,
he must be ready to hear what the others have to say. Obviously, you want us
to praise your idea and that's just about it. If you think I sound rude now,
trust me, I do. I am completely disappointed by such a stubborn attitude.

Now, please read below. There is more.


> So there are only a few questions: How can a user access an item (or more)
> on a master page quickly without having to jump through many loops? How will
> the changes be applied? For the second question, there are 3 possible
> choices: 1) Edit the content on the master page -> changes will apply to all
> master pages 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, but I think this could be done by applying the MP again in the Page
> > Apply Master Page dialog). 3) Detach the item from the master page and
> make it a part of the current page (and, perhaps, vice versa).
>
> As for using styles, master pages are already styles in a sense: change a
> style and all text/lines with that style will change, change one MP, and all
> pages that use the MP will change. I agree that one could use the style
> "mechanism" like overriding styles with local formatting, but this has a
> serious drawback, which is already hurting us: if a paragraph style is being
> changed or another style is applied to the text, what happens to the local
> changes?


Well, for paragraph styles, the most common change is enriching text.
Nothing to hurt. I agree however that changes to a MP could be far less
trivial and thus it may not be advisable to have this Style+ I was thinking
about. But before throwing the idea away, I would still consider it and give
it a second thought. After all, it is up to the user to determine what he
wants on the MP. He'll see right away if the change made is in contradiction
with his own layout. So, in fact, I see no real problem to the Style
approach.

Which one is preferred, the new style or the local change?


Good question. It could well be an option. And if it isn't, I am still
incline to think the Style+ way is fine.


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


Could be. We are precisely discussing the case. So far, I think we need more
thoughts and case scenarios.

>
> Louis' idea of using the context menu is correct, but we should keep in
> mind that it's already quite bloated.


A context menu can be less bloated in a given context. We can strip it down
in the MP context, for instance.


> My purpose was to use existing features that are already there, ie. layers.


Yes. You made that point clear. I think we all got that by now.

Detaching objects from a master page by moving them to a document layer is
> quite easy. Frankly, I don't care if DTP people did fine without layers for
> years. The technology is available in Scribus, it works reliably, and it's
> known to our users (and will be fully documented in the manual). Why not use
> it to save time and provide something easier than InDesign's insanely
> complex way?


It would be great to explain what works and what doesn't in the "insanely
complex way" of ID.

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.
>
> The linking of text frames is IMNSHO totally unrelated to editable master
> pages.


Then, tell us why you think so. Other than that, it's only an opinion.

This is again a demonstration of your difficulty to listen to what others
have to say. There are tons of case scenarios where linking is important at
MP level and where it does save lots of time. The importance of this will
also increase as Scribus text handling capabilities get better. Text
formatting for one thing could be done in one single "formatting" document
(just like galleys used to be) and then this formatted text could be copied
and pasted to an entirely structured and linked empty "layout" document.
Being able to link text frame in the MP can save hours of work, depending on
the complexity of the document. Catalogs, for one piece of work, with lots
of text levels and formatting can be done in days instead of weeks. Having
said that, you can of course maintain your "not so humble opinion". This is
up to you, of course.

To be honest, I think it is very harmful to the discussion to come up
strongly with your "not so humble opinion" in a case where it is obvious you
seem to miss some valuable information.


> This should be discussed in a separate thread.


Yes, please, continue showing us the way. How do discuss, what to discuss.
What to do. What to priorize. What is good and what is wrong. Tell us,
Master.

Louis


> Andreas' idea of roles is probably the way to go, but before that can be
> introduced, the linking of text frames should be fixed and brought on par
> with ID. That will be enough work, I think, for the near future. Andreas has
> quite a few great ideas here, IIRC. In this context, we probably also need
> to discuss changes to the page numbering, as we'd need to be able to have
> parallel numbering schemes for facing pages with different languages. I
> think there's already a bug report for this.
>
> Regards
>
> Christoph
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20080807/212e93f0/attachment.htm>