After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 143220 - Operations on regions with hidden content
Operations on regions with hidden content
Status: RESOLVED OBSOLETE
Product: Gnumeric
Classification: Applications
Component: Main System
git master
Other All
: Normal enhancement
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 149824 315853 642532 645970 669912 685488 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-05-26 16:57 UTC by Luis Mendes
Modified: 2018-05-22 13:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
An attempt to implement 'Copy Visible' (10.71 KB, patch)
2012-12-26 15:08 UTC, Valek Filippov
none Details | Review

Description Luis Mendes 2004-05-26 16:57:06 UTC
Hi, 
 
I'll try to give an example: 
 
 
cols    1               2               3 
rows 
1       colors          nr cars         cost each 
2       green           2               10.000 
3       blue            4               15.000 
4       yellow          1               25.000 
5       green           10              30.000 
6       black           7               7.000 
 
then I select Auto Filter, so thar the first row is the title row. 
if I want to remove all the rows containing green cars, I would filter in 
the color column by green, which gives me: 
 
cols    1               2               3 
rows 
1       colors          nr cars         cost each 
2       green           2               10.000 
5       green           10              30.000 
 
then I select rows 2 through 5 and delete them. 
 
I was expecting the result to be (as it is in Excel since version 97 as Dave 
told us): 
 
cols    1               2               3 
rows 
1       colors          nr cars         cost each 
2       blue            4               15.000 
3       yellow          1               25.000 
4       black           7               7.000 
 
the green lines would have disappearesd and a row renumbering proccess would 
have taken place. 
 
But in Gnumeric, instead, what I get is: 
cols    1               2               3 
rows 
1       colors          nr cars         cost each 
2       black           7               7.000 
 
All the rows between the firs and the last "green" ones were deleted.  Which 
is:  gnumeric removed not only the visible (green) but also what was not 
visible (rows containing blue and yellow cars).
Comment 1 Luis Mendes 2004-05-26 16:58:43 UTC
I though I had reported it in March, but I can't find the report. 
 
This is a MUST in a spreadsheet. 
Comment 2 Andreas J. Guelzow 2004-05-26 17:24:42 UTC
If I "select rows 2 through 5 and delete them", I would expect rows 2 through 5
to be deleted. Apparently you are not happy with that. [Personally I could not
care less that some other programs don't do what you ask of them.]  

If this weren't in an autofilter situation would you also expect hidden rows to
remain after you deleted a section of spreadsheet?
Comment 3 Morten Welinder 2004-05-26 17:26:54 UTC
Lowering prioritym fixing OS, etc.
Comment 4 Luis Mendes 2004-05-26 17:37:08 UTC
Comment to comment #2 from Andreas Guelzow 
 
No, I'm not happy that gnumeric doesn't perform as it was supposed to. 
 
You say you don't care, probably you don't work with big spreadsheets, because 
if you did, you could see the difference. 
 
If it is because I refered Excel, I must say that probably you don't dislike 
Microsoft much more than I do.  But Excel is still the benchmark.  Otherwise 
prove I'm wrong. 
Comment 5 Jody Goldberg 2004-05-26 17:51:21 UTC
Andreas : Having a distinction between filtered and hidden seems useful.  I
think this is a bug.  This sort of operation is reasonably common.  I suppose a
user could do some sort of search then use alt-space to select the rows and try
to delete (although we do not support discontinuous deletions either).  We
should support this.  However, it is definitely not a 1.2 level change.  The
ins/del col/row code took a long time to handle all the vagaries.  We'll try to
work it in for 1.3.x
Comment 6 Andreas J. Guelzow 2004-05-26 19:09:35 UTC
Wouldn't it be simpler (both from an implementation and an user interface point
of view) to have a "Delete Visible"? 
Comment 7 Jody Goldberg 2004-05-26 20:18:31 UTC
The implementation is the same either way.  we need to add support for
discontinuous col/row deletion.  I like the notion of del vs del visible.  The
down sides are

- ui gets kinda cluttered.  There is already alot in that context menu
- we'd loose some XL finger feel.  This seems manageable if we make it really
obvious.
Comment 8 Luis Mendes 2004-05-26 23:40:33 UTC
I think that the 'del visible' should be the default option.  If the other 
option is also possible, it would be nice, although I don't see any 
usefulness. 
Comment 9 Jody Goldberg 2004-06-08 16:36:32 UTC
hmm we have not considered offering a 'del visible' the current choice was
- delete all
- delete unfiltered

The latter != visible.  In XL there is a marked difference between hiding a
col/row manually and filtering them.  The former will be deleted in this case
the later will not.
Comment 10 Luis Mendes 2004-08-30 23:08:09 UTC
So, Jody, are you saying that if I want to delete visible rows I have to filter 
them in the opposite way? 
 
The visible filter is not only useful for deleting but, for example, to paste 
values to a column. 
 
In the example given, suppose you want to fill in a fourth column with type of 
fuel used.  You could right in a cell 'diesel' then copy it, filter the list 
for all green and black cars and then paste the contents of that cell to the 
fourth column in the filtered rows.  I would expect not to fill the 4th col of 
other rows with 'diesel'.  As it is right now, Gnumeric will do such, which is 
very complicated for a user dealing with large sheets. 
 
Comment 11 Luis Mendes 2004-08-30 23:10:00 UTC
sorry, correction: instead of right it is write 
Comment 12 Morten Welinder 2008-09-11 01:03:17 UTC
*** Bug 149824 has been marked as a duplicate of this bug. ***
Comment 13 Andreas J. Guelzow 2009-09-24 07:10:12 UTC
*** Bug 315853 has been marked as a duplicate of this bug. ***
Comment 14 Julien Olivier 2010-02-10 22:29:03 UTC
This is a very annoying bug, and it is also very difficult to understand what's wrong when you don't know about it. So I'm a bit surprised to see that 6 years after the bug has been reported, it's still not fixed. Is it worked on? Or does nobody care?
Comment 15 Kevin Shook 2010-07-21 04:52:21 UTC
This is one of the few real deficiencies in Gnumeric. The priority of Normal is far too low, and it is NOT an enhancement. It is a prominent feature which was never implemented properly.
Comment 16 Andreas J. Guelzow 2010-07-21 06:16:46 UTC
Julien, Kevin,

Am I correct in assuming that you are working on a patch for this? (Personally I rather fix bugs that I think are indeed bugs.) 

And clearly something that doesn't exist in Gnumeric can't be a prominent feature of Gnumeric. He request of making it a feature is clearly an enhancement.
Comment 17 Kevin Shook 2010-07-22 03:19:28 UTC
I'm only a user, sorry. If I could contribute some other way (such as financially) to solving this problem, I happily would.

I was just trying to increase the emphasis on a deficiency which has been around for a long time.
There are several duplicates, but the problem is that the filter (which is what I meant by a feature) just isn't useful.
If you can't copy or delete or restrict the application of a function to the filtered values, the the filter is effectively useless.

It's too bad as otherwise gnumeric is far and away my favorite spreadsheet, and I use it every day for my work.
Comment 18 Andreas J. Guelzow 2010-07-22 05:16:04 UTC
Note that the SUBTOTAL function ignores the filtered-out rows.

There are very few people that currently write code for Gnumeric. So obviously fixes and enhancements affected those people take precedence. And none of them seems to be concerned about this deficiency.
Comment 19 Julien Olivier 2010-07-22 22:34:51 UTC
Andreas, you are wrong in assuming that I am working on a patch for this bug. Bugzilla is a bug reporting system and I'm only doing what I am supposed to do with it: describing bugs, and making sure the developers are aware of them. As for fixing the bug, I've got already enough work with fixing the bugs reported by the users of my own applications, because the lazy users don't seem to want to fix them themselves :)
Comment 20 Andreas J. Guelzow 2010-07-22 22:52:57 UTC
Julien,  the original report was an enhancement request. Your comment (comment #14) did not add anything to that request (except that it could be read as an insult).
Comment 21 Julien Olivier 2010-07-23 10:01:27 UTC
Well, it was certainly not an insult. I was just expressing my surprise, seeing how it seems to me to be a real showstopper (and certainly not an enhancement), and that no work seems to be done on it (which, by itself, is understandable if no developer cares about this bug). The goal of my comment was only to try to get some attention to a (major) bug that seemed to have been ignored by the developers.
Comment 22 Kevin Shook 2010-07-23 14:45:31 UTC
Ditto from me. There appears to be a difference of opinion due to differing perspectives. In the opinion of the developers, the filter is complete and enhancements are being requested. In the opinion of users, the feature is incomplete as it is not usable.

I just want to give a user's perspective as this deficiency is a major problem for us, and it needs to be addressed.
Comment 23 Andreas J. Guelzow 2010-07-24 18:47:32 UTC
I believe that the actions that should optionally avoid acting on rows that are filtered out are:

1) clearing   [Can be restricted to filtered rows in 1.10.8 and later]
2) deleting
3) copying
4) counting, adding, etc. [Can be done using SUBTOTAL, but requires manual recalc]

Are there any others that you find desirable?
Comment 24 Kevin Shook 2010-07-24 19:22:14 UTC
Thanks Andreas, those are the major ones.
Statistical functions (st dev etc) would also be useful. It would also be useful if the filtered out values weren't graphed, but this may open another can of worms.
Comment 25 Andreas J. Guelzow 2010-07-24 20:35:00 UTC
the statistical functions need to be Excel and/or OpenFormula compatible. There are no provisions in the OpenFormula draft standard to exclude any hidden or filtered out rows. So to provide for that a different mechanism than changing the formula behaviour would need to be used.

Note though that the subtotal function provides for some of the statistcal functions:
	1   AVERAGE
	2   COUNT
	3   COUNTA
	4   MAX
	5   MIN
	6   PRODUCT
	7   STDEV
	8   STDEVP
	9   SUM
	10   VAR
	11   VARP

Charting is a completely different issue.
Comment 26 Kevin Shook 2010-07-24 21:00:03 UTC
That's fine - the subtotal is perfectly usable.
The most important functions are the ones you identified, especially the copy/delete.

Thanks.
Comment 27 Andreas J. Guelzow 2011-02-17 06:29:59 UTC
*** Bug 642532 has been marked as a duplicate of this bug. ***
Comment 28 Andreas J. Guelzow 2011-03-28 17:27:06 UTC
*** Bug 645970 has been marked as a duplicate of this bug. ***
Comment 29 Andreas J. Guelzow 2012-02-11 23:24:25 UTC
*** Bug 669912 has been marked as a duplicate of this bug. ***
Comment 30 Andreas J. Guelzow 2012-10-04 19:20:32 UTC
*** Bug 685488 has been marked as a duplicate of this bug. ***
Comment 31 Valek Filippov 2012-12-26 15:08:19 UTC
Created attachment 232246 [details] [review]
An attempt to implement 'Copy Visible'

I didn't add an entry to context menu, only to main 'Edit'.
Keyboard shortcut is 'shift-control-C'.

Xclipboard will have only visible cells.
gnumeric range still keeps empty rows/cols for hidden cells. If cells contain formulas referring  to hidden cells, result of pasting will have incorrect calculations.
Comment 32 dangerrat 2014-11-13 07:38:13 UTC
I am also highly interested in being able to copy/paste only the visible rows. Valek seems to have sent in a proposal to fix in 2012. I can not yet find these options in gnumeric. Will the fix he sent be implemented?

It seems to feature an option to only Copy the items that are Visible, which would be a very practical feature.
Comment 33 GNOME Infrastructure Team 2018-05-22 13:06:39 UTC
-- 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/gnumeric/issues/25.