gnumeric issueshttps://gitlab.gnome.org/GNOME/gnumeric/-/issues2020-05-13T19:06:54Zhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/39General ANOVAs with or without repetition2020-05-13T19:06:54ZBugzillaGeneral ANOVAs with or without repetition## Submitted by Daniel Vianna
**[Link to original bug (#309497)](https://bugzilla.gnome.org/show_bug.cgi?id=309497)**
## Description
Distribution/Version: Gentoo
I would like if gnumeric could perform an ANOVA test where both facto...## Submitted by Daniel Vianna
**[Link to original bug (#309497)](https://bugzilla.gnome.org/show_bug.cgi?id=309497)**
## Description
Distribution/Version: Gentoo
I would like if gnumeric could perform an ANOVA test where both factors have
replication. Something like: Test X Day, with two tests and two days, and many
observations per day/test (like 1 per min, say). I believe it would need a
"number of COLUMNS per sample" option, to perform it in a similar way gnumeric
does the 2-factor ANOVA with repetition. Other programs (SPSS, StatView) use a
collumn or more for coding of the treatments (Day1/Test1; Day1/Test2;
Day2/Test1; Day2/Test2) while the rest of the row would hold the repeated
measures (min1, min2, min3...).
Version: 1.5.x2.0Andreas J. GuelzowAndreas J. Guelzowhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/12sheetObjects no longer autoscroll2018-05-22T13:01:22ZBugzillasheetObjects no longer autoscroll## Submitted by Adrian Custer
**[Link to original bug (#63583)](https://bugzilla.gnome.org/show_bug.cgi?id=63583)**
## Description
When you drag a bonobo-object (with the four-way arrow cursor) past the
edges of the sheet (i.e. when...## Submitted by Adrian Custer
**[Link to original bug (#63583)](https://bugzilla.gnome.org/show_bug.cgi?id=63583)**
## Description
When you drag a bonobo-object (with the four-way arrow cursor) past the
edges of the sheet (i.e. when the cursor moves into the column/row headers
or into the scrollbars) the object jumps a little. This is a trivially
annoying behaviour.
1) new gnumeric
2) insert bonobo-object
3) drag object (with four-way arrows cursor) downwards.
--> depending on where the cursor enters the scrollbar, the object might
jump more or less markedly to the left. similar behaviour exists in all
four directions.
if the object is dragged in the white area beyond the limits of the grid
(i.e. in space extra IV65536) it will immediately jump back onto the grid.
Talk about trivial, who the hell inserts objects out there?
to replicate this
1) new gnumeric
2) make the gnum. window really small
3) click drag in grid out to IV65536
4) expand window
5) insert object in the white area
6) drag it around.
cheers,
adrian
Version: git master2.0https://gitlab.gnome.org/GNOME/gnumeric/-/issues/752Copy and paste from Firefox copies too much2024-02-04T00:01:19ZDarrell TangmanCopy and paste from Firefox copies too muchI just installed 1.12.56 to get access to the fix to issue #733, and it mostly fixes the problem I was having. However, when I copy a string such as "$12345.67" from Firefox and paste into a formatted field in gnumeric, the formatting of...I just installed 1.12.56 to get access to the fix to issue #733, and it mostly fixes the problem I was having. However, when I copy a string such as "$12345.67" from Firefox and paste into a formatted field in gnumeric, the formatting of the field changes. It would be nice if there were a way to copy and paste from Firefox that pastes only the string, as it is less work to simply type the new value into the field than it is to paste the new value and then restore the desired format.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/747Wayland crashes due to events piling up2024-01-09T23:00:41ZJan SchmidtWayland crashes due to events piling upI have had a lot of crashes with gnumeric 1.12.56 exiting with a `Lost connection to Wayland compositor.` message. It doesn't happen if I run with `GDK_BACKEND=x11`.
I usually use large sheets for graphing captured data (multiple sheets...I have had a lot of crashes with gnumeric 1.12.56 exiting with a `Lost connection to Wayland compositor.` message. It doesn't happen if I run with `GDK_BACKEND=x11`.
I usually use large sheets for graphing captured data (multiple sheets of > 64k rows and graphs of the data), and recalculating / updates can often take a long time. I suspect the Wayland compositor is kicking gnumeric off for being unresponsive in some wayhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/743performance: Edit paste significantly slower than competition, growing with f...2023-11-20T16:50:30Zb. s.performance: Edit paste significantly slower than competition, growing with fill of sheet,Copy 4M cells to a new book: ~5.5 minutes,
compared to LO Calc: ~6 seconds.
Think it's not dependent on the formulae, but to provide
reproducer: data structure used for test:
source:
B4: =B3 + 1
C4: =B4^2
D4: =sqrt( C4 )...Copy 4M cells to a new book: ~5.5 minutes,
compared to LO Calc: ~6 seconds.
Think it's not dependent on the formulae, but to provide
reproducer: data structure used for test:
source:
B4: =B3 + 1
C4: =B4^2
D4: =sqrt( C4 )
E4: =D4 = B4
copy B4:E4 ( ctrl-C )
paste to B5:B65536 ( ctrl-V )
copy B:E
paste to B1 in new book
paste to G1, L1, Q1 ...
First paste : ~9.5 seconds,
second paste: ~18 seconds,
each subsequent paste: ~9 seconds more than previous,
8'th paste: ~72 seconds,
data copied up here: **4M cells**, time used **~5.5 minutes**.
Could think there is some checking for formula reuse or similar,
but LO Calc uses 'shared formulas' as well.
Wouldn't complain if difference to LO Calc is 1:2 or similar,
but 1:55 and increasing with more data is inefficient.
LO Calc: first copy of 4 **1M columns** to a new book,
~6 seconds, four further copies of 4 1M columns each ~6 seconds,
not increasing, next copy is somewhat slower, ~10 seconds,
and the next one crashes ;-)
( do we have any docu available about data structure and algo
for elementary functionalities? )https://gitlab.gnome.org/GNOME/gnumeric/-/issues/739multi-table html import fails without <caption>2023-11-04T21:05:26ZJohnDenkermulti-table html import fails without <caption>***Desired and Expected Behavior***
This concerns importing an HTML file containing multiple tables.
By way of background: The following valid HTML works as desired and expected:
[tables.html](/uploads/476ec784198dea367fb90bbb6b94a1a4/...***Desired and Expected Behavior***
This concerns importing an HTML file containing multiple tables.
By way of background: The following valid HTML works as desired and expected:
[tables.html](/uploads/476ec784198dea367fb90bbb6b94a1a4/tables.html)
As you can see in these screenshots, the two tables appear as separate sheets:
![tables-xxx](/uploads/78e0ad65d699b25b405cb3e9445e2163/tables-xxx.png)
![tables-abc](/uploads/ccb28c97c0cfca7a850b5ce40926b38b/tables-abc.png)
***Undesired and Unexpected Behavior***
This applies to a version compiled from freshly-pulled git sources.
Now suppose we remove the <caption> tags. That results in the following, which is still 100% valid HTML:
[tablex.html](/uploads/2f7b6cfb6b40744bb551d52bd02b4b90/tablex.html)
Alas gnumeric interprets this incorrectly, as shown in this screenshot. The second table tramples on the first. Data is lost.
![tablex](/uploads/6a48aca2f3bf19a9924f18256b95427a/tablex.png)
***Single-Sheet Behavior***
Older versions behave differently. gnumeric version '1.12.51' puts both tables on the same page, one after another. This is sometimes desirable, and sometimes merely OK. No data is lost. I am not complaining about this.
![tablex-old](/uploads/f7a36f6bf52ad68cc1831b029705e102/tablex-old.png)
***Remarks***
The HTML standard does not require a table to have a <caption> tag.
Gnumeric should not assume a caption will be present.
The decision-making should be driven primarily by the table tag, with an assist from the caption tag if any. Note that the caption tag, if present, must come immediately after the table tag, which simplifies things.
- Take the name of the sheet from the caption, if any.
- Otherwise, take the name from the table tag's ID attribute if any.
- Otherwise, generate the table name in sequence (Sheet1, Sheet2, ...).
If two or more tables are encountered with the same name, they should be imported to the same sheet, one after another, with no trampling, as seen in the single-sheet example above.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/735plotXYsurface undocumented2023-10-30T01:48:45ZJohnDenkerplotXYsurface undocumentedThis is an issue with the documentation.
According to the gnumeric manual section 10.3.15, the Surface type of plot has two subtypes, namely plotSurface and plotXYZsurface.
The code, however, implements a third subtype, namely plotXYsu...This is an issue with the documentation.
According to the gnumeric manual section 10.3.15, the Surface type of plot has two subtypes, namely plotSurface and plotXYZsurface.
The code, however, implements a third subtype, namely plotXYsurface, which is completely undocumented AFAICT. It has been this way for years. If this is an actual feature that actual users are expected to use, it would be nice to see a few words about what its inputs and outputs should be.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/734plotSurface fails for non-monotonic x or y data2023-10-30T02:11:10ZJohnDenkerplotSurface fails for non-monotonic x or y data**Background and Expected Behavior**
The gnumeric manual section 10.3.15 documents plotSurface as follows:
```
The first subtype uses an n by 1 or 1 by n range for the x-values, a second 1 by m or m by 1
range for the y-values and an m...**Background and Expected Behavior**
The gnumeric manual section 10.3.15 documents plotSurface as follows:
```
The first subtype uses an n by 1 or 1 by n range for the x-values, a second 1 by m or m by 1
range for the y-values and an m by n range for the z values. The plotted points are constructed
from these three ranges in such a way that the z value in the ith column and jth row is combined
with the ith x value and the jth y value. This subtype then uses an m by n grid for the surface.
```
That is 100% fine as-is. Two satisfactory examples are shown in the attached .gnumeric file:
![plotXYZsurface-bugs.gnumeric](/uploads/2fe803813d59fa60ca9fcc896db66ba5/plotXYZsurface-bugs.gnumeric)
and the associated screenshot:
![hump](/uploads/96f7fb113516f9ad37294ee0658df338/hump.png)
On the 'hump' worksheet, in the special case of monotonic increasing x, the example exhibits the desired, expected, conventional, documented behavior, namely the top half of a hoop.
Similarly, in the special case of monotonic decreasing x, the example exhibits the desired, expected, conventional, documented behavior, namely the bottom half of a hoop.
Turning now to the 'hoop' worksheet, the plot shows a complete hoop. This is plotted by carrying out the documented behavior cited above, in the most simple, straightforward, direct way possible.
![hoop](/uploads/17c1d6224202e94ef01d70889112d406/hoop.png)
The x-data is known as a function of column number (i) ... and trivially as a function of (i,j).
The y-data is known as a function of row number (j) ... and trivially as a function of (i,j).
The z-data is known as a function of (i) and (j) ... tabulated explicitly.
Therefore we have [x,y,z] points in a 3D space, known as a function of (i,j).
The 3D [x,y,z] points are rotated and projected onto [u,v] space, i.e. the plane of the screen. The third coordinate in screen-space is available for hidden-surface elimination, but that's not at issue here.
The question of whether x is monotonic as a function of (i) does not arise.
The question of whether y is monotonic as a function of (j) does not arise.
The question of whether z is single-valued or known or even knowable as a function of x and/or y does not arise.
It suffices to know [x,y,z] as a function of column and row (i,j).
**Observed Bad Behavior**
Returning now to the 'hump' worksheet:
Let's try to plot the complete hoop using plotSurface. So we set the x-step in cell B30 to 20.
Alas plotSurface fails. AFAICT it fails whenever x is non-monotonic. Apparently it replaces the user's x-data with the column number (i). This happens without warning, without explanation. Of course (i) is monotonic, but it's the wrong data. Similar words apply to non-monotonic y-data.
This behavior is undocumented, undesired, unconventional, surprising, and exceedingly confusing.
It must be emphasized that a direct, straightforward implementation of the documented behavior would not exhibit this bug.
The hidden-surface elimination issue is the same whether or not x and/or y is monotonic, so it has no bearing on this discussion.
I do not know of any workarounds that I would consider practical for handling the case of non-monotonic x and/or y.
**Circumstances**
This is observed with a version compiled from freshly-pulled git sources:
```
gnumeric version '1.12.56'
datadir := '/usr/src/gnome/install/share/gnumeric/1.12.56'
libdir := '/usr/src/gnome/gnumeric'
69a456bedda13c41c79a98a1128edd9e74d2bb62 (origin/master, origin/HEAD)
Date: Sun Sep 24 13:07:14 2023 -0400
```
It is also observed with an older distro version:
```
gnumeric version '1.12.51'
datadir := '/usr/share/gnumeric/1.12.51'
libdir := '/usr/lib/gnumeric/1.12.51'
```
I suspect it has been unchanged for years.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/729Gnumeric always looks as unfocused even if it is2023-09-19T08:14:22ZEmmanuel PacaudGnumeric always looks as unfocused even if it isHi,
Running gnumeric under Fedora 38 / GNOME / Wayland, the main window always looks as if it is unfocused, with grayed text on titlebar, menubar and toolbars.
![image](/uploads/7accb51f99fb0d5d5b35863c0e7bddcd/image.png)
The applicat...Hi,
Running gnumeric under Fedora 38 / GNOME / Wayland, the main window always looks as if it is unfocused, with grayed text on titlebar, menubar and toolbars.
![image](/uploads/7accb51f99fb0d5d5b35863c0e7bddcd/image.png)
The application is still perfectly usable, though the item highlighting on mouse hovering does not work. This is with gnumeric master and gtk 3.24.38.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/728chart: cursor has offset from pull handle after leaving window frame at right...2023-09-16T12:53:39Zb. s.chart: cursor has offset from pull handle after leaving window frame at right or bottom border,We had some graph / chart / insert object related issues lately?,
think this one wasn't yet mentioned but may be related:
When inserting or resizing a chart there are handles? to pick
with the mouse pointer and pull to wanted lo...We had some graph / chart / insert object related issues lately?,
think this one wasn't yet mentioned but may be related:
When inserting or resizing a chart there are handles? to pick
with the mouse pointer and pull to wanted location.
When I 'leave the sheet' with the clicked pointer it comes back
'out of sync' to the pulling mark. That happens at right and
bottom border, when re-entering the sheet the cursor has some
offset towards the handle it's pulling, may be related to the
distance the sheet went scrolled while cursor outside.
Best shown on two pictures, the cursor which is not catched in the
screenshots but is in the center of the magenta circles is 'in sync'
with the right bottom pulling circle ( green dot ) in
![graph_pull_in_sync](/uploads/bd3497ecbdb5cb5a4c44e4a4dcb5b64b/graph_pull_in_sync.png),
but off from it in the next picture, the cursor pointing to I6:I7
still pulls! the green dot handle at I17. Also happens with cursor
'out' and opposite offset.
![graph_pull_out_of_sync](/uploads/50cf065e63f211bdf76d3ed683c3e722/graph_pull_out_of_sync.png)
If relevant: I'm using a 4k screen without special settings.
Gnumeric is actual 1.12.56 and appr. goffice on Kali / debian linux,
rechecked with fresh pulled goffice and gnumeric from today.
Also rechecked with another install on ubuntu ( 22-04 LTS ).
Add. but likely unrelated I got some warnings in the
terminal gnumeric was started from, happened when I'd hold the
cursor above top of window to scroll the sheet back.
```
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GnmPane': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkGrid': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkNotebook': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkWindow': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GnmPane': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkGrid': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkNotebook': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkWindow': NULL pointer
```
poss. related: #679,
and the following observation which is likely https://gitlab.gnome.org/GNOME/goffice/-/issues/54 .
but I'd rather see scaling of cursor moves than offset there.
When editing the graph properties in the dialog cursor move and handle move isn't in sync,
making it difficult to find a working point to click once you'd let go.
here cursor and clickpoint match:
![graph_graphical_editing_1](/uploads/6ff88438835e75ca1564c143ae775ad4/graph_graphical_editing_1.png)
and here after some small pull they are off:
![graph_graphical_editing_2](/uploads/e42ada280110cb670c1a3b4d87ce75e2/graph_graphical_editing_2.png)https://gitlab.gnome.org/GNOME/gnumeric/-/issues/724formula works in libreoffice calc, but not in gnumeric.2023-09-04T20:24:54ZG Gformula works in libreoffice calc, but not in gnumeric.=INDEX({1,2,3,4,5},MATCH(0,COUNTIF({1,2,3},{1,2,3,4,5}),0))=INDEX({1,2,3,4,5},MATCH(0,COUNTIF({1,2,3},{1,2,3,4,5}),0))https://gitlab.gnome.org/GNOME/gnumeric/-/issues/723Forcing gnumeric to load a virtual environment python3 instance2023-09-04T20:02:50ZGian Luca RocchiForcing gnumeric to load a virtual environment python3 instanceI'm on a Debian 12 distro, using gnumeric-1.12.55 and trying to use a python module which is not packaged in Debian system, namely CoolProp. At the end, the workaround of creating a pseudo-segregated environment with the scheme as sugges...I'm on a Debian 12 distro, using gnumeric-1.12.55 and trying to use a python module which is not packaged in Debian system, namely CoolProp. At the end, the workaround of creating a pseudo-segregated environment with the scheme as suggested in /usr/share/doc/python3.11/README.venv:
> e.g. instead of running: $ pip install --user foo
>
> run:
>
> $ mkdir -p \~/.venvs
>
> $ python3 -m venv \~/.venvs/foo
>
> $ \~/.venvs/foo/bin/python -m pip install foo
did the job of installing the wanted python module. The problem now is: how to tell gnumeric to spawn the virtual environment (venv) python instance while loading a gnumeric python plugin which relies on the above python module. I tried to navigate the relevant gnumeric plugin loader source code without being able to get off the sticky mud. I just noticed that once the Python_functions plugin is used, by calling one of the functions contained in, the combo selector in the Python console is giving a chance to choose the interpreter. I'm confused about the possibility I may have to solve this issue. I need some experienced programmer to suggest some path to go forward.
Thank youhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/718ticks wrongly positioned, depending on format2023-07-08T00:32:20ZJohnDenkerticks wrongly positioned, depending on format![tick-format](/uploads/b22de228abc950ca983dcf6e6e551d5a/tick-format.png)
[tick-format.gnumeric](/uploads/b260ef2a81eb3fdea83191b0fad9cc4f/tick-format.gnumeric)
Consider the spreadsheet in the attached image and, equivalently, in the a...![tick-format](/uploads/b22de228abc950ca983dcf6e6e551d5a/tick-format.png)
[tick-format.gnumeric](/uploads/b260ef2a81eb3fdea83191b0fad9cc4f/tick-format.gnumeric)
Consider the spreadsheet in the attached image and, equivalently, in the attached .gnumeric file.
In the left graph, on the lower X axis (shown in black), the tick marks are positioned at integer multiples of the tick spacing, even though Xmin is not an integer multiple. This is the normal, desired, expected behavior. The upper X axis (shown in blue) is also just fine. So far so good.
The right graph was created by copy-pasting the left graph and making one small change, namely the formatting of the lower (black) X tick labels. This exhibits abnormal, undesired, and unexpected behavior:
- Changing the format changes the position of the ticks. This should never happen. Positioning should be independent of formatting.
- The X tick marks are not positioned at integer multiples of the X tick spacing. This should never happen.
Note that this bug can easily produce false and misleading graphs, as shown by this example. The data points are wrongly positioned relative to the labeled ticks.
**Workaround**
The upper (blue) X axis is created by an "Axis Line" (not the basic axis feature). This gives explicit control over tick positioning. The ticks remain where they should be, independent of formatting.
**Circumstances**
This is observed with freshly pulled git sources, and also with a years-old distro version.
```
:; uname -srmo
Linux 5.19.0-45-generic x86_64 GNU/Linux
:; lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy
:; gnumeric --version
gnumeric version '1.12.51'
datadir := '/usr/share/gnumeric/1.12.51'
libdir := '/usr/lib/gnumeric/1.12.51'
```https://gitlab.gnome.org/GNOME/gnumeric/-/issues/716apostophe aka single-quote disappears i.e. explicit literal string becomes im...2023-11-04T20:40:10ZJohnDenkerapostophe aka single-quote disappears i.e. explicit literal string becomes implicit, which it shouldn'tPlease refer to the attached example:
[bad-unquote.gnumeric](/uploads/9f330eba4ce6ae22611fb0e08be6d211/bad-unquote.gnumeric)
In cell B2 use an apostrophe to enter the explicit literal string:
```
'2023/jan/1
```
This is recognized as be...Please refer to the attached example:
[bad-unquote.gnumeric](/uploads/9f330eba4ce6ae22611fb0e08be6d211/bad-unquote.gnumeric)
In cell B2 use an apostrophe to enter the explicit literal string:
```
'2023/jan/1
```
This is recognized as being a string and a valid date.
Copy B2 to B4 and lengthen the month name to january.
This is no longer a valid date. It is still a string. The apostrophe has disappeared, which is odd and alarming.
Copy B4 to B6 and change the day number. The apostrophe is still gone.
Copy B6 to B8 and shorten the month name back to jan.
This goes back to being a valid date, but it is no longer a string. This is unexpected and undesirable. This causes problems if you want to edit the expression, because the representation has changed. The new representation is probably locale-dependent. It causes additional problems if there is explicit type-checking using the `TYPE()` function, and when the string is concatenated using the `&` operator.
A similar scenario plays out in cells B14, B16, and B18. Explicit string becomes implicit string becomes non-string.
**Desired behavior**
The apostrophe should be sticky. When something is an explicit literal string, it should remain an explicit literal string unless and until the user edits out the apostrophe. It should remain an explicit literal string even if it would be recognized as implicitly necessarily a string.
To say the same thing the other way,
```
'2023/january/1xx
'2023/jan/1
'foobar
```
should be different from
```
2023/january/1xx
2023/jan/1
foobar
```
and should remain different. The distinction is important because it affects editing, type-checking, and concatenation.
**Workaround:**
In my application there are partial workarounds, but they are ugly, involving additional cells and constructing a string by concatenation.
**Circumstances**
This is observed with both (a) freshly-pulled git sources and (b) a years old distro version:
```
gnumeric version '1.12.51'
datadir := '/usr/share/gnumeric/1.12.51'
libdir := '/usr/lib/gnumeric/1.12.51'
```https://gitlab.gnome.org/GNOME/gnumeric/-/issues/712UI: marking active / focussed cell by 'bordering' partly lost when autofilte...2024-01-12T09:16:30Zb. s.UI: marking active / focussed cell by 'bordering' partly lost when autofilter active,It's weird behavior, sometimes partly in the filtered area,
sometimes partly below, mostly right to the displayed data,
sometimes visible when scrolling up with the cursor key,
and hidden when scrolling down, mostly the color marki...It's weird behavior, sometimes partly in the filtered area,
sometimes partly below, mostly right to the displayed data,
sometimes visible when scrolling up with the cursor key,
and hidden when scrolling down, mostly the color marking of
the column header is kept, while the marking of the row
number disappears or stays with wrong rows ...
In parallel the cell content isn't shown in the cell when
editing such cells ( F2 ), only in the formula bar.
might be dependent of somewhat bigger size of the filtered area!
related to #694 ??https://gitlab.gnome.org/GNOME/gnumeric/-/issues/708Internal links:, referencing:, UI: adapt internal links when copying cells - ...2023-05-14T06:18:33Zb. s.Internal links:, referencing:, UI: adapt internal links when copying cells - enhancement proposal.Short: would like relative references in 'internal links' to
be adapted for copies in the same manner as formulas are.
Actual observed: kept as absolute. Simple reproducer:
new sheet,
'1' in B2,
'=B2' in C2,
right-click C2 an...Short: would like relative references in 'internal links' to
be adapted for copies in the same manner as formulas are.
Actual observed: kept as absolute. Simple reproducer:
new sheet,
'1' in B2,
'=B2' in C2,
right-click C2 and 'Add Hyperlink', internal, to B2,
left click on C2 now jumps to B2.
Copying C2 to C3 adapts the formula to a
new 'same relative' position, 'B3', and the displayed result
changes to '0', but the link reference is kept unchanged to B2,
left-clicking C3 doesn't jump to B3 as simple minded users might
expect, but to B2.
Would like to see:
Link changed to 'B3' as well, click jumping to B3.
<details><summary>Long: - Click to expand</summary>
The general concept in gnumeric is 'referential integrity'?
Keeping 'absolute' references intact when copying or moving
cells, while relative references are adapted for moves and
'created new' - to same relative! position - for copies.
Same does not apply when copying cells containing 'internal links',
relative references in the link are kept like absolute also
in copying.
My use case: I'd like to produce some 'hierarchical structur'
where pairs of cells bilateral linking to the partner could serve to
jump from the table of contents to a chapter, and back from there
to the index-point in the table of contents. Producing them by
multiple copies would be much more convenient than manual edit.
</details>https://gitlab.gnome.org/GNOME/gnumeric/-/issues/707Zoom problems with 1.12.55 (and previous)2023-05-10T03:21:10ZJim DiamondZoom problems with 1.12.55 (and previous)Gnumeric seems to have a hard time keeping track of the zoom amount, at least on my system (Slackware64 15.0), when an expression creates a result too big to fit in the cell's width. To reproduce the problem:
1. start up gnumeric
2. set...Gnumeric seems to have a hard time keeping track of the zoom amount, at least on my system (Slackware64 15.0), when an expression creates a result too big to fit in the cell's width. To reproduce the problem:
1. start up gnumeric
2. set the zoom to 150%
3. put 1234 in cell A1
4. manually make column A just a bit bigger than needed for 1234
5. put =1234*567 in A2: A2 should now display a bunch of # signs, but they are apparently unzoomed.
6. Expand column A wide enough for 1234*567 to be displayed.
And now both A1's 1234 and A2's 699678 are shown (apparently) unzoomed.
(Resetting the zoom to something other than 150% and then back to 150% restores the proper size.)
The same thing happened with V 1.12.53. I don't have any older versions to check.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/706Number format resets when unrelated changes made to range in Format Cells dialog2023-09-09T16:03:17ZKevin DaughtridgeNumber format resets when unrelated changes made to range in Format Cells dialogInput numbers in two or more contiguous cells. Change the number format from the default on one or more, but not all, of those cells. Select all the cells. Open the Format Changes dialog. Make one or more changes in tabs other than the N...Input numbers in two or more contiguous cells. Change the number format from the default on one or more, but not all, of those cells. Select all the cells. Open the Format Changes dialog. Make one or more changes in tabs other than the Number tab. Click OK or Apply. The changes will be applied, but the number format on all the cells in the range will be reset to the default.
No other settings from the dialog are similarly reset. If the number format is consistent across the range, it is not reset. The equivalent toolbar buttons for these settings do not reset the number format, but of course they do not cover the full range of possible settings (especially for borders).https://gitlab.gnome.org/GNOME/gnumeric/-/issues/704Excel compatibility: MS has additional functions FLOOR.PRECISE, FLOOR.MATH, C...2023-04-05T07:26:12Zb. s.Excel compatibility: MS has additional functions FLOOR.PRECISE, FLOOR.MATH, CEILING.PRECISE, CEILING.MATH,If I understand right they wanted to spread sufficient confusion and implemented the above functions.
If I'd read well for *.PRECISE the significand is optional ( in Excel normally required ) and *.MATH work with an add. optional param...If I understand right they wanted to spread sufficient confusion and implemented the above functions.
If I'd read well for *.PRECISE the significand is optional ( in Excel normally required ) and *.MATH work with an add. optional parameter 'MODE', steering the rounding direction for negative operands.
If I looked correct gnumeric handeles Excels ERF.PRECISE and ERFC.PRECISE functions, but not the add. functions for FLOOR and CEILING.
Just spotted, can't say if and how important ... but evtl. gnumerics FLOOR and CEILING match better with Excels *.PRECISE?https://gitlab.gnome.org/GNOME/gnumeric/-/issues/702UI: cell formatting: oddity when copying row height and / or column width,2023-09-27T07:41:10Zb. s.UI: cell formatting: oddity when copying row height and / or column width,cell with edited row height and column width.
I.) copy to other location on same sheet ( ctrl-C - ctrl-V ): row height and col width **not** copied.
expected: copy height and width same way as other formattings.
II.) copy to oth...cell with edited row height and column width.
I.) copy to other location on same sheet ( ctrl-C - ctrl-V ): row height and col width **not** copied.
expected: copy height and width same way as other formattings.
II.) copy to other sheet in same workbook: row height and col width **not** copied.
expected: copy height and width same way as other formattings.
III.) copy to other workbook: row hight and col width **not** copied.
expected: copy height and width same way as other formattings.
IV.) copy to other instance / other ver. of gnumeric, or 'copy - close and reopen program - paste':
a.) same position: row height and col width **copied, not undoable**.
expected: undoable as other copied formattings.
b.) other position e.g. origin was B2, paste to D4: row height and col. width copied **to 'source position'** - B2,
**off from 'content position'** - D4, **not undoable**.
expected: same position as content and undoable as for other formattings.
See picture ( case IV.b. ) and sample file: [formatting_inconsistent_for_copies_2.gnumeric](/uploads/95345fb385188e7b96ee1b490077d5c4/formatting_inconsistent_for_copies_2.gnumeric)
![copy_formattings_problem_2023-03-30_16-01-15](/uploads/c7fde664d9731c651d7d85294b4d3fb4/copy_formattings_problem_2023-03-30_16-01-15.png)
ver.: actual 1.12.56 dev.