Re: Application menus
What is about multi-monitor-setups? If an application with an Application-Menu is moved to a non-primary-screen, the Application-Menu is only accessible on the primary-screen. This requires a user to move the visual focus from the non-primary-screen to the primary-screen. Examples which make this issue clearly are Empathy or the Gnome-Calculator. The only feasible solution I can imagine is to show the black-bar a top also on the non-primary-screen, without the date/time, notifications and user-menu. Pro: Obvious solution and simple to use, every user will grasp it Con: Some lost pixels at top, Settings-Displays will need to show more clearly what the primary-screen is (currently often missed, only the tiny black-bar indicates this) Or did I miss the obvious solution? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Fri, Jul 05, 2013 at 11:01:24AM +0200, Bastien Nocera wrote: On Fri, 2013-07-05 at 08:45 +0100, David Woodhouse wrote: On Thu, 2013-07-04 at 16:18 -0500, Michael Catanzaro wrote: I haven't seen an app menu (gmenu) discussion in quite some time, which is a bit surprising as more apps add them. 3.10 will be the fourth release featuring app menus, and by now most GNOME applications have one. But the only information on the GNOME wiki seems to have been written for GNOME 3.4, and there seem to be some issues and inconsistencies with the implementation throughout the project. I've been using GNOME all that time and I'd never noticed them. This is the one in the top panel which, with focus-follows-mouse, Which is exactly one of the reasons why focus-follows-mouse isn't an option we offer/isn't supported. There's probably plenty more things that don't work well with focus-follows-mouse, so finding creative solutions to those problems might be required. This seems backward. F-f-m was here first, and is still being used by some minority (me included). Current designs break f-f-m functionality. Your comment about ”finding creative solutions” sounds like F-f-m was something new. Designs were made in total ignorance of f-f-m. The requirement should be restated as ”finding creative solutions for things that used to work”, i.e. things that were already working, were ”solved”. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Sun, 2013-07-07 at 15:05 +0200, Tomasz Torcz wrote: This seems backward. F-f-m was here first, and is still being used by some minority (me included). Current designs break f-f-m functionality. Your comment about ”finding creative solutions” sounds like F-f-m was something new. Designs were made in total ignorance of f-f-m. The requirement should be restated as ”finding creative solutions for things that used to work”, i.e. things that were already working, were ”solved”. Concept for a shell extension: Show the app menu not based on which window currently has focus, but which window most recently had focus for X amount of time. (I guess 1 second would be good?) When set to 0, that would degrade to which window is currently focused, the current behavior. That way you could mouse over a window briefly, and while that window would gain focus, the shell would still be showing the app menu for the original window you were working with. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
We actually tried a wide variety of solutions to make f-f-m work with the application menu, and landed one that tested well. See https://bugzilla.gnome.org/show_bug.cgi?id=678169 On Sun, Jul 7, 2013 at 10:30 AM, Michael Catanzaro mike.catanz...@gmail.com wrote: On Sun, 2013-07-07 at 15:05 +0200, Tomasz Torcz wrote: This seems backward. F-f-m was here first, and is still being used by some minority (me included). Current designs break f-f-m functionality. Your comment about ”finding creative solutions” sounds like F-f-m was something new. Designs were made in total ignorance of f-f-m. The requirement should be restated as ”finding creative solutions for things that used to work”, i.e. things that were already working, were ”solved”. Concept for a shell extension: Show the app menu not based on which window currently has focus, but which window most recently had focus for X amount of time. (I guess 1 second would be good?) When set to 0, that would degrade to which window is currently focused, the current behavior. That way you could mouse over a window briefly, and while that window would gain focus, the shell would still be showing the app menu for the original window you were working with. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Sun, Jul 7, 2013 at 2:10 PM, bugs b...@ttyhoney.com wrote: What is about multi-monitor-setups? If an application with an Application-Menu is moved to a non-primary-screen, the Application-Menu is only accessible on the primary-screen. This requires a user to move the visual focus from the non-primary-screen to the primary-screen. Examples which make this issue clearly are Empathy or the Gnome-Calculator. The only feasible solution I can imagine is to show the black-bar a top also on the non-primary-screen, without the date/time, notifications and user-menu. Pro: Obvious solution and simple to use, every user will grasp it Con: Some lost pixels at top, Settings-Displays will need to show more clearly what the primary-screen is (currently often missed, only the tiny black-bar indicates this) Or did I miss the obvious solution? https://bugzilla.gnome.org/show_bug.cgi?id=695377 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Sun, 2013-07-07 at 14:10 +0200, bugs wrote: What is about multi-monitor-setups? If an application with an Application-Menu is moved to a non-primary-screen, the Application-Menu is only accessible on the primary-screen. This is https://bugzilla.gnome.org/show_bug.cgi?id=695377 by the way. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
On Fri, 2013-07-05 at 22:04 +0100, David Woodhouse wrote: Focus-follows-mouse makes it worse (especially when it's a trackpad, and a large screen, and a small application like empathy which happens to be on the *other* side of the screen for where its bizarrely detached menu now lives. I don't think the app menu is well thought-out enough (footnote: it seems that the new MacOS puts a menu bar in all monitors, which sounds like a good idea). Regardless of that... I used to be a firm believer in focus-follows-mouse, and I switched to click-to-focus recently after about 18 years of FFM. About the only two things that bothered me about FFM were that muggles would get massively confused when borrowing my computer, and that the Gimp's layers dialog didn't work quite right (it shows the layers for the focused image window). Then the app menu appeared, and since Empathy and Totem pretty much forced me to use it, I switched to click-to-focus. It took me about a month to get used to CTF. I don't mind it now so much. The scrollwheel thankfully works on unfocused windows. About the only things that became clunkier are debugging GUI apps (for which I should really have been using a second computer, anyway, but focus-follows-mouse kind of made it possible), and bgo#687850 (two monitors, wrong focus when switching workspaces). Oddly enough, even before the transition period, using my wife's Mac and being forced to use click-to-focus there didn't seem uncomfortable. Expectations, or not being used to using that system as fluidly, I guess. TL;DR Switching from focus-follows-mouse to click-to-focus was painful, worth it, and I don't have a good reason to defend either these days. YMMV. Also, there are real bugs in either mode that seem to get little attention because they are in Mutter rather than in Gnome-shell. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application menus
Where a bug is doesn't matter: all GNOME Shell hackers work on mutter and vice versa. Mutter exists just so we can reuse metacity's solid WM core, rather than reinventing it. If there's bugs that you feel are getting attention, I'll try and take a look at them. On Sun, Jul 7, 2013 at 11:16 PM, Federico Mena Quintero feder...@gnome.orgwrote: On Fri, 2013-07-05 at 22:04 +0100, David Woodhouse wrote: Focus-follows-mouse makes it worse (especially when it's a trackpad, and a large screen, and a small application like empathy which happens to be on the *other* side of the screen for where its bizarrely detached menu now lives. I don't think the app menu is well thought-out enough (footnote: it seems that the new MacOS puts a menu bar in all monitors, which sounds like a good idea). Regardless of that... I used to be a firm believer in focus-follows-mouse, and I switched to click-to-focus recently after about 18 years of FFM. About the only two things that bothered me about FFM were that muggles would get massively confused when borrowing my computer, and that the Gimp's layers dialog didn't work quite right (it shows the layers for the focused image window). Then the app menu appeared, and since Empathy and Totem pretty much forced me to use it, I switched to click-to-focus. It took me about a month to get used to CTF. I don't mind it now so much. The scrollwheel thankfully works on unfocused windows. About the only things that became clunkier are debugging GUI apps (for which I should really have been using a second computer, anyway, but focus-follows-mouse kind of made it possible), and bgo#687850 (two monitors, wrong focus when switching workspaces). Oddly enough, even before the transition period, using my wife's Mac and being forced to use click-to-focus there didn't seem uncomfortable. Expectations, or not being used to using that system as fluidly, I guess. TL;DR Switching from focus-follows-mouse to click-to-focus was painful, worth it, and I don't have a good reason to defend either these days. YMMV. Also, there are real bugs in either mode that seem to get little attention because they are in Mutter rather than in Gnome-shell. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
