Bug 107787 - Gradients steps don't save
Summary: Gradients steps don't save
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.3.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL: http://docs.oasis-open.org/office/v1....
Whiteboard:
Keywords:
Depends on:
Blocks: Area-Fill-Tab
  Show dependency treegraph
 
Reported: 2017-05-12 00:27 UTC by Leandro Martín Drudi
Modified: 2020-07-15 06:57 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Original configuration applied (52.09 KB, image/png)
2017-05-12 00:27 UTC, Leandro Martín Drudi
Details
When you want to use it again (52.09 KB, image/png)
2017-05-12 00:29 UTC, Leandro Martín Drudi
Details
The same gradient, in a page background and object's fill (same or different?) (11.87 KB, image/png)
2017-05-13 21:45 UTC, Leandro Martín Drudi
Details
Example (19.74 KB, application/vnd.oasis.opendocument.text)
2018-10-03 00:10 UTC, Leandro Martín Drudi
Details
Proposal of new arrangement of dialog parts (54.25 KB, image/png)
2018-10-07 12:37 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leandro Martín Drudi 2017-05-12 00:27:15 UTC
Created attachment 133250 [details]
Original configuration applied

When you create a gradient background and apply a manual amount of gradient steps, it is not saved for reuse in another object or configuration.
Comment 1 Leandro Martín Drudi 2017-05-12 00:29:12 UTC
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.
Comment 2 Regina Henschel 2017-05-12 13:40:26 UTC
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.
Comment 3 Leandro Martín Drudi 2017-05-13 21:40:29 UTC
(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.
Comment 4 Leandro Martín Drudi 2017-05-13 21:45:54 UTC
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?
Comment 5 Regina Henschel 2017-05-16 21:54:32 UTC
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.
Comment 6 Heiko Tietze 2017-05-18 08:14:56 UTC
(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)
Comment 7 Heiko Tietze 2018-06-02 08:26:58 UTC
Removing needsUX; the bug should be fixed - or we have to remove the manual step option.
Comment 8 Leandro Martín Drudi 2018-10-03 00:05:50 UTC
[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.
Comment 9 Leandro Martín Drudi 2018-10-03 00:10:45 UTC
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).
Comment 10 Heiko Tietze 2018-10-04 15:12:53 UTC
(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.
Comment 11 Leandro Martín Drudi 2018-10-04 15:48:13 UTC
(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.
Comment 12 Heiko Tietze 2018-10-05 10:13:06 UTC
(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.
Comment 13 Leandro Martín Drudi 2018-10-06 03:30:42 UTC
(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.
Comment 14 Regina Henschel 2018-10-06 13:14:50 UTC
@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.
Comment 15 Leandro Martín Drudi 2018-10-06 13:32:52 UTC
(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. :-)
Comment 16 Heiko Tietze 2018-10-06 14:31:47 UTC
(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?
Comment 17 Regina Henschel 2018-10-06 15:18:09 UTC
(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.
Comment 18 Heiko Tietze 2018-10-07 08:38:17 UTC
(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.
Comment 19 Regina Henschel 2018-10-07 12:37:37 UTC
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.
Comment 20 Heiko Tietze 2018-10-31 10:36:04 UTC
(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.
Comment 21 Regina Henschel 2018-10-31 16:44:23 UTC
(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.
Comment 22 Heiko Tietze 2018-11-01 14:40:14 UTC
(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).
Comment 23 Regina Henschel 2018-11-01 15:32:49 UTC
"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.
Comment 24 Leandro Martín Drudi 2019-05-24 23:59:13 UTC
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!
Comment 25 Leandro Martín Drudi 2019-09-11 02:07:43 UTC
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.
Comment 26 Leandro Martín Drudi 2020-07-15 02:52:02 UTC
(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)
Comment 27 Heiko Tietze 2020-07-15 06:57:33 UTC
(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