Created attachment 125437 [details] Shows remains of comment borders that are left displayed when the mouse is no longer hovering over a comment. This occurred in a spreadsheet that I converted to Open Office Format from Microsoft 2003 Excel format, though this may not have any relevance to the problem. PRECURSOR The spreadsheet already had a frozen pane on the left hand side, so that I could see the project names when I scrolled the spreadsheet towards the right. OBJECTIVE I wanted to enter a comment into one of the cells that was within the frozen pane. STEPS 1. I placed my cursor on the project cell into which I wanted to enter a comment and clicked my right hand mouse button and selected the Insert Comment option. RESULT No text entry box was visible on the screen anywhere. Annoyingly, whilst trying to reproduce it during this bug report entry, it's now working ! I can't explain why it's working now, but there are other small issues surrounding comment editing, namely :- 1. The borders surrounding a comment vary. Sometimes they have a left border, sometimes a top border, but the behaviour is non standard when hovering over a comment. I can't show evidence of this, unless you can tell me how to use a previously captured screenshot in Gimp. Borders seem a lot better when show comment is selected to display the comment permanently, but most users don't want them cluttering their spreadsheet. 2. Mousing over a comment displays the comment, but the top border remains, once the mouse is moved off the cell. 3. Editing a cell in the top row of a frozen pane, results in misaligned text editing box. The size of the yellow background varies when compared with the grey border. The difference in the height of the yellow background and the grey border, means that the underlying cells show through, which makes it difficult to distinguish the comment you're editing. In other words, part of the text editing box is transparent. 4. It's not possible to resize the comment entry box whilst editing it. It would be nice to be able to drag a border to stretch it one way or another, or the bottom corner to enlarge the displayed text entry box. The work around to this is to cancel editing, click view comment, click on the displayed comment, which then results in several drag points being displayed on the border of the comment. It's a shame these drag points don't exist in edit mode also.
Created attachment 125438 [details] Another example of comment borders remaining
Created attachment 125439 [details] Shows how the comment background and entry boxes are misaligned.
Created attachment 125440 [details] Shows part of other neighboring cells in the middle of comment box.
Created attachment 125441 [details] Transparent comment box.
Original problem I was reporting was not being able to see the comment entry dialog, having chosen the Insert Comment option. This is happening repeatedly for me at times, but can't determine any rhyme or reason for it. When the entry box isn't being displayed, it seems to be corrected by displaying comments in other cells in the spreadsheet, after which, it is then possible to see the comment entry dialog / box.
Created attachment 125542 [details] Shows remains of comment borders that are left displayed when the mouse is no longer hovering over a comment
Created attachment 125543 [details] Another example of comment borders remaining
Created attachment 125544 [details] Shows how the comment background and entry boxes are misaligned
Created attachment 125545 [details] Shows part of other neighboring cells in the middle of comment box
Created attachment 125546 [details] Transparent comment box
There should be one report per issue/enhancement. The lingering part is apparently bug 73287 Colin: you should decide what you want this report to be about. How are you taking the screenshots to Gimp? Pressing PrtScr on your keyboard and pasting to Gimp? Just wondering about your "1." In addition to Colin's reported issues, there is also bug 98040 for the box not displaying when hovering. Here are all the reports for Calc with "comment" in the summary: https://bugs.documentfoundation.org/buglist.cgi?component=Calc&f9=OP&list_id=615091&order=bug_id&product=LibreOffice&query_format=advanced&resolution=---&short_desc=comment&short_desc_type=allwordssubstr
Originally I started raising this bug report because I was UNABLE to enter a comment in a cell that was part of a frozen pane because no comment entry dialog appeared when I selected "Insert Comment" as an option. Having experimented during the course of raising the bug, I found that I was then able to see a comment entry dialog, probably because of experimenting with comments in other cells that were not part of a frozen pane. This left me in a tricky situation, in that the problem that I wanted to report, was no longer a problem - I wondered whether I had just missed the comment entry dialog somehow! I decided to go ahead and report some of the graphical redrawing problems relating to comments. They all seemed to be similar issues to me, so I thought one bug report was sufficient. Later on the original problem came back again, so I mentioned it as a bit of an addendum to the other points I'd listed. Sorry for the confusion. I captured screen images using GIMP. I later discovered that manually captured screenshots could be found in my recent items folder on Linux, but I'd already attached all the images I'd captured through GIMP at that point.
Ok. It might be clearer to even close this report and create brand new ones for the individual issues. Border remains issue already exists as bug 73287, so it can be left out.
The most serious issue is that the comment entry dialog was not being displayed. I've taken the time to report a number of problems (all concerning comments) into one convenient bug report along with screen images for proof. I am not about to start copying and pasting bits of my bug report into yet another new report. I've had to create 3 separate accounts to report bugs in three different applications so far, and have had weeks of dual booting and grub problems before I even got to this stage. I have got several issues with printer support, Wine, etc. I've only recently moved to Linux - in all honesty, given the weeks of struggling I've endured already, you should feel fortunate that I have made the effort to bother raising a bug report. I'm just trying to do my bit to support Linux application development and improvement. If you make it too long winded for users to provide their feedback, they will cease to do so, and you will lose valuable viewpoints on user experience and what they consider inconvenient or irksome. I don't understand why the way in which I've reported these findings should cause issue. My contribution was to report the problems, so that the product may be improved. If you choose to close the report, it's up to you, but it rather defeats the objective of users contributing towards improving the applications. It also means that there is a loss of control regarding what gets fixed and what doesn't - if it's left purely down to developers what gets fixed, then that does not represent a balanced view of what users consider important, inconvenient or aesthetically annoying. Also, if you choose to close bug reports, the fixes will not be reported back to the users that raised the report, and consequently, they won't be in a position to test whether the fixes, did indeed resolve the problems and improve the application. Sometimes it's user specific data that leads to the problems, so only they can test fixes reliably. Developers will rarely have access to user specific data to enable them to do that. Thanks, Colin
What the heck.. I'm just a user like you. Please understand that we are peers. Either you do the unpaid work or I do the unpaid work. I am willing to wait, there is no hurry.
This bug report is utterly confusing. I'm closing as INVALID. Original reporter can choose (or not) to report the issues succinctly and separately, 1 report per bug. If OP chooses not to, so be it, it's not moving forward in this state.
This developer is being defeatist and has had a tantrum because I refused to split the report into several different bug reports. What proportion of users do you think take the time and make the effort to report faults ? I think you'll find that it's a low percentage. Do you wish to completely dissuade people from reporting bugs ? If you are going to sweep faults under the carpet purely because you can't handle several errors relating to the same topic being reported in one logical grouping along with associated screen shots, then you are undermining users efforts to make the software products better. If it bothers you that much, copy and paste the relevant text you want to separate, into a new bug report. I don't agree with this report being closed though, and if you insist on closing it for trivial reasons, you are jeopardising the quality of the end product. This is not the experience I expected after making the effort to try to improve a tiny part of Linux and it's applications - someone pointlessly protesting, just because I've grouped a number of problems together. Make no mistake though - the problems exist, and if you continue to close bug reports for illegitimate reasons, you will destroy the credibility of open source development methods. I worked in the software testing industry for over 12 years testing complicated interfaces and billing systems for large blue chip companies - I will not accept developers closing bug reports in a tantrum in protest in full knowledge that the faults still exist. I'm sorry to say that I find this defeatist attitude completely unprofessional.
(In reply to Colin from comment #17) > This developer is being defeatist and has had a tantrum because I refused to > split the report into several different bug reports. We are not developers, but volunteer triagers and there is no tantrum here. You have not explained, why you think your time is more valuable than ours. You have already spent more time commenting than you would have creating those individual reports. To rephrase you: you should feel fortunate that we have made the effort to bother giving you consultation for no cost on how to avoid having your report be forever ignored by developers. There was a recent discussion shedding light on the effect this type of attitude has on open source development: https://news.ycombinator.com/item?id=12000746 This bit from one developer nails it: "My general approach is to be nice to people who ask good questions, and who try. When people ask terrible questions, and make it clear that they have no interest in lifting a finger, but demand that you do all of the work... well... they get told in no uncertain terms to shape up, or get banned. You don't owe these people anything. If they had an ounce of human decency, they would understand that they got the software for free, and that they don't deserve anything. And that they need to put some effort into it on their end. The main response I have with these people is If you're too lazy to help solve the problem, then I'm too lazy to help, too."
I made an effort to assist developers by reporting problems and documented what the problems were. Your petty request to split the report up into separate bugs just because you can't get your head around having several points raised in one report is of no concern to me. The information is there for you to refer to - I am not going to document them twice. If anybody has a jumped up impression of their own self importance it must surely be you, because you are illegitimately attempting to close a fault report in the full knowledge that the problems still exists, purely because you can't handle the fact that I am not prepared to go through the drudgery of splitting the report up, because I see it as completely unnecessary and fruitless task. You can't expect users to jump through hoops to rearrange things, just because you have an inflexible way of thinking. You can't expect them to know how you need to rearrange things so that you can better cope with them. All the problems reported in this bug relate to the display and editing of comments in cells. It is completely logical that they remain grouped together, and I simply don't appreciate your argument or insistence on unnecessarily splitting them up. As far as I'm concerned, I've made all the effort I'm going to make regarding reporting the graphical problems. It's your choice to volunteer to triage faults in your own time. By way of appreciation for free open source software I've tried to do my bit to contribute by sacrificing an hour or two of my time reporting some problems which comments which make calc appear rather amateur. My hope and expectation was that I might contribute to improving Calc for the better. In all the years I've worked as a professional system integration and billing tester, nobody has ever requested that I split a fault report up into separate parts and I'm not going to start now. The inflexibility is on your part and I had no notion or expectation of that prior to raising my report. If you are just going to be pedantic and undermine the efforts people make to inform you of problems, then soon nobody will make the effort to report anything and the quality of the applications will suffer. I believe that the acceptance of Linux as a mainstream operating system will suffer as a result. Users just won't accept software that's bug ridden, even if it is free.
(In reply to Colin from comment #19) > You can't expect users to jump through hoops to rearrange things, just > because you have an inflexible way of thinking. You can't expect them to > know how you need to rearrange things so that you can better cope with them. We can't expect them to know? Even though the first thing in the bug entry page is "Before reporting a bug, please read the bug writing guidelines" and the very first section in them has "One bug per report"? The same is true with, for example, Mozilla's Bugzilla. When you go to enter a new report, it very clearly says "Please report only a single problem at a time." (In reply to Colin from comment #19) > In all the years I've worked as a professional system integration and > billing tester, nobody has ever requested that I split a fault report up > into separate parts and I'm not going to start now. The inflexibility is on > your part and I had no notion or expectation of that prior to raising my > report. If you are just going to be pedantic and undermine the efforts > people make to inform you of problems, then soon nobody will make the effort > to report anything and the quality of the applications will suffer. I > believe that the acceptance of Linux as a mainstream operating system will > suffer as a result. Users just won't accept software that's bug ridden, even > if it is free. The software is not free to produce, it requires labor force and you are responsible for it as much as any user. Just to put a stop to this nonsensical spamming and edit war, I'm going to go ahead and split this report up and try to come up with an explanation on why you were unable to do it on your own.
I started preparing to create separate reports and investigated the existing comment-related reports more closely. It turns out that all of the issues seem to have existing reports. (In reply to Colin from comment #0) > OBJECTIVE > I wanted to enter a comment into one of the cells that was within the frozen > pane. > > STEPS > 1. I placed my cursor on the project cell into which I wanted to enter a > comment and clicked my right hand mouse button and selected the Insert > Comment option. > > RESULT > No text entry box was visible on the screen anywhere. Annoyingly, whilst > trying to reproduce it during this bug report entry, it's now working ! This looks like a symptom of bug 73898. > 1. The borders surrounding a comment vary. Sometimes they have a left > border, sometimes a top border, but the behaviour is non standard when > hovering over a comment. I can't show evidence of this, unless you can tell > me how to use a previously captured screenshot in Gimp. Borders seem a lot > better when show comment is selected to display the comment permanently, but > most users don't want them cluttering their spreadsheet. This seems related to bug 98040. I would recommend joining the CC list of bug 98040 and tracking any future fixes. > 2. Mousing over a comment displays the comment, but the top border remains, > once the mouse is moved off the cell. This is bug 73287. > 3. Editing a cell in the top row of a frozen pane, results in misaligned > text editing box. The size of the yellow background varies when compared > with the grey border. The difference in the height of the yellow background > and the grey border, means that the underlying cells show through, which > makes it difficult to distinguish the comment you're editing. In other > words, part of the text editing box is transparent. This, like the primary issue, looks like a manifestation of bug 73898. Personally, I can't reproduce it. I would recommend joining the CC list. > 4. It's not possible to resize the comment entry box whilst editing it. It > would be nice to be able to drag a border to stretch it one way or another, > or the bottom corner to enlarge the displayed text entry box. The work > around to this is to cancel editing, click view comment, click on the > displayed comment, which then results in several drag points being displayed > on the border of the comment. It's a shame these drag points don't exist in > edit mode also. This is bug 68695.