After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743591 - View popover - list/grid toggle has inconsistent behaviour
View popover - list/grid toggle has inconsistent behaviour
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
3.15.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-27 17:06 UTC by Allan Day
Modified: 2015-02-03 17:39 UTC
See Also:
GNOME target: 3.16
GNOME version: ---


Attachments
nautilus-window-slot: Don't grab focus on view change (1.55 KB, patch)
2015-02-02 13:22 UTC, Carlos Soriano
committed Details | Review

Description Allan Day 2015-01-27 17:06:48 UTC
The view popover stays open after you use any of the controls... except the grid/list toggle. It's inconsistent.

It would be better if the toggle behaved the same as the other controls.
Comment 1 Allan Day 2015-01-27 17:08:31 UTC
Adding to the 3.16 list, since this is an issue with a new feature.
Comment 2 Carlos Soriano 2015-01-27 18:54:12 UTC
It's gtk+ behaviour, moving to it.
Comment 3 Matthias Clasen 2015-01-28 21:28:13 UTC
the example for linked toggle radio buttons in gtk+/tests/testpopover behaves as expected.
Comment 4 Carlos Soriano 2015-01-29 09:35:00 UTC
(In reply to comment #3)
> the example for linked toggle radio buttons in gtk+/tests/testpopover behaves
> as expected.

Allan is proposing that the linked buttons should dismiss the popover as well.
Comment 5 Cosimo Cecchi 2015-01-29 09:58:17 UTC
I'll let Allan comment, but I am pretty sure the intention is to have the linked toggles behave as the other controls and not dismiss the popover, rather than the opposite.
Comment 6 Allan Day 2015-01-29 10:15:25 UTC
(In reply to comment #5)
> I'll let Allan comment, but I am pretty sure the intention is to have the
> linked toggles behave as the other controls and not dismiss the popover, rather
> than the opposite.

That's correct.
Comment 7 Matthias Clasen 2015-01-29 18:51:03 UTC
Oh, hmm. So, do we have some sort of rationale for what kind of controls will close the popover ? The current implementation in GTK+ closes just for straight buttons, and keeps the popover open for check buttons, radio buttons, scales, etc.
Comment 8 Cosimo Cecchi 2015-01-29 19:16:28 UTC
Matthias, is there a rationale for the existing behavior of buttons closing it?
Comment 9 Matthias Clasen 2015-01-29 19:32:24 UTC
"its what menus do" ?
Comment 10 Allan Day 2015-01-30 16:10:46 UTC
The basic principle is "keep the popover open if it contains controls that are likely to require further adjustment".

You could interpret that as: "don't close a popover after a state or range has been adjusted" (eg. radios, check boxes, switches, toggle buttons, sliders), although I'm not 100% that that will work for all cases.
Comment 11 Carlos Soriano 2015-02-02 10:08:00 UTC
Ok, I misunderstood it. So the popover in gtk+ is dismissing appropriately, like Allan wants. It's nautilus fault, because how nautilus implemented the creating of the menu in the port to gaction/gmenu.

I'll figure out how to do it differently, currently we are recreating the menu when the view loads, so probably we will have to avoid that and instead only hide/show items.
Comment 12 Carlos Soriano 2015-02-02 13:22:31 UTC
So, actually I was wrong. After Cosimo changes after the merge of the gmenu port, we no longer recreate the menu after every view load, which is nice. So the problem was in other place (and is an old problem, not something from the port). See next patch
Comment 13 Carlos Soriano 2015-02-02 13:22:51 UTC
Created attachment 295940 [details] [review]
nautilus-window-slot: Don't grab focus on view change

We were grabbing the focus on view mode change, so if the user changed
the view mode with keyboard he could continue using it.
But it makes the problem that with the new popover menu in the toolbar
where you can choose between different views while the menu is open,
grabbing the focus to another widget dismiss the menu, which is
against the behavior of the GtkMenuPopover.

To fix that, don't grab focus on view changes.

In the tests I have done, you can still focus the view just using the
arrows after the view changes, so I don't think it will be a problem for
keyboard users.
Comment 14 Cosimo Cecchi 2015-02-03 17:39:17 UTC
Looks good, pushed to master.

Attachment 295940 [details] pushed as 982469e - nautilus-window-slot: Don't grab focus on view change