GNOME Bugzilla – Bug 599901
Scale and tick auto-sizes depend on scale limits weirdly
Last modified: 2018-05-22 13:03:59 UTC
Created attachment 146417 [details] A simple graph exhibiting the misbehavior This is a minor POLA violation. Tested with 1.9.12 under WinXP and 1.9.14 in FreeBSD. A graph with a XY plot has different size of the plot area and of the scale ticks if the scale bounds are switched from automatic to non-automatic mode, if the tick size is automatic (and plot size is also automatic). The attached file contains an example of such a plot with two points, (-0.06, -0.06), (0.22, 0.22). All scale parameters are automatic. The actual bounds of the scales are -0.1 and 0.25, the ticks are 0.05 (both X and Y scales, on X scale only every second tick has a label). If you deselect 'automatic' from e.g. Minimum bound of X-Axis1, the actual Maximum bound is changed to 0.3 and Major ticks to 0.1. The greyed-out values of these parameters are not refreshed, but the preview graph shows the changes. When Apply is clicked, all the values are really applied. If you deselect 'automatic' from Maximum bound of X-Axis1, the scale bounds are not changed, but the Major ticks value is changed to 0.1, and the ralative size of the plot in Chart1 is increased. Similar changes happen with Y-Axis1.
Confirmed. Looks weird.
Not sure it is really a bug. This is aboder effect. When everything is auto, the step is evaluated as 0.05 for a range of [-0.059,0.22], but when the minimum is not anymore auto, the used range becomes [-0.1,0.22] which leads to a step of 0.1. Whatever we do, we'll find borderline cases where things change. What seems a bug is that auto values are not updated in the apropriate entries.
I understand it so that the step is to be evaluated from the automatically or manually selected range for the scale, not from the range of values in data. (Apparently it does so now for manual bounds.) Why does the evaluating function get the ranges [-0.06,0.22] and [-0.1,0.22] while the bounds are -0.1 and 0.25 in all four cases (manual/auto for Min and Max)? The function just should not know the state of Automatic for bounds, even indirectly. No borderline cases will be found in this case. Or what do I miss? I guess the same happens for the function evaluating the size of the backplane in the chart, it gets different arguments for the same but differently calculated scales.
The ranges used for the evaluation are the actual minimum and maximum when auto (-0.059 and .022 in the sample file) and are replaced by the set values when manual, so the minimum becomes -0.1. backplane just fills the plot area, so it should not be affected.
> manual, so the minimum becomes -0.1. The question is why it is not replaced by the same -0.1 in case of auto minimum. On the scale it is replaced, hence it should be replaced in the evaluation. > backplane just fills the plot area, so it should not be affected. Should not. But it is... Watch the distance between the right border of Backplane1 and right border of Chart1 while switching auto for Minimum and especially Maximum of X-Axis1.
I mean, the size which also determines the size of Backplane1 is change. I have no idea on nesting of the classes or any other internals. In the properties, Backplane1 and Plot1 are at the same level (and *-Axis* also) and have the same sizes.
(In reply to comment #5) > > backplane just fills the plot area, so it should not be affected. > > Should not. But it is... Watch the distance between the right border of > Backplane1 and right border of Chart1 while switching auto for Minimum and > especially Maximum of X-Axis1. Not a backplane issue, but apparently one more axis issue. Needs some investigation.
The problem with limits is, as Jean points out, that we simply presend that the graph minimum is -0.1 when that limit is set explicitly. That was considered close enough to the right thing. You are observing an artifact from that which we should eventually fix, but isn't high on our list. The backplane differences seem to be cause by width differences between "0.3" and "0.25".
> he backplane differences seem to be cause by width differences between "0.3" and "0.25". That's for auto of minimum for X-Axis1. For maximum there is no change of the (shown) labels,
The issue might occur for the maximum too. In your sammple, the minimum does not change, but the step changes. If the minimum was something as -0.05 instead of -0.1, it would change: something as -0.02 and + 0,27 would show a change when setting the maximum to manual but not for the minimum.
I can only speak about the actual results on the screen, not inside the program. For the maximum, no change of the shown labels happens, and the last label 0.2 is quite far from the plot margins. What changes is that a step value changes from 0.05 to 0.1, and a tick on the right boundary (0.25, no shown label at X-Axis1) disappears. It might be so that the size of might-be-printed label is accounted for in the scale size calculations, I do not know, I say that it is not needed to be accounted for, if it is not shown. For Y-Axis1, the result depends even on the order of removing the selections of auto. To repeat: I do realize these are minor things, probably demanding rather big refactoring of the program thus priority might be very low... I only ask for keeping this report as a recognized case of POLA violation until it gets fixed.
I don't intend do mark this one as WONTFIX or INVALID. It will be fixed one day when somebody has time for that. Clearly a very low priority. Of course, you might disagree, and a patch is welcome.
I guess the following is connected to the described above... Start gnumeric, insert XY plot, all defaults, any size. Double click it to edit properties. Select Y-Axis1. On Scale tab, deselect Automatic from Minimum and Maximum, set minimum to -3e-8, set maximum to 3e-8. Watch the values been refreshed every second with changed case of 'e'/'E'. This makes more difficult any further changes to the values. Tested in 1.10.15 under Win7 and in 1.10.14 under Gnome + FreeBSD. Also I want to mention, that if right after typing the new value I click on e.g. X-Axis1, the change is discarded. I need to press enter or click on anything in the same property (even on another tab of this property), but not on another property of the plot. This was not the case few versions back. Not sure if this deserves a separate bug report...
Very strange, needs fixing as soon as possible!
(In reply to comment #13) > Also I want to mention, that if right after typing the new value I click on > e.g. X-Axis1, the change is discarded. I need to press enter or click on > anything in the same property (even on another tab of this property), but not > on another property of the plot. This was not the case few versions back. Not > sure if this deserves a separate bug report... Are you sure about that? The code did not change as far as I know.
Update storm fixed. Probably unrelated to the original issue here.
(In reply to comment #15) > Are you sure about that? The code did not change as far as I know. I'm quite sure that it worked differently 3-4 months ago, but I have no idea what is the cause. Possibly, a change of gnome or gtk+ version. I used to copy data ranges from a series to series, mostly (X), and then suddenly an extra click was needed. Unfortunately, I had really no time to submit a bug report immediately.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/goffice/issues/19.