On Fri, 2013-07-05 at 11:01 +0200, Bastien Nocera wrote:
Which is exactly one of the reasons why focus-follows-mouse isn't an
option we offer/isn't supported.
Umm, it is offered, and appears to be supported. It can be enabled in
Tweak tool. I say it appears to be supported, because a delay was
On 07/05/2013 10:19:16 AM Fri, Sam Bull wrote:
On Fri, 2013-07-05 at 11:01 +0200, Bastien Nocera wrote:
Which is exactly one of the reasons why focus-follows-mouse isn't an
option we offer/isn't supported.
Umm, it is offered, and appears to be supported. It can be enabled in
Tweak tool. I say
On Mon, 08 Jul 2013 11:09:37 +0100, David Woodhouse dw...@infradead.org
wrote:
On Sun, 2013-07-07 at 14:10 +0200, bugs wrote:
Or did I miss the obvious solution?
Well, there's always the revolutionary idea of putting the application's
menu somewhere near the application, rather than two
https://bugzilla.gnome.org/show_bug.cgi?id=695377
Thank you.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Tue, 2013-07-09 at 12:55 +0200, bugs wrote:
Well. That sounds pretty much like the awful implemetations of Unity
(Ubuntu) and MacOS (Apple). As far as I understand the
Application-Menu should not replace regular menues, but instead offer
a addition to to regular menues, with only some
Should I file a bug?
Depends on the application and developers?
https://bugzilla.gnome.org/show_bug.cgi?id=695377
I assume that Empathy, GNOME-Calculator and so on are now aware of the
fact that the made it wrong? Maybe you can check via gitweb if the next
release changes the usage of the
On Wed, 2013-07-10 at 00:17 +0200, bugs wrote:
Should I file a bug?
Depends on the application and developers?
https://bugzilla.gnome.org/show_bug.cgi?id=695377
I assume that Empathy, GNOME-Calculator and so on are now aware of the
fact that the made it wrong? Maybe you can check via
On Mon, Jul 8, 2013 at 2:48 AM, Bastien Nocera had...@hadess.net wrote:
On Sun, 2013-07-07 at 15:05 +0200, Tomasz Torcz wrote:
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,
On Mon, 2013-07-08 at 02:52 -0400, Jasper St. Pierre wrote:
On Mon, Jul 8, 2013 at 2:48 AM, Bastien Nocera had...@hadess.net
wrote:
On Sun, 2013-07-07 at 15:05 +0200, Tomasz Torcz wrote:
On Fri, Jul 05, 2013 at 11:01:24AM +0200, Bastien Nocera
wrote:
On Mon, Jul 8, 2013 at 2:57 AM, Bastien Nocera had...@hadess.net wrote:
On Mon, 2013-07-08 at 02:52 -0400, Jasper St. Pierre wrote:
On Mon, Jul 8, 2013 at 2:48 AM, Bastien Nocera had...@hadess.net
wrote:
On Sun, 2013-07-07 at 15:05 +0200, Tomasz Torcz wrote:
On
Because it's unsupported.
As someone who works on mutter and gnome-shell, I'm curious: since
when is it unsupported? I've never heard anybody say this before.
It's not the default, it's not togglable in System Settings, and it's
not been designed for. That makes it
On Sun, 2013-07-07 at 14:10 +0200, bugs wrote:
Or did I miss the obvious solution?
Well, there's always the revolutionary idea of putting the application's
menu somewhere near the application, rather than two feet away at the
opposite corner of the screen.
But if hiding it somewhere a long
On Sun, 2013-07-07 at 23:26 -0400, Jasper St. Pierre wrote:
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
On Mon, Jul 8, 2013 at 6:46 PM, Federico Mena Quintero
feder...@gnome.org wrote:
Hey, thanks :) That bug about focusing the wrong window when you flip
workspaces / monitors is the one giving me the most grief right now
(#687850).
There's another bug which I can't find right now, about
On Fri, 2013-07-05 at 11:08 +0100, Emmanuele Bassi wrote:
1) For applications that retain a traditional menu bar, there's
inconsistency in whether options added to the app menu are also removed
from the traditional menu. E.g. Gedit and Totem (3.6/3.8) removed Help,
About, and Preferences
On Mon, 2013-07-08 at 12:53 -0500, Michael Catanzaro wrote:
I really hope we can agree on and enforce a solution that provides
consistency between apps that retain traditional menubars. Maybe it'd be
easier to agree on duplicating the items than moving them.
That would certainly alleviate my
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
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
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.
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
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
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.
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
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,
Michael Catanzaro mike.catanz...@gmail.com writes:
[...]
3) There's significant inconsistency in menu elements. Half place About
above Help, half below. Half say About program name and half leave
out the program name. Some new ones don't even have Quit -- I'm looking
at GNOME Terminal and
On Sat, 2013-07-06 at 09:31 +0200, Carlos Garcia Campos wrote:
So, we either leave the
about in the window menu (it's a modal dialog of the window) or we make
the about dialog actually global and not modal.
I see your point. But I also think it's very valuable to have Help,
About, and Quit
On Sat, Jul 6, 2013 at 6:34 PM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Maybe it'd be
acceptable for Quit to affect only the current window, since that's the
most natural behavior.
Or may be just rename Quit to Close all windows? At least if
application exits when the last window
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
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
not downstream, and thus can patch all non-complying applications.
application menus are not a GTK-only feature: other applications can
expose their menu structure on the session bus, and the Shell will
pick it up — assuming they namespace the actions.
the actions API is also being moved under
On Fri, 2013-07-05 at 11:08 +0100, Emmanuele Bassi wrote:
1) For applications that retain a traditional menu bar, there's
inconsistency in whether options added to the app menu are also removed
from the traditional menu.
yes. file bugs against applications that do not move them
On Fri, 2013-07-05 at 11:01 +0200, Bastien Nocera wrote:
Which is exactly one of the reasons why focus-follows-mouse isn't an
option we offer/isn't supported.
Focus-follows-mouse makes it worse (especially when it's a trackpad, and
a large screen, and a small application like empathy which
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,
we watch for applications that both
application menus and window menus and display both in the Unity menu
bar. So an application that has both would get something like:
[Application Name] [File] [Edit]
But then, perhaps obviously, if there are no window menus only the
application menu
lists, but just to clear up any
confusion. In indicator-appmenu we watch for applications that both
application menus and window menus and display both in the Unity menu
bar. So an application that has both would get something like:
[Application Name] [File] [Edit]
But then, perhaps
On Thu, 2012-04-26 at 11:54 -0400, Jasper St. Pierre wrote:
On Thu, Apr 26, 2012 at 10:53 AM, Ted Gould t...@gould.cx wrote:
While there are few today, our goal here was to ensure that as new
applications are developed it is expected that they'd use GMenuModel
instead of traditional GTK
36 matches
Mail list logo
