Bug 152655 - Introduce a Slide/Page style category in Impress
Summary: Introduce a Slide/Page style category in Impress
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: ODF-spec ImpressDraw-Style-Additions
  Show dependency treegraph
 
Reported: 2022-12-23 14:44 UTC by Eyal Rozenberg
Modified: 2023-01-16 11:44 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-12-23 14:44:23 UTC
Impress Slides / Draw Pages - have many features one can set individually: 

* Background color / gradient / image
* Background transparency
* Format (16:9/4:3)
* Width & Height
* Orientation
* Direction (LTR/RTL)
* Margins
* Slide numbering 
* Master slide
* Choice of layout
* Features of the transition to next slide

(most of the above in the "slide properties" dialog)

... but one cannot save these and re-use them in another slide, except by duplicating a slide.

We should have category of Impress/Draw Slide/Page style to hold such settings.
Comment 1 Cor Nouws 2023-01-07 08:31:54 UTC
Hi Eyal,

How would your idea interfere with the possibilities offered by the existing feature Master Slides?
Comment 2 Eyal Rozenberg 2023-01-07 23:18:23 UTC
(In reply to Cor Nouws from comment #1)
> Hi Eyal,
> 
> How would your idea interfere with the possibilities offered by the existing
> feature Master Slides?

This is a fair question. In some senses, yes, but I believe we can think of it as "overlap" with the feature of Master Slides. Let me try and elaborate.

I would say the master slide view is a lot like a way to edit slide styles by modifying a concrete slide. So, imagine instead of the dialog for character style dialog we had a box with a single character, and that we could use direct-formatting on that character - and the change would apply to every character associated somehow with that "master character".

The analogy is not perfect, mostly because you can do other things on a master slide: 

* You can introduce drawing objects which are static on the slides with a chosen master.
* You can position and format modifiable objects on the slide (e.g. the title area and content area), affecting default positions on the slides - that's not part of what I would consider the "slide style"

but there are also things you can't do:

* You can't have masters inherit from each other
* Not all changes on the master slide apply to the slides using this master, and not just due to DF on those slides. (Although this non-application may be a bug; or it may only be limited to styling of the modifiable slide elements rather than styling of the slide itself)
* Some changes you make to the master actually apply to all slides, e.g. slide dimensions


Now, back to my suggestion that this could be an "overlap" rather than a clash - we could, for example, have the changes to the slide master automatically apply to a generated/induced slide style; and when setting a slide to have a certain master, have that master's slide style constitute the non-master slide's default slide style, to which it starts out as being set.

One could of course go in the other direction, of having slide styles representing different masters, or limiting the scope of what you can do in masters with DF of the slide etc. - but I'm not sure what I think about that.
Comment 3 Cor Nouws 2023-01-12 13:29:21 UTC
Hi Eyal,

Inheritance from master slides has a ticket.
We already have the combination of master slides and slide layouts... adding another level of 'features' - i.e. complexity, will make very few users happy I think ;)
Comment 4 Heiko Tietze 2023-01-12 14:41:50 UTC
We discussed this topic in the design meeting.

Introducing a style requires standardization and implementation everywhere. There should be a very good reason to do so. And since most of the mentioned attributes are already available via master slides, the request is invalid.
Comment 5 Eyal Rozenberg 2023-01-12 23:17:23 UTC
(In reply to Heiko Tietze from comment #4)
>
> Introducing a style requires standardization and implementation everywhere.
> There should be a very good reason to do so. And since most of the mentioned
> attributes are already available via master slides, the request is invalid.

I'll start by saying that this is not merely a design issue. So, a discussion in the design committee (even ignoring the fact that I couldn't attend) is not sufficient IMHO to mark this INVALID. Nor would it be sufficient to decide that this is a good idea, either; I'm guessing whoever works on the master slides and slide layout code might have an opinion about the possibility of expression some/most of that via a proper style. (For which reason I've marked needsDevAdvice, which I should have done earlier.) And this all is doubly the case considering the meta-bug, i.e. the fact that there seems to be agreement about the need to standardize and implement several new kinds of styles in Impress.

Now, to your objection itself... 

the latter clause of your last sentence does not follow from the former. Indeed, many of what would be the attributes of a page/slide are available via master slides. But - this overlap does not make it harder or more complex to standardize or implement. In fact, it might even simplify the existing implementation and/or the standardization. I'm no ODF expert, but - element styles are very natural to represent in XML. I would even guess that the relation between a slide and its master in the ODF is already somewhat like that of a writer page and its style. I'm just suggesting that this relation be split into a proper style (which would be filled out with additional features), and whatever aspects of the relation are non-style-like.



PS - Where is "everywhere"? We're talking about Impress and Draw.
Comment 6 Heiko Tietze 2023-01-13 08:47:18 UTC
(In reply to Eyal Rozenberg from comment #5)
> PS - Where is "everywhere"? We're talking about Impress and Draw.

Microsoft Office, for example. Any application using ODF.
Comment 7 Eyal Rozenberg 2023-01-13 09:40:50 UTC
(In reply to Heiko Tietze from comment #6)
> Microsoft Office, for example. Any application using ODF.

Ah, right, that's a fair point. Still, considering the meta-bug, they would need to implement a bunch more kinds of styles anyway.