Created attachment 133251 [details]
When you want to use it again

You apply the changes, you close the window, you enter to edit and the checkbox returns to Automatic.

The step count is not part of the gradient definition but it is a property of the object, which gets the gradient applied.

The gradient definition itself is defined in an <draw:gradient> element, and that does not has an attribute to store the steps. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416460_253892949

But you can define a style in the Style&Formatting dialog. A style can contain the step count. When you want to use this gradient and this special step count for another object, you only need to apply the style.

(In reply to Regina Henschel from comment #2)
> The step count is not part of the gradient definition but it is a property
> of the object, which gets the gradient applied.
> 
> The gradient definition itself is defined in an <draw:gradient> element, and
> that does not has an attribute to store the steps.
> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.
> html#__RefHeading__1416460_253892949
> 
> But you can define a style in the Style&Formatting dialog. A style can
> contain the step count. When you want to use this gradient and this special
> step count for another object, you only need to apply the style.

[ES]
Perdón pero:
1) Lo que dices no tiene sentido para mí pues soy un simple USUARIO. Para mi problema lo que dices no lo soluciona.
2) Cuando uno hace X cosa en un lugar, espera hacer lo mismo en otro. No espera tener que hacer 3 cosas diferentes para obtener el mismo resultado. Ej.: Si guardo un gradiente al crear un fondo para la página, espero poder usar el mismo gradiente en objetos y en estilos, sin tener que aplicar opciones en forma manual cada vez.
3) El punto 2 es el fin real de este reporte.
Mira como usuario lo que reporto: Entro al estilo de página, le aplico un gradiente con 3 pasos, ángulo de 90º y una distancia desde el borde de 88%. Lo guardo para usarlo en un objeto de dibujo, aplico a la página y salgo de la ventana de edición de estilos de página. Voy al objeto y veo que el gradiente se aplica con Automático en la cantidad de pasos. Entonces tengo que volver a configurar eso, lo vuelvo a guardar. Y eso lo tengo que hacer cada vez que quiero aplicarlo a un objeto (imagina un archivo con cientos de objetos iguales). Esto es casi una burla. Es muy molesto y parece ser más un error del programa que una limitación. Yo podría entenderlo, pero el usuario que apenas sabe de lo que hablo, lo tomará como un mal funcionamiento y ¿sabes que pasa? Deja de usar LibreOffice esperando a que sea arreglado.
Sugiero que desarrollen algo para que los pasos sean parte del gradiente, sea como sea pues es lo que el usuario espera.
Perdón por mi inglés pero uso Google.

[EN]
Sorry but:
1) What you say does not make sense to me because I am a simple USER. For my problem what you say does not solve it.
2) When you do X thing in one place, expect to do the same thing in another. Do not expect to have to do 3 different things to get the same result. Eg: If I save a gradient when creating a background for the page, I expect to be able to use the same gradient in objects and styles, without having to apply options manually each time.
3) Point 2 is the real purpose of this report.
Look as user what I report: I enter the style of page, I apply a gradient with 3 steps, angle 90º and a distance from the edge of 88%. I save it for use in a drawing object, apply it to the page and exit the page styles editing window. I go to the object and see that the gradient is applied with Automatic in the number of steps. Then I have to reconfigure that, I save it again. And that I have to do every time I want to apply it to an object (imagine a file with hundreds of equal objects). This is almost a joke. It is very annoying and seems to be more of a program error than a limitation. I could understand it, but the user who barely knows what I'm talking about will take it as a malfunction and you know what happens? Stop using LibreOffice waiting for it to be fixed.
I suggest that you develop something so that the steps are part of the gradient, whatever that is, what the user expects.
Sorry for my English but I use Google.

Created attachment 133299 [details]
The same gradient, in a page background and object's fill (same or different?)

[ES]
El mismo gradiente (guardado) aplicado como fondo de página y como relleno de un objeto. Parece que fueran dos diferentes y eso es lo molesto para el usuario. El usuario espera que al guardar un gradiente se use exactamente igual una y otra y otra vez y no tener que configurar de nuevo. Es fácil si tienes un par de objetos, pero ¿y si son cientos de objetos?
[EN]
The same gradient (saved) applied as a page background and as an object's fill. It looks like they were two different ones and that's annoying for the user. The user expects that when storing a gradient is used exactly the same over and over and again and not have to configure again. It's easy if you have a couple of objects, but what if there are hundreds of objects?

The old UI had a distinction between creating a gradient and applying a gradient. The tab with creating a gradient had no item to set the steps. Only the tab for applying a gradient had a field to set the steps. There it was clear to the user, that the gradient itself is not able to carry the information "steps".

In the new UI this steps-field is mixed with the gradient defining fields. That leads the user to the mistaken belief, that the steps belong to the gradient definition.

So UX needs to thing about a UI, which prevents this mistaken belief.

(In reply to Regina Henschel from comment #5)
> So UX needs to thing about a UI, which prevents this mistaken belief.

Rather than dealing with weirdly defined formats in the UI, the stored preset should be treated like a style as you suggest in comment 2.

(adding the ML)

Removing needsUX; the bug should be fixed - or we have to remove the manual step option.

[ES]
Después de mucho tiempo sin usar este método de formato tan versatil y útil, vuelvo a probarlo y veo con mucho agrado que el degradado añadido, por ejemplo, como fondo de página y guardado en la galería, puede ser reutilizado en otro/s objetos, lo que implica que funciona. Incluso, uno puede regresar a él para modificarlo.
Ahora, los problemas que se presentas con:
1) Al regresar para modificar el degradado, la configuración de pasos vuelve a Automático.
2) Si uno modifica el degradado guardado, no se refleja en los demás objetos donde se aplicó. Por ejemplo, si fue usado en páginas y objetos y lo edita desde un objeto, la página conserva el formato primario (y lo mismo al revés).
3) Y el más molesto es: si uno cierra el archivo, al volver a abrirlo, el degradado guardado o se perdió de la galería (no siempre)
4) La modificación indicada en el Paso 2, se perdió y el objeto refleja la configuración original con la que se guardó.

[EN]
After a long time without using this format method so versatile and useful, I go back to try it and I see with great pleasure that the added gradient, for example, as a page background and saved in the gallery, can be reused in other objects, which implies that it works. Even, one can return to it to modify it.
Now, the problems that arise with:
1) When returning to modify the gradient, the step configuration returns to Automatic.
2) If one modifies the saved gradient, it is not reflected in the other objects where it was applied. For example, if it was used in pages and objects and you edit it from an object, the page retains the primary format (and the same thing in reverse).
3) And the most annoying is: if one closes the file, upon re-opening it, the gradient saved or was lost from the gallery (not always)
4) The modification indicated in Step 2 was lost and the object reflects the original configuration with which it was saved.

Created attachment 145338 [details]
Example

[ES]
La imagen insertada muestra la configuración con la que se guardó el archivo.
El degradado de la página es la versión modificada del degradado original (que tiene aplicado el rombo).

[EN]
The inserted image shows the configuration with which the file was saved.
The gradient of the page is the modified version of the original gradient (which has the diamond applied).

(In reply to Leandro Martín Drudi from comment #8)
> 1) When returning to modify the gradient, the step configuration returns to
> Automatic.

Which is the topic here and still an issue.

> 2) If one modifies the saved gradient, it is not reflected in the other
> objects where it was applied. For example, if it was used in pages and
> objects and you edit it from an object, the page retains the primary format
> (and the same thing in reverse).

The area fill "style" is actually a direct formatting rather than a style. Would you expect that user-defined solid colors are taken from this setting, like you define MyBrand=#FF0000, change it later to #00FF00, and that modifies all previously added shapes?

> 3) And the most annoying is: if one closes the file, upon re-opening it, the
> gradient saved or was lost from the gallery (not always)
> 4) The modification indicated in Step 2 was lost and the object reflects the
> original configuration with which it was saved.

"Not always" is hard to track. If you think there is an issue please file a new bug. #4 is a consequence of #3, I guess.

(In reply to Heiko Tietze from comment #10)
 
> Which is the topic here and still an issue.

I don't know. I'm an user.

> The area fill "style" is actually a direct formatting rather than a style.
> Would you expect that user-defined solid colors are taken from this setting,
> like you define MyBrand=#FF0000, change it later to #00FF00, and that
> modifies all previously added shapes?

[ES]
No sé si entendí bien su pregunta porque, como dije, soy usuario y desconozco los funcionamientos internos y poco me importan: solo espero un resultado lógio en su funcionamiento.
Lo que hago:
Entro a la configuración, edito todo lo que está disponible desde el degradado guardado y guardo nuevamente los cambios en el degradado de la galería (creado por mí).
Lo que espero:
Que todos los objetos y páginas donde se aplicó ese mismo degradado guardado reflejen la nueva configuración.
Lo que sucede:
Solo se aplica al objeto seleccionado desde el que se editó.

[EN]
I do not know if I understood your question well because, as I said, I am a user and I do not know the internal operations and I do not care: I only hope for a logical result in its operation.
What I do:
I enter the configuration, I edit everything that is available from the saved gradient and I save again the changes in the gallery gradient (created by me).
What I expect:
That all the objects and pages where the same saved gradient was applied reflect the new configuration.
What happens:
It only applies to the selected object from which it was edited.

> "Not always" is hard to track. If you think there is an issue please file a
> new bug. #4 is a consequence of #3, I guess.

[ES]
No pude reproducirlo. Solo sucedió una vez y no estoy seguro de los pasos que hice para poder reproducirlo. Se podría omitir este detalle debido a que, antes de responder, intenté repetir todo lo que haría para obtener un resultado en un nuevo documento y no sucedió nada que no haya dicho antes, pero este problema no se volvió a presentar.

[EN]
I could not reproduce it. It only happened once and I am not sure of the steps I took to reproduce it. This detail could be omitted because, before answering, I tried to repeat everything I would do to obtain a result in a new document and nothing happened that I did not say before, but this problem did not happen again.

(In reply to Leandro Martín Drudi from comment #11)
> I do not know if I understood your question well...

It was more a rhetorical question :-) 
Point is that all area fill options are direct formatting (like when you press "bold" on the standard toolbar) and not styles (such as the character style "emphasis"). That's perfectly clear for solid colors, which could be helpful to understand why gradients work likewise.

(In reply to Heiko Tietze from comment #12)
> (In reply to Leandro Martín Drudi from comment #11)
> > I do not know if I understood your question well...
> 
> It was more a rhetorical question :-) 
> Point is that all area fill options are direct formatting (like when you
> press "bold" on the standard toolbar) and not styles (such as the character
> style "emphasis"). That's perfectly clear for solid colors, which could be
> helpful to understand why gradients work likewise.

[ES]
Aquí se juntan muchos problemas y el principal es mi pésimo inglés (debo recurrir a Google Translator). Sinceramente entre esto y que hablan con un usuario como si se tratara de un experto (en algunos aspectos, no siempre y no todos pero sí la mayoría) se hace muy difícil poder entender.
Pero, como usuario, lo que me interesa es la respuesta a esto:
1) ¿Eso se podrá convertir a lo que realmente un usuario espera?
2) ¿Cuánto tiempo podría tomar que se de forma a lo que uno espera?
3) ¿Ya se está trabajando en ello o simplemente estoy perdiendo el tiempo?
Debo aclarar que si la respuesta a 3 es "no", creo que abandonaré LibreOffice porque no siento que ustedes tomen en serio algunas cosas importantes para los usuarios. Sin embargo, guardo la esperanza que en futuros lanzamientos (¿En LibreOffice 7, tal vez?) esto ya esté totalmetne resuelto y pueda usar estos gradientes como yo espero usarlo y no tener que reinventar la rueda cada vez que deba dar formato a los diferentes elementos de un archivo.
He discutido mucho con expertos enalgunos chats de Telegram sobre que en LibreOffice los experots encuentran un problema a cada solución. Y cuando alguien plantea un problema, le explican una alternativa complicadísima para hacer lo mismo en vez de resolver el camino más corto. Nunca intentan verificar el origen del problema y ayudar a resolverlo.
No lo digo por esto ni por usted ni por nadie en particular, sino en general, en muchos aspectos de funcionamiento del soporte de LibreOffice. Llega a tal punto esto que digo que muchas veces he pensado en dejar de aportar a LibreOffice con alguna ayuda o reporte (como ya dejé de dar soporte económico por esto mismo) debido a que no me siento acompañado como usuario.

[EN]
Here many problems come together and the main one is my bad English (I must use Google Translator). Honestly between this and talking to a user as if it were an expert (in some aspects, not always and not all but the majority) it is very difficult to understand.
But, as a user, what interests me is the answer to this:
1) Can that be converted to what a user really expects?
2) How long could it take to shape what one expects?
3) Is it already working on it or am I just wasting my time?
I must clarify that if the answer to 3 is "no", I think I will leave LibreOffice because I do not feel that you take seriously some important things for the users. However, I keep hoping that in future releases (in LibreOffice 7, maybe?) This is completely solved and I can use these gradients as I hope to use it and not have to reinvent the wheel every time I have to format the different ones elements of a file.
I have discussed a lot with experts in some Telegram chats about LibreOffice where experts find a problem with each solution. And when someone poses a problem, they explain a very complicated alternative to do the same thing instead of solving the shortest route. They never try to verify the origin of the problem and help solve it.
I do not say this for anyone in particular, but in general, in many aspects of the operation of LibreOffice support. It reaches this point that I say that many times I have thought about stopping contributing LibreOffice with some help or report (as I stopped giving financial support for this) because I do not feel accompanied as a user.

@Leandro: No developer is coding something, because the desired behavior is still not clear. "working on it" means to first define the goal. And that needs discussions like this.

@Heiko: You have removed UX tag, but I think it includes UX problems:

From point of file format, you define the kind of filling in a <draw:gradient> element. This element gets a name, by which it is referenced in a style. The style can be a child element of <office:styles> - which corresponds to a 'style' in the sense of UI,  or it can be a child element of <office:automatic-styles> - which corresponds to 'direct formatting' in the UI. It makes no difference here.

So "gradient" has two parts: defining a gradient and using a gradient. The current UI does not distinguish between them.

Because the gradient is referenced by name in the style, a change in the gradient will be reflected in all styles, that reference it, and so in all objects, that use these styles. But the UI has no means to alter an existing gradient definition. I do not mean a change in the palette, but in the file. You need to edit the gradient definition in the file itself manually, to get the desired global change.

The Gradient tab in the UI does not show the gradients, that are defined in the file. The UI shows only palette items of the installed LibreOffice and the user gradient items of the current user. The UI gives no apparent access to the gradient definitions of the file.

And as already written in comment 2, the step-count is not part of the gradient definition, but part of the style. That is not obvious to users.

The problem is not comparable with colors, because they are never referenced but always used directly as #rrggbb values.

(In reply to Regina Henschel from comment #14)
> @Leandro: No developer is coding something, because the desired behavior is
> still not clear. "working on it" means to first define the goal. And that
> needs discussions like this.
> 
> @Heiko: You have removed UX tag, but I think it includes UX problems:
> 
> From point of file format, you define the kind of filling in a
> <draw:gradient> element. This element gets a name, by which it is referenced
> in a style. The style can be a child element of <office:styles> - which
> corresponds to a 'style' in the sense of UI,  or it can be a child element
> of <office:automatic-styles> - which corresponds to 'direct formatting' in
> the UI. It makes no difference here.
> 
> So "gradient" has two parts: defining a gradient and using a gradient. The
> current UI does not distinguish between them.
> 
> Because the gradient is referenced by name in the style, a change in the
> gradient will be reflected in all styles, that reference it, and so in all
> objects, that use these styles. But the UI has no means to alter an existing
> gradient definition. I do not mean a change in the palette, but in the file.
> You need to edit the gradient definition in the file itself manually, to get
> the desired global change.
> 
> The Gradient tab in the UI does not show the gradients, that are defined in
> the file. The UI shows only palette items of the installed LibreOffice and
> the user gradient items of the current user. The UI gives no apparent access
> to the gradient definitions of the file.
> 
> And as already written in comment 2, the step-count is not part of the
> gradient definition, but part of the style. That is not obvious to users.
> 
> The problem is not comparable with colors, because they are never referenced
> but always used directly as #rrggbb values.

[ES]
Siento no estar de acuerdo con Ud.: En "lenguaje usuario" acaba de demostrarme que sí están trabajando en ello. El hecho que estos mails sean con el fin de encontrar una solución es, para mí, que están interesados en resolverlo.
Me alegra ver que esto no quedó en un ida y vuelta de mails sin llegar a ningún lado. :-)

[EN]
I regret not agreeing with you: In "user language" you have just shown me that you are working on it. The fact that these emails are in order to find a solution is, for me, that they are interested in solving it.
I'm glad to see that this was not in a round trip of mails without getting anywhere. :-)

(In reply to Regina Henschel from comment #14)
> ...
> @Heiko: You have removed UX tag, but I think it includes UX problems:
> ...

Basically I agree that it is preferable to have all formatting functions in both flavors, as direct formatting and as style. But we are talking about a piece only, meaning the gradient (and other area fill options) is always bound to an object. So the expected workflow is to define a paragraph style, or a drawing style, etc. including the gradient. 

Of course we could also save the area presets (excluding solid color) as styles. But I expect trouble to understand this special workflow. And many users may expect the opposite behavior as known from today. 

Btw, how does it work in other tools?

(In reply to Heiko Tietze from comment #16)
> But we are talking about a
> piece only, meaning the gradient (and other area fill options) is always
> bound to an object.

No, a gradient is an entity of it own. It can exists in the file without being used. A gradient is different from a style. A gradient is a <draw:gradient> element and a style is a <style:style> element and neither can be a child element of the other. A style can reference a gradient by the gradient name.

(In reply to Regina Henschel from comment #17)
> (In reply to Heiko Tietze from comment #16)
> > But we are talking about a
> > piece only, meaning the gradient (and other area fill options) is always
> > bound to an object.
> 
> No, a gradient is an entity of it own. It can exists in the file without
> being used. A gradient is different from a style. A gradient is a
> <draw:gradient> element and a style is a <style:style> element and neither
> can be a child element of the other. A style can reference a gradient by the
> gradient name.

Then it's not well defined (similarly to list styles, IMHO) and we do have to make clear, given the implementation is done accordingly, why solid colors, hatches, patterns etc. are not styles.

Created attachment 145444 [details]
Proposal of new arrangement of dialog parts

We should discuss the general "definition <-> style" problem on a mailing list.

Back to the "gradient step" problem:
"Increment" is only applicable, if the dialog is used to apply a direct formatting of a background or if defining a style. "Increment" is not applicable if using the dialog to alter an existing gradient or add a new gradient. Perhaps this will become more obvious, if the "Increment" part is moved from inside the settings to below, see attached image.

The part "Increment" needs to be hidden or disabled, if the dialog is called without a context of style or object, e.g. if calling it by Format > Area.

(In reply to Regina Henschel from comment #19)
> Created attachment 145444 [details]
> Proposal of new arrangement of dialog parts

It's the correct representation of the situation - and I hate it.
 
> The part "Increment" needs to be hidden or disabled, if the dialog is called
> without a context of style or object, e.g. if calling it by Format > Area.

That makes everything really easy ;-).


My take: this is terrible bad usability, hard to understand, destroying an easy dialog. Either the stepping is saved with the preset (I don't see a big showstopper) or we go with just Automatic.

(In reply to Heiko Tietze from comment #20)
> ... Either the stepping is saved with the preset (I don't see a big
> showstopper)

You know that this is not possible.

> or we go with just Automatic.

I do not want to drop a feature, that is used since more than twenty years.

For me the reason is, that the new all-in-one dialog mixes "defining" of something with "applying" it. In the earlier dialogs "defining and management" had a separate dialog tab.

(In reply to Regina Henschel from comment #21)
> (In reply to Heiko Tietze from comment #20)
> > ... Either the stepping is saved with the preset (I don't see a big
> > showstopper)
> 
> You know that this is not possible.

Not really. We could save it with the gradient like

<draw:gradient draw:name="Foo" ... draw:<bar>="..." steps="Auto"/>

but of course ignore this value on the document. The drawback of an actual stepping depending on the last chosen gradient preset is similar to the general setting (and if we go this way, I would place the controls at the bottom of the preview panel).

"steps" is not valid in <draw:gradient>. See the linked URL about valid attributes of <draw:gradient>.

The attribute draw:gradient-step-count is usable with <style:drawing-page-properties> and <style:graphic-properties>. If this attribute is missing, an automatic calculation is used. So there is no need to invent a new attribute for the <draw:gradient> having an "automatic" as value. [http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#property-draw_gradient-step-count]

The draw:gradient-step-count is an attribute of the style of the object. You can have styles using the same gradient but different values for step-count.

In version 6.2.4.2 it works much better. It needs a small nut adjustment to be as the user would expect. EXCELLENT WORK!

Everything reported works perfectly in 6.3.1.
The new (minor) problem is that saving does not appear in the list immediately after saving. You have to close and reopen the object/page properties.

(In reply to Leandro Martín Drudi from comment #25)
> Everything reported works perfectly in 6.3.1.
> The new (minor) problem is that saving does not appear in the list
> immediately after saving. You have to close and reopen the object/page
> properties.

Reproducible:
Versión: 6.4.5.2 (x64)
Id. de compilación: a726b36747cf2001e06b58ad5db1aa3a9a1872d6
Subprocs. CPU: 8; SO: Windows 10.0 Build 19041; Repres. IU: predet.; VCL: win; 
Configuración regional: es-AR (es_AR); Idioma de IU: es-ES
Calc: CL

-------------------------
BUT BUT BUT :D

NOT REPRODUCIBLE IN:
Version: 7.0.0.1 (x64)
Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd
Subprocs. CPU: 8; SO: Windows 10.0 Build 19041; Repres. IU: Skia/Vulkan; VCL: win
Locale: es-AR (es_AR); Interfaz: es-ES
Calc: CL

GREAT, GREAT, GREAT JOB!! (emoji party, emoji balloon, emoji smiling face)

(In reply to Leandro Martín Drudi from comment #26)
> NOT REPRODUCIBLE IN:
> Version: 7.0.0.1 (x64)

Trying with latest master: Writer > Shape with 'Deep Ocean' gradient but 5 steps, applied and reopened shows again the automatic setting and 64 steps. So not fixed en passant, unfortunately.

Version: 7.1.0.0.alpha0+
CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded

*** Bug 133525 has been marked as a duplicate of this bug. ***

Tested in this version:

Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: es-AR (es_AR); UI: es-ES
Calc: CL threaded

The new gradient is saved, it can be reused for other objects, even in other files.
BUT, if you apply another option (gradient, image, pattern, etc.) the previously created gradient loses its settings again.

Lost settings:
Gradient: Increment -> Automatic: False (3 steps)

Settings preserved:
Angle: 90
Border: 75%
From and to colors.

The problem with the 'Increments' field and check box is related to the fix for bug 105966. That fix changes the initial value from the XATTR_GRADIENTSTEPCOUNT property in the property-set of the SvxGradientTabPage to the StepCount component of the gradient definition.

But the gradient definitions in file markup have no information about step count, because step count is part of the graphic style of objects and not of gradient definitions. So the value for StepCount is always 0 (which means "automatic") when you use an initial gradient. And that means that the checkbox 'automatic' is marked regardless of the actual step count of the shape.

Regina Henschel committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/48a9ade1dacc63e61cc9a5748f29119d1d01d841

tdf#107787 Sync FillGradientStepCount and StepCount

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

The patch solves the problem, that the dialog does not keep the Increment setting of a selected object, see bug 150545.

The palette uses the ODF definition of a gradient which does not include Increment values. Heiko, do you really want, that the XML of our palette is changed to be able to carry the Increment value in addition?
Or should the design of the dialog be changed (with is needed for multicolor gradients anyway) to make clear, that the Increment value does not belong to a gradient definition but is an attribute of the individual object?

Regina Henschel committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/a69bf0de6a7515fa4de551ba8d6f15f1120cb145

tdf#107787 Sync FillGradientStepCount and StepCount

It will be available in 7.6.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Regina Henschel from comment #33)
> Or should the design of the dialog be changed (with is needed for multicolor
> gradients anyway) to make clear, that the Increment value does not belong to
> a gradient definition but is an attribute of the individual object?

This. I suggest to check (=Automatic) and disable the steps spinbox if more than two colors are used aka MCGR.

(In reply to Regina Henschel from comment #33)
> Heiko, do you really want, that the XML of our palette is
> changed to be able to carry the Increment value in addition?

Ultimately being able to have 5 steps for red to blue followed by a smooth transition from blue to green, as an example? Hopefully I never suggested this (keep it simple).

Created attachment 188147 [details]
Increment 3 in MCGR

(In reply to Heiko Tietze from comment #35)
> (In reply to Regina Henschel from comment #33)
> > Or should the design of the dialog be changed (with is needed for multicolor
> > gradients anyway) to make clear, that the Increment value does not belong to
> > a gradient definition but is an attribute of the individual object?
> 
> This. I suggest to check (=Automatic) and disable the steps spinbox if more
> than two colors are used aka MCGR.

So you suggest to always use "automatic" in case the gradient has more than two color stops?

The current behavior is, that in case there are more than two color stops and the user has set an Increment value, the stepped rendering is applied individually to each part between two adjacent stops.

Example attached: [1] offset 0.2 red, [2] offset 0.5 yellow, [3] offset 0.95 green and Increment=3. Current behavior:
0 to 0.2 red (automatic extending of the first color),
0.2 to 0.3 red (first step)
0.3 to 0.4 orange (second step)
0.4 to 0.5 yellow (third step)
0.5 to 0.65 yellow (first step)
0.65 to 0.8 yellow+green mix (second step)
0.8 to 0.95 green (third step)
0.95 to 1 green (automatic extending of the last color)

For me it looks ugly and I would support to use always 'automatic' in case of more than two colors. The user can still create steps by setting two stops to same offset. Having always 'automatic' in this case brings no restriction to the OOXML filter, because OOXML has no setting for stepped rendering at all.

Because MCGR is not yet in ODF, we could include such restriction into the proposal to the ODF TC.

> 
> (In reply to Regina Henschel from comment #33)
> > Heiko, do you really want, that the XML of our palette is
> > changed to be able to carry the Increment value in addition?
> 
> Ultimately being able to have 5 steps for red to blue followed by a smooth
> transition from blue to green, as an example? Hopefully I never suggested
> this (keep it simple).

I do not mean a mix but this: Users currently do not understand, why a preset gradient cannot have a stepped rendering, although the shape from which the preset is created had an Increment=4, for example. The current solution of the Gradient-dialog has no indication that it is not possible.

This problem exists independent from MCGR and is not solved by forcing 'automatic' in case of more than two colors.

I see the following solutions. Which would do you prefer?
(A) The current css.awt.Gradient struct from the API contains the Increment as StepCount component, whereas the gradient definition in the <draw:gradient> in ODF has no corresponding attribute. Currently the XML of the palette uses the ODF definition directly. Because the XML of the palette is our own format we could change it without impacts to ODF. Of course, this is not to be had for free; it requires a developer to donate his free time to it.

(B) The dialog could show a warning, that the Increment-value is not included in the added gradient, in case an Increment-value is set and the user adds this gradient to the palette.

(C) Separate the Increment setting visually from the others in the dialog and include a hint/warning in its label.

(B) and (C) affects only the dialog and could be done, when the dialog is adapted to MCGR.

I did not understand very well what you are talking about but I will expose my position as a user and what I expect to happen when I use the tool: When I apply 2 or more steps, it is because the effect obtained is the one I want. In fact, this complaint arises because I cannot recover that expected configuration. Forcing the user to stay in Automatic when the desired effect is obtained with few steps is disrespectful to the user. As an user, I expect what was presented when configuring it to happen. Otherwise, as an user, I consider it a malfunction and it leads me not to use the software until it is resolved.

Setting back to new, but I think Regina was waiting for a reply from Heiko.

(In reply to Regina Henschel from comment #36)
> So you suggest to always use "automatic" in case the gradient has more than
> two color stops?
> 
> The current behavior is, that in case there are more than two color stops
> and the user has set an Increment value, the stepped rendering is applied
> individually to each part between two adjacent stops.

The stepped gradients are IMO a mutually exclusive alternative to multi-color gradients (which define their own steps, and allow to create the same effect, if needed). Having it either-or is correct, I believe.

> I see the following solutions. Which would do you prefer?
> (A) The current css.awt.Gradient struct from the API contains the Increment
> as StepCount component, whereas the gradient definition in the
> <draw:gradient> in ODF has no corresponding attribute. Currently the XML of
> the palette uses the ODF definition directly. Because the XML of the palette
> is our own format we could change it without impacts to ODF. Of course, this
> is not to be had for free; it requires a developer to donate his free time
> to it.

This is the preferred one. The UI is orthogonal to the file format. The effort is a different thing; the idea that we should reject some improvement because it needs an effort is not correct (well, it may happen not too soon, but that doesn't matter).