https://bugs.documentfoundation.org/show_bug.cgi?id=91415
--- Comment #8 from ady <[email protected]> --- (In reply to Cor Nouws from comment #7) > (In reply to ady from comment #5) > Is it that there may never be any overlap in the content and the indicator? No, of course I'm not demanding that; just that the current workarounds be still available, especially the zoom, as it is the easiest to temporarily apply. The current change seems to prevent it. > Or..? > Can I see images/examples somewhere of what works and what not? First, apologies for the long text that follows, but this matter needs clear debate (as shown by the several bug tickets, many comments, and prior attempts of resolutions back and forth). I have encountered some case with the comment indicator blocking some text or number in a cell at some point or another in my life. Usually, I am able to overcome such situation by means of zoom. Using the zoom is something that I am used to use frequently, for other reasons, so it is natural for me to use such method. Other users might not even think about that, so they might think that they have a critical UI issue. There is very little mention of using zoom in the related bug reports (which might indicate that they don’t even try it or think about such alternative). Other workarounds, besides those I already mentioned, can be text alignment, indentation and border padding (all of which I also use for cases such as filter arrows blocking text, either within or around the boundaries of the filtering cell). When I saw the wording, "scale…", I went and asked Heiko Tietze in irc #libreoffice-design, and the screenshots and video provided show that, no matter the zoom, the resulting text is still covered by the indicator. This is not what happens as of LO 7.4.4, in which, most frequently than not, temporarily changing the zoom can resolve the relatively minor problem – I say "relatively minor", because it can be easily overcome by several currently-available methods. It is still in the hands of users. By changing the indicator to grow when we use higher values of zoom (i.e. part of scaling it), which is part of the change according to the screenshot that Heiko Tietze showed me, a relatively minor problem for some users in some cases can turn into a permanent inconvenience (especially to visually challenged users) that has no easy workaround (because no matter the zoom, if the indicator covers a text, it will cover it under any zoom value once the change is committed). There will be no longer an easy workaround in the hands of users (especially if the file is read-only, when other properties cannot be modified, but the zoom is yet available). Having some artifact covering some text is not an exclusive issue with the comment indicator. There is help text showing under the mouse pointer, and/or filter arrows, just as common examples. The user has sometimes some method to overcome or correct the situation (e.g. for filter arrows, and for comment indicators), but sometimes there is no workaround (e.g. mouse pointer over help text). The resolution proposed here seems to make useless the easy workaround currently available (as of LO 7.4.4.), and will not solve the issue really (as shown in the screenshots that Heiko Tietze provided in irc). For example (of what _not_ to do), making the indicator just one color (i.e. with no border of another contrasting color) would make it smaller, but such hypothetical change clearly clashes with using a similar background color for the cell or for the cell’s border, so you should _not_ make the indicator one_color_only and without its border (i.e. its border, with a different color, must remain). If you can make the indicator smaller but still visible (e.g. triangle, still with a border of a different color), then that’s an improvement (in UI) that shouldn't affect negatively other users. Perhaps if the indicator can be partly transparent (the alpha thing that was suggested before) then both objectives can be maintained(?): the text can be clearly seen, and the indicator can be clearly spotted. It is possible that just making it a triangle is enough, in which case no new bug enhancement requests would show up (and so, going step-by-step towards a resolution can be helpful, rather than applying several changes at one time, risking some unnecessary negative side-effects). Reading prior tickets (some of which I already linked to) on the same subject and prior attempts to improve the situation, demonstrates that there is some balance to consider, and that some changes that are centered on the comment indicator alone can negatively affect other aspects of UI and usage. Since I have to rely on using the zoom more often than not (and the comment indicator is not nearly the main reason for it, by far), I am perhaps more aware than others that using the zoom can be an easy workaround for the matter in question in many occasions, while scaling the comment indicator seems to have (according to the screenshots that Heiko Tietze showed me) detrimental consequences. When users would write to complain that, no matter the zoom value, the indicator still blocks the text behind it, then one workaround that is available as of LO 7.4.4 would be gone, and a solution for that newly created situation would have to wait for another 7 or 8 years (I wonder?). (Just in case, I don’t mean to sound rude or to complain; I’m only writing what I worry about, since the very instant I read the "scale…" phrase. So, triangle, with border, 2 different colors (one for the triangle, another color for its border, as it is now for the square), with some degree of transparency. Maybe introducing the changes step-by-step (first the shape, then the transparency) instead of all at once? I don’t know whether there are negative effects (such as more resources needed just for displaying the indicator, instead of using them for calculation power, for instance?), but others can comment on those. Now, if what I am describing that I saw in the screenshots is just my misunderstanding, and the comment indicator will _always_ be smaller than what currently is at any_and_every zoom (I am no stranger to 200% zoom, sadly) and DPI scaling factor, then please accept my apologies for the noise. -- You are receiving this mail because: You are the assignee for the bug.
