Header bar: Keyboard accessibility?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Header bar: Keyboard accessibility?

Yuri Khan
Hello everybody.

I have heard of desktop environments that display the application menu
in a dedicated place (GNOME Shell, OS X). Presumably, in that case the
desktop environment provides a key that the user can press to open the
application menu.

I am not on such a system. That means every GTK application has to
display its menu in its own window.

There are basically two ways to do that. By default,
GtkApplicationWindow displays a menu bar with the application menu as
its first menu. In this case, F10 opens the menu.

Another way is to add a GtkHeaderBar to the window, call
gtk_application_window_set_show_menubar(false) and
gtk_header_bar_set_show_close_button(true). In this case, the header
bar shows an unfocusable button that, when clicked, displays the
application menu.


And now for the title question. In this latter scenario, how does the
user access the application menu without having to use a pointing
device? Is every application supposed to implement that? As a
developer, how would I go about that? As a user, what do I say in the
bug report when an application neglects this?

In a demo application, I was able to add an F10 accelerator to a
window action that walks the widget tree of the header bar and
activates the first GtkMenuButton it finds, but this really screams
“implementation details” and “support nightmare”.
_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Header bar: Keyboard accessibility?

Michael Torrie
On 06/22/2017 12:03 PM, Yuri Khan wrote:
> And now for the title question. In this latter scenario, how does the
> user access the application menu without having to use a pointing
> device? Is every application supposed to implement that? As a
> developer, how would I go about that? As a user, what do I say in the
> bug report when an application neglects this?

All the Gnome 3 apps that use a header bar that I have at my disposal
let me open the application menu with F10.  Even when I run the app
under the most primitive window manager out there, TWM.  Are they doing
something different than your app?


_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Header bar: Keyboard accessibility?

Yuri Khan
On Fri, Jun 23, 2017 at 11:15 AM, Michael Torrie <[hidden email]> wrote:

> All the Gnome 3 apps that use a header bar that I have at my disposal
> let me open the application menu with F10.  Even when I run the app
> under the most primitive window manager out there, TWM.  Are they doing
> something different than your app?

What GTK3 version are you on? Could you make a screenshot so I could
see we’re talking about the same thing?

I’m on 3.18, and here’s my test application/mockup:

http://yurikhan.github.io/images/20170623-gtk-header-bar.png

In my testing, F10 focuses the first focusable control in the header
bar, if any.

This happens in gtk/gtkwindow.c, function gtk_window_activate_menubar.
First, it checks if the window has a title bar and whether focus is
inside it; if not, it focuses the title bar, which presumably causes
its first focusable descendant to be focused. If it is, it focuses the
next menu bar if any.

The button that houses the application menu fallback is created as
unfocusable, and it has been that way since 2013.

https://git.gnome.org/browse/gtk+/commit/?id=d9f9242
_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Header bar: Keyboard accessibility?

Michael Torrie
On 06/23/2017 11:15 AM, Yuri Khan wrote:
> What GTK3 version are you on? Could you make a screenshot so I could
> see we’re talking about the same thing?

Gtk 3.20 here.

>
> I’m on 3.18, and here’s my test application/mockup:
>
> http://yurikhan.github.io/images/20170623-gtk-header-bar.png

Oh I see. Yes that's different.  The application menu usually refers (at
least in my mind) to the now ubiquitous hamburger menu that all Gnome
apps seem to sport. I guess what you're trying to trigger is what we
used to call the window menu?  In the old days before client-side
decorations, alt-space would trigger that menu.




_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Header bar: Keyboard accessibility?

Yuri Khan
On Sat, Jun 24, 2017 at 1:21 AM, Michael Torrie <[hidden email]> wrote:

>> I’m on 3.18, and here’s my test application/mockup:
>>
>> http://yurikhan.github.io/images/20170623-gtk-header-bar.png
>
> Oh I see. Yes that's different.  The application menu usually refers (at
> least in my mind) to the now ubiquitous hamburger menu that all Gnome
> apps seem to sport.

In *your* *mind*? Application menu is an official term. The menu that
is assigned via gtk_application_set_app_menu.

What you are describing is called the “gear menu”. The only
application I have seen so far where it was activated with F10 is
Gitg. And Gedit tries to do that too, unsuccessfully.

> I guess what you're trying to trigger is what we
> used to call the window menu?  In the old days before client-side
> decorations, alt-space would trigger that menu.

And no, that is not the window menu. The window menu of the old days
would contain the window-manager-defined commands such as Move,
Resize, Minimize, Maximize and Close. The application menu is fully
application-defined. And applications put important functionality
there, such as displaying the preferences box.
_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Header bar: Keyboard accessibility?

Michael Torrie
On 06/23/2017 12:35 PM, Yuri Khan wrote:

> On Sat, Jun 24, 2017 at 1:21 AM, Michael Torrie <[hidden email]> wrote:
>
>>> I’m on 3.18, and here’s my test application/mockup:
>>>
>>> http://yurikhan.github.io/images/20170623-gtk-header-bar.png
>>
>> Oh I see. Yes that's different.  The application menu usually refers (at
>> least in my mind) to the now ubiquitous hamburger menu that all Gnome
>> apps seem to sport.
>
> In *your* *mind*? Application menu is an official term. The menu that
> is assigned via gtk_application_set_app_menu.

You're right, and this does seem like a pretty serious oversight.  I see
that gedit did not have (at least on my version of gnome) an application
menu at all.  gnome-calculator does, though, and it's definitely not
keyboard accessible, which is a very strange design choice, if it's not
a bug.

> What you are describing is called the “gear menu”. The only
> application I have seen so far where it was activated with F10 is
> Gitg. And Gedit tries to do that too, unsuccessfully.

I've looked at a few Gnome 3 apps just now and F10 was able to open the
gear menu for all of those, including Gedit.  I'm not using Gnome 3 as a
desktop environment.


_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Loading...