Description: The behavior of the border picker is sometimes off Steps to Reproduce: A) Table without borders set (cycling through) 1. First click -> Apply border 2. Second click -> Selected border state (needed?) 3. Third click -> Remove -> This become more obvious by bug 139837. Have enabled the incidentally so many times B) Table with pre-existing borders (cycling through) 1. First click -> select 2. Second click -> remove 3. Third click -> apply border C) Pre-existing borders with 1 border selected 1. First click -> Select border 2. Change line color 3. Click different border -> expected select only (not change) -- D) Pre-existing border, not selected initially 1. Change line color -> Applied to all borders E) Table without borders, not selected 1. Change line color -> Nothing happens 2. Click in border picker -> border applied -> fine -- F) Mixed, some borders active, others disabled (without any border selected) 1. Change line color -> Applied to all active borders G) Mixed, some borders active, others disabled with active border selected 1. Change line color applied to that border (fine) Actual Results: I struggle with case C. I don't expect a direct change & only a selection. Also case A, where the 'select border' comes second. Expected Results: In case C no change should occur.. only selection. In case A it should skip 'select' and directly remove. As there is not to 'pre-select) Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 6ee7a3b2c0565c2871d32d704cb2899445b9f88d CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and in 3.3.0
New attempt: I started this first time with bug 139094. However was probably searching in the wrong direction..
Had this topic in the design meeting. Sascha thinks that "keep" makes no sense in many cases, e.g. edit single cell, column, row. And consistent behavior would be: init off>on>off; init partial>on all>off all. Me smells bike-shedding, and while I neither see the benefit of the third state there is/was likely a reason to introduce it.
Created attachment 169464 [details] Screencast (In reply to Heiko Tietze from comment #2) > Me smells bike-shedding, and while I neither see the benefit of the third > state there is/was likely a reason to introduce it. I have no clue how people managing enabling/disabling borders.. I surely use the border picker.. and I surely get frustrated So for me it's not 'trivial'/ bike-shedding. I survive, but keeps being annoying. But depends if you use tables (A) & (B) configure borders manually (or template). (C) how often this occurs). Disabling borders I like pretty common (see templates). Different border settings also. The third state is not totally 'superfluous'. At least, click an existing border (single) (selected). And change formatting (does work).. If it word the whole cycling third borders is different question.. The major problem, you can't move to any other 'border'.. The new formatting is 'new setting'. So every border selected subsequentially will be reformatted. This is a feature (and a bug) at the same time :-( In Atlantis Word processor and Word this works differently (screencast). So 'uncoupling' formatting border settings and actually applying the formatting already an improvement. Except there still the issue that you can't see the 'current border formatting settings' So CTRL+CLICK Border showing current. And direct click adjust? [Atlantis doesn't handle this case either; nor does Word]
*** This bug has been marked as a duplicate of bug 143249 ***