Description: Even after ensuring that it is set to 'No Transparency', on hover they are still transparent. Steps to Reproduce: Steps: 1. create a comment on a field. 2. click away from the field 3. hover over field to show comment result: comment is transparent. Steps to validate the settings: 1. in a field with a comment, select 'Show Comment'. 2. Right-click on the comment and select 'Area'. 3. Click on the 'Transparency' tab. 4. Ensure that 'No Transparency' is selected. 5. Click on [OK] 6 right-click on field, and select 'Hide Comment' 7. Repeat validation steps above to show that on hover, the comment is still transparent. Actual Results: Comments remain transparent. Expected Results: Comments shouldn't be transparent. Reproducible: Always User Profile Reset: Yes Additional Info: Is there a global setting somewhere? I can't seem to find one. I wouldn't want to have to set each comment individually.
Hey MacAhi, I am not able to reproduce this bug on Version: 25.8.3.2 (AARCH64) Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 11; OS: macOS 15.6.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Would you be able to share a screenshot of what this looks like for you?
Created attachment 204286 [details] Here's the comment on hover.
Created attachment 204287 [details] Here's the comment if I choose 'Show Comment'
Created attachment 204288 [details] This is the comment settings.
It still happens on 25.8.3.2 on MacOS
In bug 166734 comment 11 it was argued that this is fine. Let's add Armin and Heiko.
It's not fine. Depending on what is behind the comment, the transparency interferes with clear and easy reading of what's in the comment. If users want to make their comments transparent (as in comment 11 which you pointed out), they can do so. That comment's argument doesn't make sense since all the user would have to do is hover off of the cell in order to see what's behind it. Leaving it permanently transparent interferes with anyone who doesn't want that. As it is currently, it's not working as the interface dictates. The setting is "No Transparency". That should be the result. I also think this should be a global setting, maybe with an override at the individual comment, but if someone wants to set a level to apply to all comments, that should be available.
You get what you want per View > [x] Comments. The semi-transparency happens only when you hover over a hidden comment. (In reply to MacAhi from comment #8) > It's not fine. The majority has a different view, see bug 166734 comment 9. > I also think this should be a global setting... Wouldn't mind a boolean expert option AlwaysOpaqueComments, or the like. But not something in the main UI.
I viewed the survey. It would have been better to have asked if Comments should be *allowed* to have levels of transparency. Having done hundreds of user surveys in my 40+ year career as a developer, I understand that getting people to respond to surveys can be challenging, but 17 users is hardly representative of the user community. If users voted to show the color Red, when a user chooses Green, would you support that decision? I certainly hope you'd say no, you wouldn't. Why? Because that decision, no matter how popular it may be, doesn't make sense. The setting is Green, not Red, just as No Transparency means zero transparency, not >0% transparency. If you decided to change the setting title to "Minimum Transparency", I'd still argue that you're making the wrong decision by not allowing a Comment to be opaque on mouseover (the way most comments are viewed), but at least the setting would be doing what it says, unlike how it works today. It's inaccurate, which is not something you want in a program. Fonts also has a No Transparency setting, but I notice that actually works correctly. Why the intransigence on the Comments? In the end, this setting doesn't break the tool. It's not going to produce invalid numbers or break any macros, but it is an inconvenience that simply doesn't need to be there. It can make it very difficult to quickly read comments when the box is over content that interferes with the data in the comment.
Let's keep your objection as New and wait for more people joining the choir. Adjusted the summary a bit to make the issue easier to find. I can imagine an expert option but wouldn't invest effort unless more users benefit.
Thank you for the response. My summary is more accurate. Yours is subjective. Mine is objective. I've updated it to reflect both. Here's a resolution. I'm guessing that the transparency percentage chosen is 10%. I haven't verified, but for the sake of argument, let's go with that. - set the default value to 10% - reflect that in the controls, so when a user opens the setting, it states 10% - allow users to set any value from 0-100, and actually use that value as the transparency. As best as I can figure, the app now ignores anything <10% - get rid of the No Transparency checkbox and just go with 0% to reflect the level. - have a global setting either for calc or per file to set the default instead of forcing 10%.
(In reply to MacAhi from comment #12) > - set the default value to 10% You cannot change the transparency yourself, it's hard-coded in a rather complex patch. See https://gerrit.libreoffice.org/c/core/+/185417
It probably never should have been implemented in the first place. It seems like it was a lot of work for nothing more than a gimmick with no actual value. I"d love to see it reversed, but as I said, it's not going to break the app if it isn't. It's just a visual annoyance.
(In reply to Heiko Tietze from comment #13) > (In reply to MacAhi from comment #12) > > - set the default value to 10% > You cannot change the transparency yourself, it's hard-coded in a rather > complex patch. See https://gerrit.libreoffice.org/c/core/+/185417 I just re-read your previous comment. Maybe I misunderstood, but are you saying that you think users can't set the transparency percentage? You know that functionality is built into the controls of the Comments and is what I've been talking about, right? If you're not sure what I'm talking about, please see the attachment titled " This is the comment settings. ". Here, I absolutely can set the transparency amount but nothing less than the preset value is respected. If you meant that I was suggesting that *I* would change the default, you're correct, I can't. My bullet points above were suggestions for design changes to the application.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b32e65bcd122998ecdeb990b07823f5d60cc226a Resolves tdf#169504 - Option to control comment transparency It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The new expert option NoteTransparency (Tools > Options > Advanced: Open Expert Configuration) controls the transparency. Switch it to false for opaque comments. This change requires a restart.
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/70bc772bd7356cf1d8025cafd58b814510196f89 Resolves tdf#169504 - Option to control comment transparency It will be available in 26.2.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #16) > Heiko Tietze committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > b32e65bcd122998ecdeb990b07823f5d60cc226a > > Resolves tdf#169504 - Option to control comment transparency > > It will be available in 26.8.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. I still haven't seen this update come through. I'll check again tomorrow.
(In reply to MacAhi from comment #19) > I still haven't seen this update come through. I'll check again tomorrow. Hmm? It has come through, see the Mac builds in https://dev-builds.libreoffice.org/daily/master/current.html
Created attachment 204725 [details] pic
(In reply to Buovjaga from comment #20) > (In reply to MacAhi from comment #19) > > I still haven't seen this update come through. I'll check again tomorrow. > > Hmm? It has come through, see the Mac builds in > https://dev-builds.libreoffice.org/daily/master/current.html I just pulled it again and NoteTransparency doesn't exist. I'd searched for Transparency, Comment and Note by themselves and can't find an appropriate setting.
(In reply to MacAhi from comment #22) > (In reply to Buovjaga from comment #20) > > (In reply to MacAhi from comment #19) > > > I still haven't seen this update come through. I'll check again tomorrow. > > > > Hmm? It has come through, see the Mac builds in > > https://dev-builds.libreoffice.org/daily/master/current.html > > I just pulled it again and NoteTransparency doesn't exist. I'd searched for > Transparency, Comment and Note by themselves and can't find an appropriate > setting. It's there for me in 26.8, so you must be using an incorrect version. If you copy and paste here the content of your LibreOffice - About by clicking the copy button, we will know for sure.
Version: 26.8.0.0.alpha0+ (AARCH64) Build ID: 30b57dcd3f740a423308eaa9d935aa02142b572b CPU threads: 10; OS: macOS 15.6.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded This is what's available on https://dev-builds.libreoffice.org/daily/master/current.html MacOSX-aarch64@tb92-TDF 2025-12-16 04:10:28
(In reply to MacAhi from comment #24) > Version: 26.8.0.0.alpha0+ (AARCH64) > Build ID: 30b57dcd3f740a423308eaa9d935aa02142b572b > CPU threads: 10; OS: macOS 15.6.1; UI render: Skia/Metal; VCL: osx > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded > > This is what's available on > https://dev-builds.libreoffice.org/daily/master/current.html > > MacOSX-aarch64@tb92-TDF 2025-12-16 04:10:28 You did not notice the newest one from another build machine: MacOSX-aarch64@tb94-TDF 2025-12-19 04:19:08
(In reply to Buovjaga from comment #25) > (In reply to MacAhi from comment #24) > > Version: 26.8.0.0.alpha0+ (AARCH64) > > Build ID: 30b57dcd3f740a423308eaa9d935aa02142b572b > > CPU threads: 10; OS: macOS 15.6.1; UI render: Skia/Metal; VCL: osx > > Locale: en-US (en_US.UTF-8); UI: en-US > > Calc: threaded > > > > This is what's available on > > https://dev-builds.libreoffice.org/daily/master/current.html > > > > MacOSX-aarch64@tb92-TDF 2025-12-16 04:10:28 > > You did not notice the newest one from another build machine: > MacOSX-aarch64@tb94-TDF 2025-12-19 04:19:08 I didn't realize there were 2 separate builds for the same OS/chip Thanks. I'll pull this one and test.
Buovjaga, Thank you for pointing me to the correct DL. I'll know that for the future. Heiko, This update does work, and also allows for transparency if the user chooses it. That's exactly how it should be. Thank you for the work and the solution. However, this should have the default set to false. Otherwise, by default you still have a control that doesn't do what it says it does. That's bad UX. 'No Transparency' should mean no transparency, not partial transparency. Thanks!
(In reply to MacAhi from comment #27) > 'No Transparency' should mean no transparency, not partial transparency. The variable is NoteTransparency, true by default. It means to have a semi-transparent on hover, as known, and allows to switch the transparency off. I see no need to change anything in the naming. And I understand your position as a single, although comprehensible, argument that does not justify changing the default (always opaque and transparent per user configuration). I also see no need to make the option available for easy access, meaning a checkbox somewhere under Tools > Options (or LibreOffice > Preferences in your case). This might change with further user comments.
(In reply to Heiko Tietze from comment #28) > (In reply to MacAhi from comment #27) > > 'No Transparency' should mean no transparency, not partial transparency. > The variable is NoteTransparency, true by default. It means to have a > semi-transparent on hover, as known, and allows to switch the transparency > off. I see no need to change anything in the naming. > > And I understand your position as a single, although comprehensible, > argument that does not justify changing the default (always opaque and > transparent per user configuration). I also see no need to make the option > available for easy access, meaning a checkbox somewhere under Tools > > Options (or LibreOffice > Preferences in your case). > > This might change with further user comments. As a UX expert, you certainly should know that a control which doesn't do what it says it does, is very bad UX. I don't know how you can justify that. I'll drop it. Thanks for the work.
(In reply to MacAhi from comment #29) > ...a control which doesn't do what it says it does, is very bad UX. Absolutely- but read the name more carefully. It is *Note*Transparency not No. The comments are called notes internally.
(In reply to Heiko Tietze from comment #30) > (In reply to MacAhi from comment #29) > > ...a control which doesn't do what it says it does, is very bad UX. > Absolutely- but read the name more carefully. It is *Note*Transparency not > No. The comments are called notes internally. I'm not talking about the name. I don't care if you call it George. I'm talking about the default status. If it's defaulted to true, then the "No Transparency" setting through the Comments interface doesn't do what it says. That's bad UX/design.
Created attachment 204736 [details] Screenshot You mean the option from the Area settings? It comes from the shape attributes, and could indeed pick up that is set as default on the comment. I suggest to create a new report "Comment area attribute in particular transparency should pick up the hard-coded settings" or the like. And it also sounds right if the comments style was some user-customizable drawing style (with minor inconsistency that comment colors change with the author in Calc too, AFAIK). Both are beyond my skills.
(In reply to Heiko Tietze from comment #32) > Created attachment 204736 [details] > Screenshot > > You mean the option from the Area settings? It comes from the shape > attributes, and could indeed pick up that is set as default on the comment. > I suggest to create a new report "Comment area attribute in particular > transparency should pick up the hard-coded settings" or the like. And it > also sounds right if the comments style was some user-customizable drawing > style (with minor inconsistency that comment colors change with the author > in Calc too, AFAIK). Both are beyond my skills. I am very confused that you're confused. Yes, I've been talking about that setting this entire time. That's what this defect is about, from the beginning. I'm not creating a new defect report. This report is about that issue. At this point I have no idea what you mean by 'hard coded settings'. All I've been asking from the beginning is that the controls do what they say. 'No Transparency' should mean No Transparency. I'm really sorry if there's been a misunderstanding of some sort, but your 'fix' corrects the issue (in a very strange way). All I'm suggesting now is that instead of defaulting to 'true', meaning that you're *forcing* transparency even if a user chooses 'No Transparency', that you default to 'false' so the control does what it says. I'm sorry. If this still isn't clear, please let me know and I'll try to do a better job of explaining. I'm going to bed soon, so I'll follow up in the morning. Have a good weekend!
(In reply to MacAhi from comment #33) > All I've been asking from the beginning is that the controls do what they say. And I was trying to explain that a comment _seems_ to be configurable like a shape with color/shadow/transparency attributes but is not. It is a control _based on shapes_ created and maintained by the source code. Possible solutions are: a) do not make the comment look like something configurable and remove access to the options, or b) make comments exactly like other shapes, with default attributes taken from some style. In any case a lot of work ;-).
You've already done the work to fix it. Don't change your code or the name from NoteTransparency. Leave all of that as it is, but make sure the NoteTransparency default value is 'false', not 'true' when it gets pushed out, and it will work perfectly fine. That value set to false makes the Comment controls work properly. I'll write up something later today to explain better since I think there's still a misunderstanding.
Created attachment 204742 [details] Pass/Fail See the attachment for my test results. Please see the original attachments for full context. This defect is regarding the 'Comments\Area Transparency' settings controls (see image: https://bugs.documentfoundation.org/attachment.cgi?id=204288). The code in production has controls which do not do what they say. Similarly, setting the "NoteTransparency=true" in your updated code doesn't change that. - In the current production version, selecting ( ) "No Transparency", or any value <10% doesn't work. The comments have a *forced* 10% transparency. - with the setting "NoteTransparency=true", the result is exactly the same. The 'Comments\Area Transparency' settings do not work properly. - with the setting "NoteTransparency=false",the results are that all of the 'Comments\Area Transparency' settings do what they indicate. You agreed that a control which doesn't do what it says it does, is very bad UX. That is the current situation. Your code fixes that, but *only* if the parameter is set to false, which is why I'm stating that when your fix is rolled out, it needs to be set to false by default. That will fix the issue.
(In reply to MacAhi from comment #36) > it needs to be set to false by default. Just to acknowledge your POV, my comment 34 is still valid. And I would prefer to block the configuration of comments. I suggest to write a new ticket, this "comments transparency can't be disabled" is solved now (or band-aided if you prefer this view).
(In reply to Heiko Tietze from comment #37) > (In reply to MacAhi from comment #36) > > it needs to be set to false by default. > Just to acknowledge your POV, my comment 34 is still valid. And I would > prefer to block the configuration of comments. > > I suggest to write a new ticket, this "comments transparency can't be > disabled" is solved now (or band-aided if you prefer this view). How do you justify defending a control that doesn't work? All I'm asking is that you change the default on your new code from true to false so that the problem is actually fixed instead of making users have to hunt for a fix. Are you concerned that it's a patch and not a fix? Is that the issue? Does LibreOffice have a change control process? Did either the forced transparency or this fix actually get approved by a change control board?
(In reply to MacAhi from comment #38) > Does LibreOffice have a change control process? Did either the forced > transparency or this fix actually get approved by a change control board? The change control process is having a bug report to discuss the change before it is done/committed. Unfortunately, the transparency defining commit 256ad05887a23484ef4494cc90ea168696bbba37 was not associated with any report, so there was no opportunity to discuss it. Bug 166734 comment 3 then revealed the thought process of the implementer after the fact. Clearly this is not ideal and not the recommended way to go about changes. We always suggest to create a report.
(In reply to Buovjaga from comment #39) > (In reply to MacAhi from comment #38) ...is not ideal and not the recommended way to go about changes. Agreed. ==== How do you justify defending a control that doesn't work? All I'm asking is that you change the default on your new code from true to false so that the problem is actually fixed instead of making users have to hunt for a fix. Are you concerned that it's a patch and not a fix? Is that the issue? Do you really not understand why it should be defaulted to false?