[scribus-dev] Editable Master Pages

[Andreas Vox]

Louis,

did you have a bad day? I also think there's a lot left which has to  
be discussed, but I wouldn't take Christoph's opinion so personal. He  
thinks he has a simple solution, we have to convince him that it's  
not so easy.
And you have to take into account Christoph's long-lasting internet  
deprivation! ;-)

/Andreas

Am 07.08.2008 um 17:19 schrieb 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
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20080807/620f2d2d/attachment-0001.htm>