https://bugs.documentfoundation.org/show_bug.cgi?id=163512
--- Comment #16 from FredrikL <[email protected]> --- (In reply to ady from comment #15) > I did not say that the horizontal width is automatically modified. Sorry I missunderstood that. > By default, there are 2 default widths, one for "edit" (and for "show"), and > another for "hover". Yes, correct since LO 7.6.x. > When editing the content of a comment, the width is kept; only the height is > automatically expanded. When the content of the comment is reduced during a > follow-up edition, the size of the comment box (both width and height) will > be kept. IOW, edition of the content will only automatically expand the > height of the comment box; there is no automatic reduction of the height, > nor a modification of the width. True, I agree. > Whichever the height of the comment box after editing, it will also be kept > for the "hover" size. OTOH, for several years now, the initial "hover" width > will be wider than the initial "edit" width. Going back to editing the > content of the comment, the "edit" width is still as it initially was when > the comment was initially created (if there was no manual modification of > its size). Yes, correct since LO 7.6.x. > After the creation of the comment, you can set the comment to "show", modify > its width (and its height), and hide the comment again. This used to affect > also the "hover" width. Unfortunately, it is no longer the case; the "hover" > width is not modified according to the manually-set width. Yes, this is exactly what I personally don't like since LO 7.6.x. > I could understand the temptation of matching the widths, but I do not agree > with the idea that the initial default "hover" width should match the > narrower default "edit" width. Ok after doing some more tests I now realize that if only one short word is entered into a comment for example and the Autor information is hidden then the width of the comment will not expand when "hovering". That is really good. I have also now realized that if I have a longer comment that I don't want to expand so much I can just put in row breaks where I want each line to break to make it more narrow than the default width. Personally I just wanted the "hoover" width to be the same as the "edit" and "show" width no matter if the width had been manually modified or not (when the user has choosen to hide the Author information). For example: 1. If the default "edit" width has not been modified the "hover" width should be exactly the same as the default "edit" width I think and again I'm only talking about when the user has choosen to hide the Author information. 2. If the default "edit" width has been modified the "hover" width should be the same as new modified width (again always the same width for all 3 different scenarios "show", "edit" and "hover" and again I'm only talking about when the user has choosen to hide the Author information). My suggested one line of code change does only affect when the user has choosen to not show Author information in the comments. But maybe what do you think of this idea of code change: 1. If the user is showing the Author information no changes to current LibreOffice behaviour. 2. If the user has a comment with a width of the comment that has not been modified no changes to current LibreOffice behaviour. 3. If the user has a comment with a width that manually has been modified set the "hoover" width to the same as "edit" and "show" width and once again I'm only talking about when the user has choosen to hide the Author information. I have not written any code for that but I guess it should be possible with an if-statement. Would you say that this could be a code change that could be implemented in future LibreOffice versions? Would you like me to take a look at such a code change instead? > OTOH, I would agree that the user should be able to (somehow) manually set a > "hover" width other than the current default, considering that the size of > the comment box can be manually set for the other statuses ("edit" and > "show"). Yes if someone wants to write a code for that it works for me but in the mean time I think the suggested solution above is good. > Comment boxes that are "too narrow" containing "long" text are uncomfortable > to read, and they have problems / bugs in freeze panes. Under typical > circumstances, there is more horizontal space available for reading than > there is vertical space (which causes the problem with freeze panes to be > more frequent). Sure that sounds correct. > The current initial default "edit" width is fine for short text. That's the > reason for the narrow default "edit" (and "show") width. Since the "hover" > status is only temporal, reading the content of a comment on a wider box is > usually more comfortable (and has less conflicts with freeze panes). True in my case have frozen panes both in vertial and horizontal directions in many of my spread sheets, therefore it is a problem in all directions. > As for the conflict between comments and other artifacts (such as a Push > Button), the width of each of those can be inadequate, or not, depending on > several factors such as location. Trying to solve that conflict by modifying > the default width of comments should not be taken as a solution, as > whichever the width, there could still be similar conflicts; it will depend > on the specific layout. Additionally, you can still manually set a different > width for the comment when it is set to "show", and for the other artifact > (Push Button) too. I did not have any other solution to the problem therefore I went down that path. > The conflict between the hovering comment box and the Push Button should be > solved appropriately, instead of using a doubtful workaround that has other > implications, unrelated to the specific use-case, and that will not really > solve the case in a generic way; it will only match specific layouts, just > different than the current ones. There might be some "foreground" or similar > setting for the comment (see "Arrange") or for the Push Button, or some > other method, but it is unrelated to the default width of comment boxes. I have tested many different ways to try to get the comment to the "foreground" but it seams that it is not possible. Also this bug has been reported so many times without beeing fixed. I think because probably it is a harder one to fix as the whole way of how the comments render on screen might have to be reprogrammed. That is what I recall from different forums over the years. So summary, would you like me to take a look at such a code change that I wrote about above? -- You are receiving this mail because: You are the assignee for the bug.
