Description: I know that a reliable way to set the background for a slide is to set the Slide Master background and then apply that to the slide. But what about the background property of the slide itself? That doesn't seem to do anything. Steps to Reproduce: 1. Create a new presentation with several slides. 2. In the sidebar, click Master View. Right-click on the Master Slide, click on Properties, and choose the Background tab. Click Color, choose an obvious color such as orange, and click OK. The background of the Master Slide becomes orange. 3. Click Close Master View. All of the slides become orange. 4. Select one of the slides in the Slide Pane. In the Sidebar, uncheck Master Background. The slide switches to a white background (although not in the slide pane, but that's another issue.) 5. Right-click on the (white) slide, click on Properties, and choose the Background tab. Click on Color, choose a different obvious color such as purple, and click OK. The slide is still white. 6. Right-click on the (white) slide, click on Properties, and choose the Background tab. Click on Gradient, select one of the gradients, and click OK. The slide is still white, even though the sidebar (slide properties) now shows that the Background is a gradient. 7. Try the other possible backgrounds (Bitmap, Pattern, or Hatch). 8. In the sidebar, check Master Background. Aha! The selected background is applied to the formerly white slide. 9. For extra confusion, click Master View. The Slide Master has a solid orange background, showing that there is a "master slide" for the presentation and a different "master slide" (invisible unless applied) for the slide we've been working on. Actual Results: As listed in steps above. Yes, I understand (sort of) how it's supposed to work, but from the point of view of a new or inexperienced user, it's mighty confusing. Expected Results: As a naive user, I want to make the background for one slide different from the background of the other slides. To do that, I turn off the Master Background and then go to the slide properties and follow steps that seem to make sense, namely change the background. But it doesn't work. To have to understand that there's a "master slide" for each slide that is (or might be) different from the "master slide" for the other slides, and to understand that if I change the background property with Master Background unchecked I'm really changing the background of the invisible master slide... that's a lot of deep knowledge for that inexperienced user. Is there any value to the concept of the master for an individual slide? Why not just let each slide's background be set individually, if that's the user's preference? The sidebar would still show the setting of that background. Then the Master Background checkbox would mean "apply the background from the Presentation Master Slide, the one that you see if you click Master View." Reproducible: Always User Profile Reset: No Additional Info: Apologies for ranting and for my possible misunderstanding of how this is supposed to work. It just seems to me that slide properties, slide master properties, and presentation master properties are too many levels, and that the sidebar control labels (Background, Master Background, and Master View) don't clarify what's what. Version: 6.0.0.3 (x64) Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Repro with the steps. It seems this has always been this way. Let's ask UX what they think about this. They have lots of background experience. Win 10 LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735 Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 40c33132cfa6582dfccf17e787f10dd4dbd0819d CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on February 24th 2018
If you not untick Master Background everythign should work as you expect. I'd say we have two bugs: Master Background is no straightforward implemented and the background set in master is not taken into the area dialog (tab is always none). Ordinary bugs, AFAICS.
The check-boxes "Master background" and "Master Objects" should be disabled, if in master view. They set the attributes "presentation:background-visible" and "presentation:background-objects-visible". The specification text for those is, "The presentation:background-visible attribute specifies whether to display the background of a master page when displaying a presentation page." and "The presentation:background-objects-visible attribute specifies whether to display objects in the background of a master page when displaying a presentation page." respectively. So these attributes make only sense for a normal page/slide. They made no changes to the master page. Styling the "background" of a slide does not generate a new "master", but it is the draw:fill attribute in its page properties. The implementation of "presentation:background-visible" and "presentation:background-objects-visible" is wrong, because it does not only disables things from master, but disables fill properties from the slide itself. For a master page the attribute draw:display of a <draw:layer> would be suitable. But the implementation of layers has currently a lot of problems, which have to be solved prior, that a quick solution is not possible.
Let's go with Regina's suggestion and disable the unchecked checkboxes in master mode. Nice easy hack but needsDevEval for code pointers.
The "grayed out" should be taken from a checked checkbox, because background objects cannot be hidden at the master page.
*** Bug 117358 has been marked as a duplicate of this bug. ***
Dear David F Smith, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present. The user interface might have changed since I first reported it, or I may have abbreviated the steps, so here is a new step-by-step with the current behavior. (New) Steps to Reproduce: 1. Create a new presentation with several slides. 2. In the sidebar, choose Properties, then under Slide click Master View. Right-click on the Master Slide, click on Slide Properties, and choose the Background tab. Click Color, choose an obvious color such as orange, and click OK. The background of the Master Slide becomes orange. 3. Click Close Master View in the sidebar. All of the slides become orange. 4. Select one of the slides in the Slide Pane. In the Sidebar, uncheck Master Background. The slide switches to a white background (although not in the slide pane, but that's another issue.) 5. Right-click on the (white) slide, click on Slide Properties, and choose the Background tab. Click on Color, choose a different obvious color such as purple, and click OK. The slide is still white. 6. Right-click on the (white) slide, click on Slide Properties, and choose the Background tab. Click on Gradient, select one of the gradients, and click OK. The slide is still white, even though the sidebar (slide properties) now shows that the Background is a gradient. 7. Try the other possible backgrounds (Bitmap, Pattern, or Hatch). 8. In the sidebar, check Master Background. Aha! The selected background is applied to the formerly white slide (although the Slide Pane still shows it as white). (8a. In the previous step, the Master Background checkbox might not be visible; if you have chosen a background with more parameters than you started with, the Slide Properties will be longer, but the Layouts Properties don't automatically shift down to make room.) 9. For extra confusion, click Master View. The Slide Master has a solid orange background, showing that there is a "master slide" for the presentation and a different "master slide" (invisible unless applied) for the slide we've been working on. Note that step 8a is a new observation that wasn't present before or that I didn't notice. I reiterate my contention that the "Slide Master" appears to be an unnecessary concept and a source of confusion. Why not just allow the user to change the background of each slide directly? Then the Presentation Master would be a one-step way to control the background of all slides. Thanks for considering this report. Version: 7.1.4.2 (x64) / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
"Master Background" (MB) disables the chosen background but applies also to the attributes set on the slide. If you untick MB, the orange background becomes white (None), changing slide properties > color to blue has no effect. But if MB is on you get the blue background, which reverts to orange by setting None. We could a) rename MB to just Background or b) do not block individual but only master properties. The None = <orange> remains a bit weird anyway. Looking into the code at sd/source/ui/view/drviews2.cxx DrawViewShell::FuTemporary() case SID_DISPLAY_MASTER_BACKGROUND, it seems the background has it's own layer which is hidden by unticking the checkbox. Meaning we cannot distinguish between master background and slide background. Hope someone proves me wrong.
The associated style attribute in ODF is '20.232 presentation:background-visible'. And it's description is: "The presentation:background-visible attribute specifies whether to display the background of a master page when displaying a presentation page." So the current behavior of LibreOffice does not fit to the spec. The "background" of an individual slide is a 'draw:fill' attribute in the style of this individual slide. It is different from 'background of a master page'. Therefor it should not be effected. There exists no attribute in the spec to hide the fill of an individual slide. From point of ODF spec, solution (b) would be correct.
Dear David F Smith, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug