The grid (View > Grid and Helplines > Display Grid) is showing tiny dots that become barely perceivable when zooming in. It was suggested on the mailing list https://listarchives.libreoffice.org/global/design/msg08925.html to change the dots to symbol such as a plus that increases it's size on zoom. This idea is supported by the design team.
Reported in bug 120720 *** This bug has been marked as a duplicate of bug 120720 ***
*** Bug 120720 has been marked as a duplicate of this bug. ***
(In reply to Xisco Faulí from comment #2) > *** Bug 120720 has been marked as a duplicate of this bug. *** It was actually the original and attachment 145842 [details], attachment 145843 [details], and attachment 145875 [details] are quite useful.
"Writer, Calc, Impress, Draw" all use this grid design.
Created attachment 203612 [details] POC: writer 75% zoom
Created attachment 203613 [details] POC: writer 100% zoom
Created attachment 203614 [details] POC: writer 200% zoom
Created attachment 203615 [details] POC: calc 100% zoom
Created attachment 203616 [details] POC: calc 200% zoom
Created attachment 203617 [details] POC: draw 100% zoom
Created attachment 203618 [details] POC: draw 200% zoom
Created attachment 203619 [details] POC: impress 100% zoom
Created attachment 203620 [details] POC: impress 200% zoom
Created attachment 203621 [details] POC: writer grid with subdivisions
Created attachment 203622 [details] POC: writer grid with unequal grid sizes
I created a quick proof of concept implementation to see what the proposed solution would look like. I attached screenshots of this POC. There are two versions, where the plus symbol size has a proportion of 1 / 4 and 1 / 8 compared to the grid distance.
I'd go with the less obtrusive solution, so 1/8.
(In reply to Heiko Tietze from comment #17) > I'd go with the less obtrusive solution, so 1/8. Yes the plus marks remain a needed enhancement to the grid overlay. But visibility at HiDPI DE display resolutions might be more helpful at 1/4 ratio, any option to follow the HiDPI detection? Or otherwise scale the 1/8 upward towards 1/4 or even 1/2 at HiDPI, or even dynamically with high canvas zoom > 200%?
I would prefer, when the cross at the main grid is larger than the subdivision markers.
(In reply to Tamás Zolnai from comment #15) > Created attachment 203622 [details] > POC: writer grid with unequal grid sizes Such unequal grids are kind of uncomfortable to see, and IMHO to work with. I would keep them symmetric for the overlay.
(In reply to V Stuart Foote from comment #20) > (In reply to Tamás Zolnai from comment #15) > > Created attachment 203622 [details] > > POC: writer grid with unequal grid sizes > > Such unequal grids are kind of uncomfortable to see, and IMHO to work with. > I would keep them symmetric for the overlay. But different distances for horizontal and vertical are possible in current LibreOffice. I don't actually know who uses it, but can imaging that they might be useful, if you want to align the graphical grid with the baseline grid or with the raster of East Asian scripts.
(In reply to Regina Henschel from comment #21) > (In reply to V Stuart Foote from comment #20) > > (In reply to Tamás Zolnai from comment #15) > > > Created attachment 203622 [details] > > > POC: writer grid with unequal grid sizes > > > > Such unequal grids are kind of uncomfortable to see, and IMHO to work with. > > I would keep them symmetric for the overlay. > > But different distances for horizontal and vertical are possible in current > LibreOffice. I don't actually know who uses it, but can imaging that they > might be useful, if you want to align the graphical grid with the baseline > grid or with the raster of East Asian scripts. Correct as usual :-) Tools -> Options -> Writer|Calc|Draw|Impress -> Grid with defaults of symmetric increments, but users can adjust...
A few notes: * Using '+' is only relevant where there's an actual intersection of lines. In some of the screenshots we see ++++++ + + + + ++++++ instead of +----+ | | | | +----+ * Please don't create a situation where the grid is too distracting from the contents, the shapes. With some of the screenshots - it _is_ very distracting. * The opening comment complained about grid indicators becoming "barely perceivable" - many users want exactly that: Something you only notice if you're paying attention to it, and is otherwise easy to ignore. So, even though I like plus marks over dots (for intersections), I am worried that a patch here would tie up that issue with the issue of changing grid indicators' weight, darkness, width etc. So - perhaps separate the two issues? Or make the weight, darkness width changes optional?
(In reply to Eyal Rozenberg from comment #23) > instead of > > +----+ > | | > | | > +----+ A dash in that direction as subdivision marker is not helpful in positioning an object. So better go with dot or small cross.
(In reply to Regina Henschel from comment #24) > A dash in that direction as subdivision marker is not helpful in positioning > an object. So better go with dot or small cross. Oh, sorry, I didn't mean to suggest dashes. Dots are fine (or at least - that would be a subject for another bug). I just mean that it shouldn't be a cross.
Well, I see some contradicting opinions here. @Eyal Rozenberg, about your notes. As I see it, based on your notes, you are actually against changing the current behavior. The notes you added basically describe the current behavior of Draw / Impress. In Draw / Impress, the grid has a 3x3 pixel cross for the main grid points and a 1 pixel dot for the secondary grid points. So it seems to me you challenge the decision of the design team to increase the visibility of the grid. Reading the related design meeting minutes: https://wiki.documentfoundation.org/Design/Meetings/2018-10-24 and also reading this ticket and other related tickets, it's clear to me that the design team agreed on changing the current behavior (including Draw / Impress), because having a barely perceivable grid is not good. So my suggestion for you is to discuss this with the design team via the mailing list or at the next design meeting. If the design team as a whole says that the current behavior in Draw / Impress is good as it is now, then I guess this ticket can be closed as won't do or something like that. (Note: In Writer, all points are drawn as 1 pixel dots, so the 3x3 crosses can still be introduced for the main grid points in this case.) For the time being, I'll go with the idea that something should be changed to increase the visibility of the grid, as the existence of this ticket indicates.
Created attachment 203694 [details] POC 2: writer with small crosses 100% zoom
Created attachment 203695 [details] POC 2: writer with small crosses 200% zoom
Created attachment 203696 [details] POC 2: impress with small crosses 100% zoom
Created attachment 203697 [details] POC 2: impress with small crosses 200% zoom
So, after reading all the comments here, I see there is no clear agreement on how this "zoomable plus symbol" should be implemented. Also, I see some technical problems with implementing such behavior reliably. So I leave that idea now. I've got another idea, which is a good compromise. It improves the visibility of the grid without introducing too much clutter. The idea is simply to do what the title of this ticket says: "Change grid indicator from dot to plus", meaning replacing all of the grid points that are currently displayed as 1 pixel dots with 3x3 pixel crosses. The same type of crosses that are already used for main grid points in Impress / Draw. I think it's a small step toward improving the situation. These small crosses are not much bigger than the 1-pixel dots, so it's not a huge change in the visual appearance, but it still improves the visibility. This idea was also suggested by Pedro: https://bugs.documentfoundation.org/show_bug.cgi?id=117348#c18 I added some screenshots how this solution would look like (screenshot with POC 2 prefix).
The new screenshots contain both the current behavior and the new behavior with the small, 3x3 crosses.
(In reply to Tamás Zolnai from comment #26) > So it seems to me you challenge the decision of the design team to > increase the visibility of the grid. Wait, when did the design team decide to increase the visibility of the grid generally? > > Reading the related design meeting minutes: > https://wiki.documentfoundation.org/Design/Meetings/2018-10-24 > and also reading this ticket and other related tickets, it's clear to me > that the design team agreed on changing the current behavior (including Draw > / Impress), because having a barely perceivable grid is not good. If anything, it is clear the design team agreed on _not_ changing the current behavior, but rather only allowing for _optional_, alternative, grid drawing modes. Or rather, it agreed on a change _into_ the current behavior. That discussion was prompted by bug 117348, about making the grid color somewhat darker. That prompted the design meeting discussion, and eventually - the change was made, so we already have a visibility increase. In the meeting, several additional ideas were brought up, and the conclusion was to file additional bugs for each of them; again, as options. > So it seems to me you challenge the ... [the notion of] increas[ing] the visibility of the grid. And you are right. The grid should have low visibility by default. Higher visibility is always achievable using rulers, or concrete shapes that delinieate things - but if the grid were made high-visibility always, one would not be able to reduce it. But the objection to all-plusses is separate from that. Even in high-visibility, a distinction should be made between grid line intersections and grid lines segments without an intersection. > For the time being, I'll go with the idea that something should be changed > to increase the visibility of the grid, as the existence of this ticket > indicates. Please don't do that - except as an _option_. Let's not have a repeat of the active-cell-rectangle situation again. That aside, I think it would be a good idea if you and I would bring this up in another design meeting.
I see. So as it stands now, I stop working on this ticket, because it seems this enhancement was not actually approved by the design team. I would rather not invest more of my time into something that is actually blocked by the design team.
(In reply to Eyal Rozenberg from comment #33) > (In reply to Tamás Zolnai from comment #26) > > So it seems to me you challenge the decision of the design team to > > increase the visibility of the grid. > > Wait, when did the design team decide to increase the visibility of the grid > generally? See the description of the bug: "change the dots to symbol such as a plus that increases it's size on zoom. This idea is supported by the design team." It says the idea was supported by the design team. I don't see anything about optional in the title or in the ticket description.
(In reply to Tamás Zolnai from comment #35) > See the description of the bug: > "change the dots to symbol such as a plus that increases it's size on zoom. > This idea is supported by the design team." > > It says the idea was supported by the design team. I don't see anything > about optional in the title or in the ticket description. The description in the opening comments does not agree with the design meeting minutes, and naturally, the minutes are the more authoritative reflection of what had happened in the meeting. Of course, let us also remember that we don't actually have a formal "design team". Heiko coordinates these activities, and we have design meetings - sometimes attend by a few more people, sometimes less. Many choices or decisions at the design meetings are not fully informed of the variegated interests and needs of the user community - which is why those decisions, unless supported by a wider process, are typically up for reconsideration if objections arise - especially objections which had not been considered in the meeting. This goes both ways: The decision could change to increased grid visibility by default; or the desire for an optional feature may be reaffirmed; or we could decide that the optionality should be different for cross-vs-dot, but not for zoom-dependent size; or vice versa.
No. And see the broader Grid-Helplines meta bug 116219 This exact BZ issue of changing to a Plus instead of Dot was filed by Heiko as a result of UX/Design team discussions of improving the grid visibility 2018-05-30 [1] and as an action item 'c)' following the 2018-10-24 [2] meeting: => file new tickets for a) optional color, b) optional static grid with dots depending on screen resolution (see also night mode) rather than canvas distance (we should take care of jumping issues in relation to the anchors), *c) have a symbol (plus) indicator instead the dot* Tamás please submit to master, once available across modules IFF it needs additional revision(s) for related issues on the meta, we can evaluate and provide feedback. =-ref-= [1] https://wiki.documentfoundation.org/Design/Meetings/2018-05-30 [2] https://wiki.documentfoundation.org/Design/Meetings/2018-10-24
(In reply to V Stuart Foote from comment #37) > Tamás please submit to master, once available across modules IFF it needs > additional revision(s) for related issues on the meta, we can evaluate and > provide feedback. Tamás had the good sense to realize that if there is disagreement, it should be addressed rather than ignored, and he has written the design mailing list to solicit feedback; I encourage you, and the other CCed here, to oblige that request. Whether the result of that discussion will better agree with my position or not, it will certainly get more eyes and minds on the issue. This would be different than in the design meeting from 2018, where user interest in the grid being subtle rather than grabbing attention was not discussed nor mentioned (at least, not in the minutes). Unless there is some urgent need in rushing a change right now - why, Stuart, would you be pushing Tamás in that direction? What is the benefit in doing that? I suppose maybe it is, after all, relevant to expand a little about the active cell rectangle 'saga': ----- The design choices for the active cell rectangle are a delicate trade-off of benefits and detriments. At some point, bug 143733 was filed, complaining about the way we were drawing the rectangle. But the complaint, or the suggestion, was interpreted in a very specific and narrow way, in an implementation of a change. That change - despite its massive effect on how Calc would look - did not undergo serious discussion before a patch was submitted and merged, and then - users, including those of nightlies and QA contributors - were flabbergasted to see their selection rectangle messed up in a bad way. Bug 161709 was submitted, with harsh language about the change; and bug 161740 (which I submitted), noting how content of adjacent cells was now hidden sometimes; and a third dupe, bug 162624, asking for the change to be made optional. In parallel, there were informal requests to back out the change, which were met with resistance, considering the effort which had already gone into the change, suggesting that we wait and see, and even claims that the issues brought up are actually "solved", when they weren't. At some point, people noticed that even the suggestion of the original bug reporter did not agree with what had been committed. Eventually, continuing defense of the committed change became untenable, and the belated discussion brought its proponents to adopt the position of its critics (and the position originally expressed in bug 143733) - and the rectangle was redone differently. But along the way, the were a lot of flak and acrimony which would have been spared, had the matter been handled differently, and had a change likely to be at least contentious not been rushed. ------- What I was saying earlier is that we should do better this time. Let's find a way to satisfy more (or all) of the users - rather than to shut people up by getting to a state where the commit has already happened.
(In reply to Eyal Rozenberg from comment #38) There is no disagreement regards the change to a cross/plus grid mark. This was already covered by the UX-Design process back in 2018 and I for one am very appreciative that Tamás took the dev cycles to work up a reasonable POC for what is an existing ticket with clear goals. Implementation choices remain largely the choice of the individual developer electing to contribute--and who in this case had clear guidance to work against. Far to many UI issues receive no dev interest. Your well intentioned but thoughtless actions degrade things further with no benefit. Please stop pestering the devs who are willing to make improvements and are willing to work with the user community to refine their submissions IFF needed. That can't be done when we don't have their code to review and test. Tamás isn't going anywhere, but why would he subject himself to implementation thrash occasioned by endless feature change requests as afflicted Rafael L by extending work on the otherwise off-topic bug 161709 for the Calc active cell border. You claim to understand and interpret the Design-UX process, yet you demonstrate inability to work within constraints of the development process. Design and UX-feedback does not drive the development effort.
(In reply to 00 from comment #4) > "Writer, Calc, Impress, Draw" all use this grid design. Actually, the Writer grid design is different that Draw's (checked with a recent 26.2 nightly): Draw has pluses-at-intersections, dots elsewhere; Writer has only dots. And - IIUC, it seems the Writer dots have not received the same color change as for Draw/Impress.
(In reply to V Stuart Foote from comment #39) I'll (try) to keep the material discussion on the mailing list where it's started, but - I believe it's worthwhile to trace the parallels between this case and that of the active cell rectangle affair. Yes, it seems that in both of these efforts, developers received what seemed like clear guidance. But in both cases, the guidance was a misrepresentation, even if an unintended one. We've discussed how that was the case in this bug; and it seems to have been the case with the active-cell-rectangle efforts: Rafael was led to believe everyone was on board with a wide rectangle outside the cell boundaries, although the bug prompting the rectangle revamp did not ask for that to happen, and in fact asked for something else (an Excel-like rectangle). The result was a major degradation of LO Calc's UI, that had to be fixed. > Please stop pestering the devs who are willing to make improvements and are > willing to work with the user community to refine their submissions IFF > needed. That can't be done when we don't have their code to review and test. Actually, the lesson to learn is for us to please stop trying to manufacture artificial clarity and definitiveness for developers who work on UI issues - especially for UI aspect which are highly visible to most users most of the time. We should not frustrate them with a belief that "the community has spoken", and now they just need to implement things in some fashion - when that is not the case. False expectations lead to surprising frustration. Moreover, there is the slippery slope: When that code is submitted for review, it may well be accepted - since the review does not typically ensure that the UI change is really sound and widely acceptable; and after the review, the problem becomes much more difficult to fix, in the political sense: A backout was not considered an acceptable option; so we had to wait for an improvement on the original state of affairs. > You claim to understand and interpret the Design-UX process, yet you > demonstrate inability to work within constraints of the development process. > Design and UX-feedback does not drive the development effort. LibreOffice is a user-facing application, for which reason design and UX inputs and feedback drive a significant part of the development effort.
We discussed the topic in the design meeting. Much has been said in the comments here or on the mailing list. The task is essentially to make the look and feel consistent across modules (do not have different indicators for Draw/Impress vs Writer), make it dependent to zoom (the grid either covers the content when zoomed out or is barely visible in the current implementation - and other symbols might not help a lot here), and add some user customization (different preferences or scenarios require either a subtle grid or a bit more visible; could be an expert switch or some easy to understand option).