Created attachment 150524 [details] Screenshot of "None" selected when "Color" is active Activating Area tab, "None" is always focused, regardless of which fill type is active. Use e.g. these steps: - Create a new Writer document; - Format->Page; - Click "Area" tab in the Page Style dialog. => "None" toggle button is both active (pushed) and focused (has a frame around it, indicating the current focus control). - Click "Color" toggle button to set background to some color - Click "Page" (or any other) tab to leave "Area" tab; - Click "Area" tab to return. => "Color" toggle button is active (pushed); but "None" is focused. This creates a confusing impression of the two "active" modes; it's not always easy to tell which of the two distinct highlighted elements is really active: see the screenshot - on Windows 10, focusing makes the button so more emphasized than activating. Upon activation of the "Area" tab, currently active button should be both pressed, and focused. Code pointer: see SvxAreaTabPage::ActivatePage in cui/source/tabpages/tparea.cxx.
Thank you for reporting the bug. I can confirm the bug present in Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
I've tested this bug and my opinion is: it is not really a bug. The focus is set on NONE-Button always when entering the PAGE tab. This is OK. The toggle-state of a button connected with the content below is a specific design decision with this issue as a draw back. An alternative would be to change this design (cascaded tab-component) - not really better - I think.
(In reply to Jörg Schaffner from comment #2) Sigh. This is a bug, and it was evaluated, and its fix is easy. If you think that any "draw back" that you don't know how to fix is not possible, or not needed, to be fixed, it's wrong. No need to make large-scale changes. And no need to say "oh that's unfortunate result of decision to use that control, and we need not to try to improve that control behavior".
Sorry for my opinion - I do not want to start a discussion here. But think about the following: the focus of a button is not an indicator for his toggle state. And generally: every design decisions has advantages and draw backs. Draw backs are note automatically bugs.
This bug is still present. Version: 6.5.0.0.alpha0+ Build ID: a4ae484ab047193adedaf1c556e2be887f32833c CPU threads: 12; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: en-IN (en_IN); UI-Language: en-US Calc: threaded I think no one is working on it, can i start working on it ?
(In reply to Abhishu Raina from comment #5) > This bug is still present. > > Version: 6.5.0.0.alpha0+ > Build ID: a4ae484ab047193adedaf1c556e2be887f32833c > CPU threads: 12; OS: Linux 5.0; UI render: default; VCL: gtk3; > Locale: en-IN (en_IN); UI-Language: en-US > Calc: threaded > > I think no one is working on it, can i start working on it ? Absolutely. Just remember to assign it to yourself so others know you're working on it
Grabbing focus to the active sub page button when the area tab page is activated will cause unexpected keyboard navigation behavior by moving the focus to the active button when the tab page is visited. Perhaps this could be done for mouse selection only. It would change the current mouse selection behavior of focus being set on the tab if focus is currently on any other tab.
can I work on it? (my first easy hack)
(In reply to pranesh ulleri from comment #8) > can I work on it? (my first easy hack) Yes. A previous attempt is here, so it would be wise to study it: https://gerrit.libreoffice.org/c/core/+/70965
My Progress: I used grab_focus(), now whenever we open the "Area" tab it shows focus on the last saved button, but when I change the tab and then come back to the area tab it goes back None.
(In reply to pranesh ulleri from comment #10) Nice progress; the recommended workflow is that you publish your change to gerrit, and add the easy hack author (me in this case) as reviewer, so that we could discuss the code there.
(In reply to Mike Kaganski from comment #11) > (In reply to pranesh ulleri from comment #10) > > Nice progress; the recommended workflow is that you publish your change to > gerrit, and add the easy hack author (me in this case) as reviewer, so that > we could discuss the code there. But shouldn't I fix the bug completely before I publish it in gerrit.
(In reply to pranesh ulleri from comment #12) > (In reply to Mike Kaganski from comment #11) > > (In reply to pranesh ulleri from comment #10) > > > > Nice progress; the recommended workflow is that you publish your change to > > gerrit, and add the easy hack author (me in this case) as reviewer, so that > > we could discuss the code there. > > But shouldn't I fix the bug completely before I publish it in gerrit. Not necessarily, it can be a call for help & comments.
(In reply to Buovjaga from comment #13) > (In reply to pranesh ulleri from comment #12) > > Not necessarily, it can be a call for help & comments. I have been trying to push the code since last night, there seems to be some error in the process I'm doing. I will push it asap
I have pushed the code: https://gerrit.libreoffice.org/c/core/+/87534
My Progress: I have made a change in TabControl::ImplChangeTabPage. Now the focus goes to the tab name, instead of the button in the tab.
I have added a new patch (patch 5): In this patch I have given the tab name Focus, so now when different tabs are selected the tab name gets activated and focused. After all required setting is selected and clicked "OK" and later when the 'Page Style' is selected the last selected button remains focused.
small correction: last selected button before "OK" remains focused.
I have submitted a new patch pls review and give suggestions. :)
I have submitted a new patch(7) pls review and give suggestions. :)
No repro, the bug seems fixed. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fc6806c4be8585ce0d35a6b581bf8b3dbf858500 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: CL threaded
Created attachment 186649 [details] No repro None always selected
Still repro Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9470fca71139f9e439ce61b4c93dd33022c2cc6d CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
*** Bug 154836 has been marked as a duplicate of this bug. ***