You Should Be Able to Clear a Popover by Clicking Inside an Application

Bug #1011185 reported by NewfieBullet
68
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Granite
Fix Released
High
Unassigned

Bug Description

In elementary applications that make use of a popover, if one person clicked the button that made the popover appear, it would be very difficult to make it disappear by a number of methods that would make a normal menu disappear easily.

For instance, in Maya Calender, the button 'select calenders to display' will make a popover appear for that specific function. If anyone wanted to make the popover disappear like any other menu in elementary they would need to, click the title bar of the window or by clicking another application. Clicking the desktop, inside of the app, or the button again will not get clear the popover.

This is a usability issue that affects many applications in elementary and should not be apart of the popover function.

Related branches

NewfieBullet (n-bullet)
summary: - You Should Be Able to Get Rid of a Popover By Clicking Inside an
- application
+ You Should Be Able to Clear a Popover By Clicking Inside an application
summary: - You Should Be Able to Clear a Popover By Clicking Inside an application
+ You Should Be Able to Clear a Popover By Clicking Inside an Application
summary: - You Should Be Able to Clear a Popover By Clicking Inside an Application
+ You Should Be Able to Clear a Popover by Clicking Inside an Application
Changed in elementaryos:
assignee: nobody → elementary UX Team (elementary-design)
Revision history for this message
eyelash (eyelash) wrote :

I believe the problem is that if you call run() on a PopOver it becomes modal (because its parent Gtk.Dialog does so) which means the parent window can neither receive events nor become active which in turn prevents the PopOver from disappearing.

Revision history for this message
Tom Beckmann (tombeckmann) wrote :

It could be fixed by removing any run() call and just starting with show_all() instead.
You'd most problably also have to change the focus_out handler, here it only worked properly without the checks for toplevel type, so just a plain destroy() without the checks, which should be fine in most cases, in others it might not be good.

Revision history for this message
Akshay Shekher (voldyman) wrote :

@Tom i tried removing run ( ) and using show_all ( ) in a test application but the bug still persists.
you simple cannot close the popover until you click on the titlebar or out site the dialog.

Revision history for this message
Tom Beckmann (tombeckmann) wrote :

You also have to change the focus_out event handler.
My fix for this looks like this: http://bazaar.launchpad.net/~tombeckmann/gwoffice/gwoffice/view/head:/src/Widgets/PopOver.vala
For starting, as mentioned, no run() should be called.

Revision history for this message
Cody Garver (codygarver) wrote :

So, this bug is sort of intended behavior. Because the popover believes itself to be a window, not a menu. I propose a separate popover be created, for popover menus. Popover menus would hide on focus lost, popover windows would not.

Revision history for this message
Tom Beckmann (tombeckmann) wrote :

How would you close popover windows then?

Revision history for this message
Cody Garver (codygarver) wrote :

FFFUUU I don't know.

Revision history for this message
Danielle Foré (danrabbit) wrote :

Yea I don't think we want to create a case where users have to guess if it's a "menu" popover or a "window" popover. I think in general the expectation is that you can dismiss it in the same manner as you would a menu.

Revision history for this message
Cassidy James Blaede (cassidyjames) wrote :

Yep definitely agree with Dan here. Any way you dismiss a menu should dismiss a popover. This includes clicking anywhere that's not within the popover, for example.

Changed in elementaryos:
assignee: elementary UX Team (elementary-design) → nobody
Changed in granite:
status: New → Fix Committed
no longer affects: elementaryos
Changed in granite:
milestone: none → luna-beta1
Changed in granite:
importance: Undecided → High
Changed in granite:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.