Bug 113606 - TOOLBAR: Handling of icon "borders" in the table toolbar should be improved (see comment 4)
Summary: TOOLBAR: Handling of icon "borders" in the table toolbar should be improved (...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.2.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 141392 (view as bug list)
Depends on:
Blocks: Toolbar-Border-Controls
  Show dependency treegraph
 
Reported: 2017-11-02 15:59 UTC by Christian Lehmann
Modified: 2021-04-23 08:37 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Lehmann 2017-11-02 15:59:35 UTC
In a Writer table, I mark two vertically adjacent cells currently separated by a black line, which latter I want to eliminate.
The Table symbol bar contains a symbol of a black and red bordered square, which I click.
The eleventh symbol there shows the horizontal line separating the cells in white. I click it. Nothing happens. (If instead I walk through the menu 'Table - Properties - Borders - User defined' and click the central horizontal line away, it does disappear from the table.)
Comment 1 Dieter 2017-11-03 06:35:10 UTC
I don't know what symbol you think of. To eleminate the black line between the two sells choose "Borders (Shift to overwrtite)". Press Shift and the specific icon to remove the black line.

Set to WORKSFORME. Please change it back to UNCONFIRMED if the description doesn't solve your problem.
Comment 2 Christian Lehmann 2017-11-03 08:54:46 UTC
I can see that it does work if Shift is pressed, and thus withdraw the bug report with apologies.
However, what then is hitting any of those icons supposed to do if Shift is not pressed? I could not detect any effect.
Comment 3 Dieter 2017-11-04 07:44:06 UTC
You can use them, if you have a table without borders. I must admit, I don't know, why it is necassary to differ between table without borders and overwriting borders. Wozld be more userfriendly, if you can also overwrite borders without pressing shift. Might be a proposal for an enhancement. But I hven't checked, if this proposal already exists.
Comment 4 Christian Lehmann 2017-11-04 09:19:28 UTC
Okay, can we turn this into an enhancement proposal?

Current situation: The functionality of the icon 'Borders (Shift to overwrite)' on the Table Icons bar is not transparent.

Suggestion: The simplest solution would seem to be: On pressing the icon on the bar, the user is shown the section 'User defined' of the dialog box that he gets to see if he walks through the menus 'Table - Properties - Borders'. The icon on the bar would be just a shortcut to this part of the box, whose functionality is immediately transparent.
Comment 5 Yousuf Philips (jay) (retired) 2017-11-05 10:06:40 UTC
(In reply to Christian Lehmann from comment #4)
> Suggestion: The simplest solution would seem to be: On pressing the icon on
> the bar, the user is shown the section 'User defined' of the dialog box that
> he gets to see if he walks through the menus 'Table - Properties - Borders'.
> The icon on the bar would be just a shortcut to this part of the box, whose
> functionality is immediately transparent.

The intent of the group button's expansion is to give easy access to a few common border options, with the more advanced features being available in the dialog. So for me, i wouldnt agree with this enhancement.

Heiko, Stuart, Adolfo: thoughts?
Comment 6 Dieter 2017-11-05 10:17:16 UTC
What is at least necessary is the following:
If you press the button, the different border styles appears with the heading "Borders". It should be renamed to "Borders (Shift to overwrite)" (the same as the toolbar icon), because as the original bug report shows, a lot of people (including me some months before) immedeatly press the icon button "Borders" and don't realize the additional "Shift to overwrite" information.
Comment 7 Christian Lehmann 2017-11-05 16:25:19 UTC
I can see Yousuf's point. But if the idea is to present a set of common border layouts for a one-click selection, then I still do not understand why we need two different behaviors for clicking and shift-clicking. Why doesn't it suffice for the user to force one of the schemes presented onto his selected cells, regardless of how they are formated theretofore?
Comment 8 Heiko Tietze 2017-11-06 12:09:28 UTC
The full caption "Border (Shift to override)" (localized) is too long for the widget, and we also shouldn't resize it. The common workflow is to apply a border style and not to have the "hidden gem" feature of modifying the outer border. So either we drop the shift modifier or keep things as it. There is not much to say against a "more" button to go into the table properties dialog.
My opinion: WFM.
Comment 9 Christian Lehmann 2017-11-06 12:19:51 UTC
Dropping the shift modifier and adding a 'more' button leading to the full properties menu seems a good compromise.
Comment 10 Telesto 2018-11-07 15:38:58 UTC
FWIW: I prefer a WYSIWYG behavior as default (so dropping the shift modifier)
Comment 11 Christian Lehmann 2018-11-07 16:04:12 UTC
As long as nobody reacts to Comment 3 plus Comment 7, I may be allowed to repeat the suggestion of the simplest solution: Drop the difference between Click and Shift-Click and always overwrite the current design of the table by the design that the user clicks.
Please consider that a feature may be ever so ingenious and still not helpful if its functionality is not transparent to the user.
Comment 12 Heiko Tietze 2020-10-28 13:10:13 UTC
The widget has the tooltip "Borders (Shift to overwrtite)". Removing functionality might be too much.
Comment 13 Heiko Tietze 2020-11-09 17:30:45 UTC
We discussed the topic in the design meeting. While the widget currently _adds_ borders the request is to _toggle_. Positive side-effect is that we could highlight what is set, drawback that combination of horizontal plus vertical in order to create rectangular wouldn't be possible anymore. But the widget lacks only one configuration, and if we move the empty / None option into the header similarly to the color picker, the free spot gives room for the remaining option.

In a nutshell, let's make the current +shift the default and have toggle with shift. Plus, move None into the header area and add the last option to the presets. Once done we ideally get the toggled state highlighted.
Comment 14 Heiko Tietze 2021-04-23 08:37:43 UTC
*** Bug 141392 has been marked as a duplicate of this bug. ***