Open Impress, select View->Master->Slide Master from the menu. Try to copy the master page on your left, in the slide sorter - and see it fail.
It's called on Paste.
555 LoC – refactor it, add a unit test in sd/qa/unit, find & separate all ~6 use cases, and fix the style/name merging.
Deteted "Easyhack" from summary
*** Bug 41573 has been marked as a duplicate of this bug. ***
*** Bug 51551 has been marked as a duplicate of this bug. ***
Are you still looking into this. Otherwise I'll look into this.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
I have started working on the bug. I may need help for adding a unit test
@Rishabh - going to assign this to you since you said you've started. If this changes please set it back to NEW. Thanks!
Migrating Whiteboard tags to Keywords: (EasyHack SkillCpp)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
Still open after three years :-/
1. Save presentation and make a copy of the file.
2. Change the name of one (or more) master page(s).
3. If not already the case, apply the changed master page(s each) to at least one normal page.
4. Open the original file.
5. Copy one of the normal pages with the changed master page(s) applied to the original presentation.
6. Now there should be a copy of that master with the changed name.
Thanks very much for the workaround.
By the way:
It's also not possible to change the order of master pages. There is no actual need for this in creating a presentation. But it may be convenient to be able to change the order.
E.g. putting the master pages into the order, by which they are used in the presentation pages.
And I don't really see a reason why the order isn't adjustable!?
Added "needsUXEval" – there seem to be several related bugs, all concerning the missing function/an UI for it, but UX did not seem to be involved in any of them.
*** Bug 85966 has been marked as a duplicate of this bug. ***
So we need a solution to both possibilities that users use to duplicate a slide - copy (.uno:Copy) & paste (.uno:Paste) and duplicate (.uno:DuplicatePage) - both of which are disabled in master slide mode.
I would assume creating a .uno:DuplicateMasterPage command to work in master slide view should be the priority, as the uno command would be accessible in the master view toolbar, as well as the slides pane context menu (bug 87669).
As suggested in comment 15 the best solution from the UX POV is to have the same interaction as on normal slides. Meaning right click offers Copy (and paste) as well as Duplicate.
The menu contains today New/Duplicate/Delete Slide and New/Delete Master. Since we switch the context it's okay to change the menu and hide slide entries or master (btw. New Master in Normal mode adds another slide and not a master, the same is true for delete).
Regarding the toolbar users expect copy and paste to work (copy is enabled today in master mode but not functional). We also have the Insert toolbar which provides a New (slide) function. This one could remain for normal slides.
Putting all together the recommendation is to make the copy/paste and duplicate function for slides working on master too. Either with new .uno commands or by changing label and tooltips.
Removing UX, but we should take a look when the implementation has started.
*** Bug 113407 has been marked as a duplicate of this bug. ***
*** Bug 87669 has been marked as a duplicate of this bug. ***
*** Bug 115006 has been marked as a duplicate of this bug. ***
*** Bug 115678 has been marked as a duplicate of this bug. ***
Just came across this issue, really would be nice to have it fixed
This is still high priority from my perspective
(In reply to Steve from comment #21)
> Just came across this issue, really would be nice to have it fixed
(In reply to samtuke from comment #22)
> This is still high priority from my perspective
Keywords and initial description give a hint ;)
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assign it back to yourself if you're still working on this.
Hi, I'll work on this bug.
*** Bug 142516 has been marked as a duplicate of this bug. ***
*** Bug 147476 has been marked as a duplicate of this bug. ***
So, Quan, have you had time to devote to this?
Also, note I filed the related bug 149342 about duplicating masters.
Re-evaluating the EasyHack in 2022
This issue is still relevant. The master slides are not copy-able in the slide sorter.
This copy is possible in MS PowerPoint.
There is a some 'clever' but infuriating behaviour hiding behind this bug. Master slides seem to carry some kind of unique ID code with them, to help reformatting of slides when they are being restyled.
1. Create new ('original') ODP
2. modify the *master* slide by placing a text box "TEST" on it, close the master.
3. Create a second ('new') ODP
3. copy the slide from the first ODP to the second ODP
Result: the master-slide text "TEST" does not appear in the copied slide. This is because the master slide is being recognised as "equivalent" in both cases, and the modifications in the original ODP are being dropped when the slide is copied to the new ODP.
Expected result: perhaps it would be expected to be asked if (1) the existing master slide used (2) the new master used to replace the old master, or (3) a duplicate master added, so that both slides can look just as they were before.
I thought it might be possible to hack the "copy master" behaviour by tweaking the name field in the styles.xml file embedded inside original.odp. But so far I couldn't figure it out. How can I convince Impress to think that the master slide in original.odp is NOT the same as the master slide in new.odp?
Copying styled slides therefore has some very strange behaviour that depends on the exact way that the masters were created.
If a single slide is copied from an original ODP to a new ODP, then its master slide edited, then the slide is copied back top the original ODP, the modified master does not overwrite the master in the original ODP.
It would appear that there is a unid UD
its master modified, then copied back to the original
There seem to be various issues with the support for master slides in Impress -- certain attempts to edit text styles don't get kept, and it's all a bit mystifying, especially when starting with PPTX templates that have been generated in a recent Powerpoint version.
What seems to work well is creating the master slides again from scratch! But this is very tedious, because of the current bug. Having set up the font for titles and outline text, one cannot copy a master slide in order to create the different 'variants' that a complete template requires.
That's the use-case for this bug -- being able to duplicate master slides makes it much easier to develop a set of master slides with a common theme/styling.
People are trying all sorts of desperate hacks out there!
Adding the 'duplicate' feature would be enough, in my mind, if that's easier. Copy and paste is not necessary, since one can always copy and slide (inheriting whatever master) instead, and that works fine between different .odp documents.
Modifying a master by copying it to another sheet then copying it back doesn't seem to work. It seems that there is some sort of unique identifer attached to each master slide design... is that true? Copying
sorry, a bunch of text there that I intended to delete. can't seem to do it here.
*** Bug 149342 has been marked as a duplicate of this bug. ***
Created attachment 183427 [details]
ODP file with a macro that should duplicate a master slide.
Run the TestAddMasterPage() sub in the document Standard:Module1.
Expected: You get a duplicate of the 1st masterpage (there's only one).
Found : You get a duplicate of the first standard slide.
Version: 220.127.116.11 / LibreOffice Community
Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
OS: LinuxMint 20.3 (Cinnamon)
This bug is still present, 10 yrs after being opened :,(
This is very annoying in that the copy masterslide option would be a workaround to the lack of masterslides inheritance. It is tedious to duplicate many properties from a given masterslide to another.
Note that the API exposes a .Duplicate() method in the Impress document service (XDrawPageDuplicator interface), see page:
where one can read:
"creates a duplicate of a DrawPage or MasterPage, including the Shapes on that page and inserts it into the same model."
which is erroneous. While this method can duplicate standard slides, it can't duplicate master ones. See attachment: https://bugs.documentfoundation.org/attachment.cgi?id=183427.
So I see two options: (1) fix the API help page or (2) fix the .Duplicate() method to apply to the master slides as explained. My take goes to (2), and adding the Add option in the UI :)
(In reply to Jean-Francois Nifenecker from comment #35)
> copy masterslide option would be a
> workaround to the lack of masterslides inheritance.
Is there an open bug about that possibility? If not, please open one and describe this more fully.
> This bug is still present, 10 yrs after being opened ... This is very annoying
Apparently no newbie coder has taken this easy hack upon themselves over the past decade, so perhaps the veterans would take care of this one.