[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Stéphane Guillou (stragu)  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #39 from Stéphane Guillou (stragu) 
 ---
Setting back to new, but I think Regina was waiting for a reply from Heiko.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

QA Administrators  changed:

   What|Removed |Added

 Status|NEEDINFO|UNCONFIRMED
 Ever confirmed|1   |0

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #38 from QA Administrators  ---
[Automated Action] NeedInfo-To-Unconfirmed

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #37 from Leandro Martín Drudi  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #36 from Regina Henschel  ---
Created attachment 188147
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188147=edit
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  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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #35 from Heiko Tietze  ---
(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).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Commit Notification  changed:

   What|Removed |Added

 Whiteboard|target:24.2.0   |target:24.2.0
   ||target:7.6.0.0.beta2

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Regina Henschel  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=15
   ||0545
 Status|NEW |NEEDINFO

--- Comment #33 from Regina Henschel  ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #32 from Commit Notification 
 ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Commit Notification  changed:

   What|Removed |Added

 Whiteboard||target:24.2.0

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Regina Henschel  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=10
   ||5966

--- Comment #31 from Regina Henschel  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #30 from Leandro Martín Drudi  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #29 from QA Administrators  ---
Dear Leandro Martín Drudi,

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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Timur  changed:

   What|Removed |Added

 CC||greenandpleasant2000-suppor
   ||t...@yahoo.co.uk

--- Comment #28 from Timur  ---
*** Bug 133525 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #27 from Heiko Tietze  ---
(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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #26 from Leandro Martín Drudi  ---
(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)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Heiko Tietze  changed:

   What|Removed |Added

   See Also||https://bugs.documentfounda
   ||tion.org/show_bug.cgi?id=13
   ||1035

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #25 from Leandro Martín Drudi  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #24 from Leandro Martín Drudi  ---
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!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Regina Henschel  changed:

   What|Removed |Added

URL||http://docs.oasis-open.org/
   ||office/v1.2/os/OpenDocument
   ||-v1.2-os-part1.html#element
   ||-draw_gradient

--- Comment #23 from Regina Henschel  ---
"steps" is not valid in . See the linked URL about valid
attributes of .

The attribute draw:gradient-step-count is usable with
 and . If this
attribute is missing, an automatic calculation is used. So there is no need to
invent a new attribute for the  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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #22 from Heiko Tietze  ---
(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

="..." 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).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #21 from Regina Henschel  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #20 from Heiko Tietze  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #19 from Regina Henschel  ---
Created attachment 145444
  --> https://bugs.documentfoundation.org/attachment.cgi?id=145444=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #18 from Heiko Tietze  ---
(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
>  element and a style is a  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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #17 from Regina Henschel  ---
(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 
element and a style is a  element and neither can be a child
element of the other. A style can reference a gradient by the gradient name.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #16 from Heiko Tietze  ---
(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?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #15 from Leandro Martín Drudi  ---
(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
>  element. This element gets a name, by which it is referenced
> in a style. The style can be a child element of  - which
> corresponds to a 'style' in the sense of UI,  or it can be a child element
> of  - 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. :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #14 from Regina Henschel  ---
@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 
element. This element gets a name, by which it is referenced in a style. The
style can be a child element of  - which corresponds to a
'style' in the sense of UI,  or it can be a child element of
 - 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #13 from Leandro Martín Drudi  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #12 from Heiko Tietze  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #11 from Leandro Martín Drudi  ---
(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=#FF, 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #10 from Heiko Tietze  ---
(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=#FF, 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #9 from Leandro Martín Drudi  ---
Created attachment 145338
  --> https://bugs.documentfoundation.org/attachment.cgi?id=145338=edit
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).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #8 from Leandro Martín Drudi  ---
[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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Heiko Tietze  changed:

   What|Removed |Added

   Keywords|needsUXEval |
 CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com
   |.freedesktop.org|

--- Comment #7 from Heiko Tietze  ---
Removing needsUX; the bug should be fixed - or we have to remove the manual
step option.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Heiko Tietze  changed:

   What|Removed |Added

 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org
 Blocks||94551

--- Comment #6 from Heiko Tietze  ---
(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)


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=94551
[Bug 94551] All-in-one Area tab for modifying object fill
-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Regina Henschel  changed:

   What|Removed |Added

   Keywords||needsUXEval
 Status|REOPENED|NEW
  Component|Writer  |UI

--- Comment #5 from Regina Henschel  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Leandro Martín Drudi  changed:

   What|Removed |Added

 CC||sanipache...@outlook.com.ar

--- Comment #4 from Leandro Martín Drudi  ---
Created attachment 133299
  --> https://bugs.documentfoundation.org/attachment.cgi?id=133299=edit
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Leandro Martín Drudi  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|NOTABUG |---
 Ever confirmed|0   |1

--- Comment #3 from Leandro Martín Drudi  ---
(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  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 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

Regina Henschel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rb.hensc...@t-online.de
 Resolution|--- |NOTABUG

--- Comment #2 from Regina Henschel  ---
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  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 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 107787] Gradients steps don't save

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #1 from Leandro Martín Drudi  ---
Created attachment 133251
  --> https://bugs.documentfoundation.org/attachment.cgi?id=133251=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs