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 658239 - alt-tab application list doesn't have icons on multi-head when primary is at the right
alt-tab application list doesn't have icons on multi-head when primary is at ...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.1.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-09-05 09:44 UTC by Ionut Biru
Modified: 2011-09-19 16:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of the bug (135.37 KB, image/jpeg)
2011-09-07 08:12 UTC, Alexander Larsson
  Details
altTab: Don't count our position twice when determining whether to scroll (1.18 KB, patch)
2011-09-07 09:26 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review
altTab: Fix icon scrolling (1.46 KB, patch)
2011-09-07 10:04 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review
altTab: Fix icon scrolling (1.44 KB, patch)
2011-09-07 15:19 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review

Description Ionut Biru 2011-09-05 09:44:51 UTC
Gnome-shell 3.1.90.1 running on multi-head, when the primary monitor is set up on the monitor from the right, alt-tab doesn't have any apps in the list, as in the screenshot attached.

If i move primary back to the left, alt-tab shows the right apps.


gnome-shell 3.1.90.1-1
mutter 3.1.90.1-1
Comment 1 Ionut Biru 2011-09-05 09:46:19 UTC
sorry.the bugtracker doesn't let me upload this screenshot.

here is the link:
http://ompldr.org/vYTdqdg
Comment 2 Rui Matos 2011-09-06 00:06:51 UTC
I can't reproduce this. Can you give us more details?
Comment 3 Ionut Biru 2011-09-06 05:56:52 UTC
i have a laptop one which i have a 1280x800 resolution and an external screen, 1920x1090.

In the display configuration I'm setting up the primary monitor to be the big screen, which is in the right in my setup.

What other details you want to know?
Comment 4 Alexander Larsson 2011-09-06 14:12:57 UTC
I see this too.
I have a 1280x1024 rotated screen on the left (so 1024x1280) and a 1920x1080 screen on the right.

If the right screen is primary i get no alt-tab icons, if the left one is i do get them.

This is with F15 and the ati R600g drivers.
Comment 5 drago01 2011-09-06 17:51:22 UTC
(In reply to comment #4)
> I see this too.
> I have a 1280x1024 rotated screen on the left (so 1024x1280) and a 1920x1080
> screen on the right.
> 
> If the right screen is primary i get no alt-tab icons, if the left one is i do
> get them.
> 
> This is with F15 and the ati R600g drivers.

Hmm cannot reproduce this with just the primary at the right ... (don't have anything to test rotation with).
Comment 6 Alexander Larsson 2011-09-07 08:12:12 UTC
Rotation doesn't require anything special just choose a rotation (i have counterclockwise) in the Display pane in system settings.

However, if i unset the rotation i still get the bug, so it seems unrelated. Also, the fact that the right monitor is larger also doesn't seem to be the problem, lowering it doesn't fix the problem. It does however give a hint to the source of the problem. 

I'm attaching a screenshot of the results, this is with a left monitor (viewsonic) at 1024x1280 (i.e. rotated) and a primary right monitor (hp) at 1024x768. When I alt tab I do get *some* icons visible, but they are offset to the right. Then when I continue to press alt tab the icons scroll in to the left as new icons are being selected (i.e. it makes sure the currently selected on is visible).
Comment 7 Alexander Larsson 2011-09-07 08:12:50 UTC
Created attachment 195844 [details]
Screenshot of the bug
Comment 8 Jasper St. Pierre (not reading bugmail) 2011-09-07 09:26:17 UTC
Created attachment 195848 [details] [review]
altTab: Don't count our position twice when determining whether to scroll

get_transformed_position already includes its parent's size. This was causing
some obscure multimonitor bugs. Additionally, replace an incorrect 0 with the
primary monitor position.
Comment 9 Jasper St. Pierre (not reading bugmail) 2011-09-07 10:04:06 UTC
Created attachment 195850 [details] [review]
altTab: Fix icon scrolling

Don't depend on the primary monitor position for determining whether we should
scroll, just use our own container's size.



Alternate patch, not depending on monitor sizes.
Comment 10 Alexander Larsson 2011-09-07 11:19:39 UTC
The first patch works, but the second one causes the list of icons to scroll to the left when you step to the next icon, so that the selected icon is always on the far right, even when all icons fit on the screen.

Also, i said that the first patch work, but that is not quite right.
It mostly works at any particular icon size, however as you start to add icons it will fill the whole screen, then when you add an additional icon it will cause it to use the old icon size and force scrolling, rather than pick a smaller icon size. Also the rendering is weird, there is no spacing between the icons and the selected icon rectangle is not wide enough. However, if you add yet another icon, then it picks the next smaller icon size and all is fine (until you get to the limit of that icon size).

I tried to debug this, but it seems very tricky to find the underlying cause.
What I can see is that AppSwitcher._getPreferredHeight() is called multiple times during the showing of the alt-tab popup, and the first 4 time this line:
let [iconMinHeight, iconNaturalHeight] = this.icons[j].label.get_preferred_height(-1);

Returns a iconNaturalHeight of 21, but on the 5th and following times it returns 17. This causes some weird issues, because the value of iconNaturalHeight is propagated to iconSpacing, then to height and then to w, causing us to use different values of w in the w <= availWidth check, and thus to pick a different icon size after the 4th call, causing us to lay out things weirdly.

I tried to figure out why StLabel.get_preffered_height (-1) would return different values, but could only track it to the fact that clutter_text_get_preffered_height (-1) on st_label->priv->label returned a smaller value. Maybe some theme information changed the state of the label, affecting the font size or something...
Comment 11 Jasper St. Pierre (not reading bugmail) 2011-09-07 15:19:59 UTC
Created attachment 195885 [details] [review]
altTab: Fix icon scrolling

Don't depend on the primary monitor position for determining whether we should
scroll, just use our own container's size.



Whoops, I thought the "allocation" property was in absolute coords.
Comment 12 Alexander Larsson 2011-09-07 19:33:42 UTC
Last patch works for me, although it still has the problem described in comment 10, which seems to be bug #658480
Comment 13 Jasper St. Pierre (not reading bugmail) 2011-09-19 16:40:20 UTC
Attachment 195885 [details] pushed as 0f4ce5d - altTab: Fix icon scrolling