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 648305 - Log Out dialog should appear on primary monitor when no window has focus
Log Out dialog should appear on primary monitor when no window has focus
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 670740 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-20 14:23 UTC by Adam Dingle
Modified: 2017-11-02 21:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (764 bytes, patch)
2011-04-21 14:03 UTC, Adam Dingle
reviewed Details | Review
updated patch (964 bytes, patch)
2011-04-26 16:18 UTC, Adam Dingle
committed Details | Review

Description Adam Dingle 2011-04-20 14:23:19 UTC
I'm using GNOME Shell 3.0.0.2 on Fedora 15.  I have two monitors: a laptop display on the left, and a external monitor on the right.  The external monitor is primary: that's where the GNOME Shell panel appears.

When I choose Log Out from the system menu, if any window is active then GNOME Shell displays the Log Out dialog on the monitor containing that window.  That's fine.  However, if no window is active the the Log Out dialog appears on my laptop display. It should instead appear on the primary (external) monitor.
Comment 1 Adam Dingle 2011-04-21 14:03:38 UTC
Created attachment 186429 [details] [review]
patch

Easy to fix.  Here's a patch.
Comment 2 drago01 2011-04-22 19:37:25 UTC
Review of attachment 186429 [details] [review]:

No this is wrong, you are changing the semantics of that function instead of just calling the the correct one (i.e in the JS code).
Comment 3 drago01 2011-04-22 19:43:18 UTC
(In reply to comment #0)
> I'm using GNOME Shell 3.0.0.2 on Fedora 15.  I have two monitors: a laptop
> display on the left, and a external monitor on the right.  The external monitor
> is primary: that's where the GNOME Shell panel appears.
> 
> When I choose Log Out from the system menu, if any window is active then GNOME
> Shell displays the Log Out dialog on the monitor containing that window. 
> That's fine.  However, if no window is active the the Log Out dialog appears on
> my laptop display. It should instead appear on the primary (external) monitor.

It appears on the focused monitor (i.e the monitor where you are probably interacting with at the moment).

Changing that is easy the question is whether we want that or not. It would make sense to be consistent with alt-tab and the workspace switcher; but the current situation isn't bad either. So lets gets the designers opinion(s).
Comment 4 Adam Dingle 2011-04-26 14:59:09 UTC
Here's how things work today:

- Alt+Tab and the Activities overview always appear on the primary monitor.
- All GNOME Shell dialogs (including the logout dialog, the Alt+F2 Run dialog and authentication dialogs) appear on the focused monitor, i.e. the monitor containing the focused window.  If no window has focus, these dialogs appear on monitor 0 (which might or might not be the primary monitor).

My patch above makes only a tiny change to the above: if no window has focus, we now use the primary monitor rather than monitor 0.  If any window has focus, my patch has no effect.  I think this is clearly a beneficial change.

A larger question is whether some or all dialogs should appear on the primary monitor rather than the focused monitor.  I think that's beyond the scope of this bug report, but you could certainly open another bug if you'd like to propose changing that.
Comment 5 drago01 2011-04-26 15:20:07 UTC
(In reply to comment #4)
> Here's how things work today:
> 
> - Alt+Tab and the Activities overview always appear on the primary monitor.
> - All GNOME Shell dialogs (including the logout dialog, the Alt+F2 Run dialog
> and authentication dialogs) appear on the focused monitor, i.e. the monitor
> containing the focused window.  If no window has focus, these dialogs appear on
> monitor 0 (which might or might not be the primary monitor).
> 
> My patch above makes only a tiny change to the above: if no window has focus,
> we now use the primary monitor rather than monitor 0.  If any window has focus,
> my patch has no effect.  I think this is clearly a beneficial change.

Oh ... sorry misread your patch, yeah that makes sense.
Comment 6 drago01 2011-04-26 15:21:33 UTC
Review of attachment 186429 [details] [review]:

Sorry was wrong before, the patch looks correct.

Remove the "[PATCH]" from the subject and add a commit body, otherwise fine.
Comment 7 Adam Dingle 2011-04-26 16:18:26 UTC
Created attachment 186664 [details] [review]
updated patch

Thanks for the review.  Here's an updated patch including a commit body.  I've removed [PATCH] as requested, though I don't actually understand why that's necessary since 'git am' will strip it automatically when applying a commit.

I don't yet have a GNOME account, so can you commit this?
Comment 8 drago01 2011-04-26 19:08:34 UTC
(In reply to comment #7)
> Created an attachment (id=186664) [details] [review]
> updated patch
> 
> Thanks for the review.  Here's an updated patch including a commit body.  I've
> removed [PATCH] as requested, though I don't actually understand why that's
> necessary since 'git am' will strip it automatically when applying a commit.

Yeah it wouldn't do that if you pushed it directly from your tree but given that you don't have a gnome account that does not apply.

> I don't yet have a GNOME account, so can you commit this?

Sure and thanks for the patch.
Comment 9 Owen Taylor 2011-05-24 22:39:35 UTC
Bit confused here - I agree that this patch conceptually made sense, but meta_screen_get_primary_monitor always returns 0 at the moment (check mutter/src/screen.c) so I don't see how it changed anything.

Reopening here in case there is some other bug involved, I thought I saw misbehavior once in testing, but couldn't reproduce - in subsequent testing it seemed to work fine with or without this patch.
Comment 10 drago01 2011-05-25 10:05:52 UTC
(In reply to comment #9)
> Bit confused here - I agree that this patch conceptually made sense, but
> meta_screen_get_primary_monitor always returns 0 at the moment (check
> mutter/src/screen.c) so I don't see how it changed anything.

Oh .. I didn't notice that Alex changed shell_global_get_primary_monitor to use meta_screen_get_primary_monitor instead of the GDK code we had before. If this indeed always returns 0 it would break lots of things.

But checking the code in mutter this does not seem to be the case:

int
meta_screen_get_primary_monitor (MetaScreen *screen)
{
  g_return_val_if_fail (META_IS_SCREEN (screen), 0);

  return screen->primary_monitor_index;
}

where the index is set in reload_monitor_infos() (which uses the xinerama information etc etc).
Comment 11 Owen Taylor 2011-05-25 15:42:50 UTC
(In reply to comment #10)
> int
> meta_screen_get_primary_monitor (MetaScreen *screen)
> {
>   g_return_val_if_fail (META_IS_SCREEN (screen), 0);
> 
>   return screen->primary_monitor_index;
> }
> 
> where the index is set in reload_monitor_infos() (which uses the xinerama
> information etc etc).

Look what it's set to in reload_monitor_infos().
Comment 12 Florian Müllner 2011-05-25 15:54:21 UTC
(In reply to comment #11)
> Look what it's set to in reload_monitor_infos().

Alex claims in http://git.gnome.org/browse/mutter/commit?id=f9b5cdfeb1a that the primary monitor is always the first one returned by Xinerama.
Comment 13 Florian Müllner 2011-05-25 15:56:22 UTC
Of course this may now be a case of mutter<->shell incompatibility you mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=609258#c130 ...
Comment 14 Allan Day 2014-08-07 10:41:22 UTC
What's the status of this bug?
Comment 15 Alexandre Franke 2017-11-01 11:00:54 UTC
I assume this can be considered fixed. Feel free to reopen with an explanation if it’s not.
Comment 16 Alexandre Franke 2017-11-02 21:56:59 UTC
*** Bug 670740 has been marked as a duplicate of this bug. ***