Radio buttons normally look like a dot in a circle. Checkboxes normally look like a checkmark in a square. However, now in 7.1 (and probably backported to 6.4.6) the radio button has a checkmark in it, and in the gtk3 theme the checked result looks like a square. See attachment 100290 [details] calc radio controls - which look like checkboxes. (The gen theme also uses a checkmark which I don't really like, but at least it is clearly a circle.) Since 7.1 commit dcc031d0cd3219dd77b66e1221fe966139829c1a Author: Rizal Muttaqin on Tue Jun 9 14:33:26 2020 +0700 Icon theme: tdf#133582 missing checkbox and radio button in gen env
Created attachment 163401 [details] TheseAreRadioButtons.jpg: how it looks on my screens.
Yes, I confirmed this. I just follow elementary Human Interface Guideline here: https://elementary.io/docs/human-interface-guidelines#radio-buttons The point is I would like to follow upstream as close as possible. I would like to ask one of main elementary OS developer regarding this issue which already join LibreOffice Telegram Design group.
OK. I think in the particular situation / document I provided, the background of the button must be coming from somewhere other than the cell - so that the transparent-edges (of the square) are showing a black color from somewhere instead of the white background of the cell - making it look worse than it ought to look. So there might be an implementation problem with controls that is more at fault here.
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=86ea64f216819696cd86d1926aff0a138ace2baf author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2019-02-15 13:14:32 +0100 committer Tomaž Vajngerl <quikee@gmail.com> 2019-04-03 11:57:08 +0200 commit 86ea64f216819696cd86d1926aff0a138ace2baf (patch) tree db513803abc9dc255d27c0f08cba6d6d0c9ef1d9 parent 994b41a6c69d20637dcb95894c385f5c0102d600 (diff) Support for native 32bit Bitmap in VCL and SVP (cairo) backend Bisected with: bibisect-linux64-6.3 Adding Cc: to Tomaž Vajngerl
Created attachment 163406 [details] elementary icon theme with kf5 backend (In reply to Justin L from comment #3) > OK. I think in the particular situation / document I provided, the > background of the button must be coming from somewhere other than the cell - > so that the transparent-edges (of the square) are showing a black color from > somewhere instead of the white background of the cell - making it look worse > than it ought to look. > > So there might be an implementation problem with controls that is more at > fault here. I confirm the black edges in gtk3 backend. But with kf5 it looks OK (see the attached screenshot) Version: 7.1.0.0.alpha0+ Build ID: 9006cbf6a13317a386194d6857f22391464c2aa0 CPU threads: 4; OS: Linux 4.20; UI render: default; VCL: kf5 Locale: id-ID (id_ID.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-07-16_00:51:18 Calc: threaded
(In reply to Xisco Faulí from comment #4) > Regression introduced by: > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=86ea64f216819696cd86d1926aff0a138ace2baf > > author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2019-02-15 13:14:32 > +0100 > committer Tomaž Vajngerl <quikee@gmail.com> 2019-04-03 11:57:08 +0200 > commit 86ea64f216819696cd86d1926aff0a138ace2baf (patch) > tree db513803abc9dc255d27c0f08cba6d6d0c9ef1d9 > parent 994b41a6c69d20637dcb95894c385f5c0102d600 (diff) > Support for native 32bit Bitmap in VCL and SVP (cairo) backend > > Bisected with: bibisect-linux64-6.3 > > Adding Cc: to Tomaž Vajngerl Different email from one person?
(In reply to Rizal Muttaqin from comment #2) > The point is I would like to follow upstream as close as possible. I would > like to ask one of main elementary OS developer regarding this issue which > already join LibreOffice Telegram Design group. Here is the answer from him: https://blog.elementary.io/why-we-use-checks-in-checkboxes-and-radio-buttons/
I find it very telling that they even had to write an article a couple of years ago about why their bad idea wasn't so bad. This phrase is key. > "Checkboxes and radio buttons are honestly used pretty sparingly > in elementary OS, > and even more sparingly together. When they are used, it’s fairly obvious > from context whether it’s a multi-select or exclusive-select situation." As attachment 100290 [details] shows, we don't have control over whether the use of radio buttons or checkboxes will be obvious from the context - since these are user-created items. Nor could we claim that they are sparingly used. And I strongly disagree this this is just "historical differences for those subtly different behaviours". The distinction is not subtle at all.
Dear Justin L, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 188298 [details] 7.5.5.1 gtk3 render of radios/checkbox Setting the checkmarks in radio buttons issue aside.. The latest 7.5.5.1 gtk3 renders without black edges. Version: 7.5.5.1 (X86_64) / LibreOffice Community Build ID: 2c5e46c1980ec5241359fd65d751dc518205e7af CPU threads: 4; OS: Linux 6.3; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Jojo from comment #10) > The latest 7.5.5.1 gtk3 renders without black edges. Fixed in LO 7.2 with commit cd09fc9451897e6efedbf9f5e1d5b9bd96e65cb5 Author: Luboš Luňák on Mon Mar 22 19:06:15 2021 +0100 do not enable mbSupportsBitmap32 for headless (tdf#141171) As said e.g. in 994b8e52fc02c7468a24 and 84f84f59ce7c83a99e4e340071d, LO code is not yet fully ready for 32bit bitmaps and e.g. PDF export code mishandles it. Obviously this is not going to be a battle that I win, so with the radio button now at least looking like a circle, I'll mark it as fixed.
Personally, I prefer regular radio button rather a radio button with checkmark, some goes with save button in elementary theme.