Bug 124548 - Activating Area tab, "None" is always focused, regardless of which fill type is selected
Summary: Activating Area tab, "None" is always focused, regardless of which fill type ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyMedium, easyHack, skillCpp, topicUI
Depends on:
Blocks: Area-Fill-Tab
  Show dependency treegraph
 
Reported: 2019-04-04 14:07 UTC by Mike Kaganski
Modified: 2020-07-04 07:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of "None" selected when "Color" is active (92.39 KB, image/png)
2019-04-04 14:07 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2019-04-04 14:07:29 UTC
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.
Comment 1 Durgapriyanka 2019-04-04 14:36:50 UTC
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
Comment 2 Jörg Schaffner 2019-04-30 10:39:20 UTC
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.
Comment 3 Mike Kaganski 2019-04-30 10:46:52 UTC
(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".
Comment 4 Jörg Schaffner 2019-04-30 11:03:59 UTC
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.
Comment 5 Abhishu Raina 2019-12-11 14:10:11 UTC
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 ?
Comment 6 Xisco Faulí 2019-12-11 14:18:18 UTC
(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
Comment 7 Jim Raykowski 2019-12-19 07:17:41 UTC
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.
Comment 8 pranesh ulleri 2020-01-20 12:44:34 UTC
can I work on it? (my first easy hack)
Comment 9 Buovjaga 2020-01-20 12:54:22 UTC
(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
Comment 10 pranesh ulleri 2020-01-25 10:03:29 UTC
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.
Comment 11 Mike Kaganski 2020-01-25 10:59:47 UTC
(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.
Comment 12 pranesh ulleri 2020-01-26 10:10:03 UTC
(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.
Comment 13 Buovjaga 2020-01-26 10:38:21 UTC
(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.
Comment 14 pranesh ulleri 2020-01-27 13:32:38 UTC
(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
Comment 15 pranesh ulleri 2020-01-28 13:19:44 UTC
I have pushed the code: https://gerrit.libreoffice.org/c/core/+/87534
Comment 16 pranesh ulleri 2020-02-01 17:36:59 UTC Comment hidden (obsolete)
Comment 17 pranesh ulleri 2020-02-01 17:37:50 UTC Comment hidden (obsolete)
Comment 18 pranesh ulleri 2020-02-04 03:10:39 UTC
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.
Comment 19 pranesh ulleri 2020-02-04 03:12:10 UTC
small correction: last selected button before "OK" remains focused.
Comment 20 pranesh ulleri 2020-02-24 11:31:16 UTC Comment hidden (obsolete)
Comment 21 pranesh ulleri 2020-02-24 11:33:00 UTC
I have submitted a new patch(7) pls review and give suggestions. :)