Bug 34449 - request new feature: ability deleting borders of cell from adjacent cell
Summary: request new feature: ability deleting borders of cell from adjacent cell
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high enhancement
Assignee: Dennis Francis
URL:
Whiteboard: target:5.2.0 unitTestNotes:25
Keywords:
: 67501 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-18 06:39 UTC by sasha.libreoffice
Modified: 2023-10-17 07:16 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
example of cell borders problem (15.16 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-06-20 23:21 UTC, sasha.libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2011-02-18 06:39:56 UTC
Often when I open existing document and try to delete borders from cell, I found that I can not. Border my be deleted only from cell, where were created. It my be big problem for beginners, and experienced users it slows down.

Please, add ability to delete border of cell from adjacent cell.
Comment 1 Björn Michaelsen 2011-12-23 11:49:22 UTC Comment hidden (obsolete)
Comment 2 sasha.libreoffice 2012-01-01 22:46:28 UTC
remains in LibO 3.5.0 beta 1 in Writer and in Calc
Comment 3 Joel Madero 2012-06-20 11:25:55 UTC
Can you provide a test document with instructions on how to reproduce? Not quite following the issue. Thanks!
Comment 4 sasha.libreoffice 2012-06-20 23:21:12 UTC
Created attachment 63282 [details]
example of cell borders problem
Comment 5 Florian Reisinger 2012-08-14 14:01:52 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 14:02:55 UTC Comment hidden (obsolete)
Comment 7 Florian Reisinger 2012-08-14 14:07:29 UTC Comment hidden (obsolete)
Comment 8 Florian Reisinger 2012-08-14 14:09:35 UTC Comment hidden (obsolete)
Comment 9 sasha.libreoffice 2012-08-16 08:36:03 UTC
reopening because it is RFE
Comment 10 Joel Madero 2012-10-14 19:31:47 UTC
I can confirm this, not sure how we would solve it and how often this happens. Took me a few times to realize what you had done with the borders. Enhancement request, low priority. If someone has a suggestion on how to actually implement an enhancement, feel free to suggest
Comment 11 Florian Reisinger 2012-10-20 08:54:27 UTC
Okay I got it. If a right border is added from B9 you expect to delete it from C9, because it is also its left border.

IMHO importance is high...
Comment 12 tilus06 2013-08-03 13:54:14 UTC
(In reply to comment #10)
> I can confirm this, not sure how we would solve it

Hello! I found out what cause this problem (and some more), and what is the solution. Right now, you can set 2 border lines between adjacent cells, because every cell has its 4 own borders. These 2 border lines are placed on the same spot, on each other, so you cannot tell if that line is A2's bottom border or A3's top border or both. And if you set 2 border lines between adjacent cells, and one of them is thicker, then the thinner will not displayed, because these lines are placed on each other. And if you set a red and a black line, and these lines has the same width, you cannot really tell which one will displayed. You can found some different bugreports that caused by the wrong implementation to handle cell borders.
These bugs can be solved by another implementation: adjacent cells' border should be a common attribution. If you set B2's bottom border, then it means you also set B3's top border. So insted of 4 own border lines, there is 4 common border lines. (Except for example A1, because it has 2 own and 2 common border lines.) That is how Excel works, and how Calc should works. For more info and pictures, see my bugreport: Bug 67501 - CONFIGURATION: Wrong implementation to handle cell borders.
I think this is a high priority bug.
Comment 13 Joel Madero 2013-08-04 20:34:29 UTC
Hm - I'm still not seeing this as a high priority bug. The product works as it was designed to work - you can argue that it can work better (and I'm convinced it can) but that makes it an enhancement. Even if it was a bug, according to the flowchart that many of us use it's a minor bug (perhaps minor - highest, as it can affect a lot of people) but none the less, not critical IMHO - there is a workaround that's relatively straight forward (you just have to check borders for multiple cells, yes a pain in the butt at times) but really - a straight forward workaround that makes it so the "bug" or enhancement doesn't prevent high quality work compared to bugs such as crashes of the product, memory leaks, or bugs that prevent high quality work (with no feasible workaround) are more important.

But I'm not the only one who has a say here ;) Other QA members are already cc'ed on the bug so if one of them feels different - they can do as they see fit :)


Best,
Joel
Comment 14 ign_christian 2013-08-05 02:37:34 UTC
Bug 67501 should be a replicate / duplicate to this bug.
Comment 15 Florian Reisinger 2013-08-05 05:55:22 UTC
*** Bug 67501 has been marked as a duplicate of this bug. ***
Comment 16 tilus06 2013-08-05 11:54:52 UTC
(In reply to comment #13)

You are right. This is not a bug, because the product works as it was designed to work. But the problem is, the product was incorrectly designed. An avarage user expecting if he/she set a bottom border, he/she also set a top border too, because there is only one border between neighbouring cells. The same with left and right borders. This is how Microsoft's Excel, Google Docs, Gnumeric, Calligra Suite (KOffice), Kingsoft Office and so on, and so on works. It affects a lot of people, and the workaround is waste of time, and time is money. This is the reason I think, it is a high priority task to redesigne border handling. It is not so difficult, still makes Calc a lot better, and prevents false bugreports. And do not forget interoperability.
Comment 17 Jorendc 2013-08-05 16:36:03 UTC
I do agree this would be a valuable enhancement. It does make sense and feels more "natural".

But I don't see why we have to place this bug on the MAB (most annoying _bugs_). I'm convinced that enhancement requests does _not_ belong on a MAB. I read all use cases, and I do agree this is in some cases quite annoying, and this enhancement request is great to have in LibreOffice... but it is still not a bug.

The way we have to destinguish between enhancement requests like 'how it would reflect on the users' and 'how many users would benefit from it' is to change the priority of it. Therefore I'm going to mark this as ENHANCEMENT HIGHEST and remove it from the MAB.

Thanks for your understanding

Kind regards,
Joren
Comment 18 tilus06 2013-08-15 11:51:37 UTC
(In reply to comment #17)

Thank you. That is what I wanted. Where can I find this Enhancement highest list? I found something, but I think that is something else. (Vote for Enhancement @ wiki.documentfoundation.org)
Comment 19 Björn Michaelsen 2014-01-17 00:43:54 UTC Comment hidden (obsolete)
Comment 20 Dennis Francis 2015-10-31 22:28:45 UTC
I have submitted a preliminary patch at https://gerrit.libreoffice.org/#/c/19715/
Comment 21 Commit Notification 2015-12-07 13:51:24 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2e512174f2116d86682037459fd5ab5164e9f510

tdf#34449 : ability of deleting borders of a cell from adjacent cell

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Eike Rathke 2015-12-07 13:53:56 UTC
@Dennis:
Could you please also add a feature description to https://wiki.documentfoundation.org/ReleaseNotes/5.2#Calc best with a screenshot of the dialog pointing out the new checkbox?
Thanks.
Comment 23 Commit Notification 2015-12-07 18:48:05 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=da150e5e30cd1c56e5dc6de7201af58bf98b291a

fix build, don't pass int as sal_uInt16, tdf#34449 follow-up

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 24 Dennis Francis 2015-12-08 00:10:06 UTC
(In reply to Eike Rathke from comment #22)
> @Dennis:
> Could you please also add a feature description to
> https://wiki.documentfoundation.org/ReleaseNotes/5.2#Calc best with a
> screenshot of the dialog pointing out the new checkbox?
> Thanks.

Done. Marking this as resolved-fixed.

Thanks,
Dennis
Comment 25 Buovjaga 2023-10-17 07:16:58 UTC
Notes for unit test writers:

Nothing to revert here, you would be testing a new option.