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 641603 - Windows in activity overview not resized correct
Windows in activity overview not resized correct
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal minor
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-02-05 14:22 UTC by Maximilian Ruta
Modified: 2013-09-07 01:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch - just concept (1.56 KB, patch)
2012-01-13 09:22 UTC, Vít Stanislav
needs-work Details | Review

Description Maximilian Ruta 2011-02-05 14:22:00 UTC
1. I go the the activity overview and drop a application to the desktop. (In this case pidgin which open up a second window)
2. I drag the main window of pidgin before the second window opens
3. If i drop the window the preview gets the size which it had before. it ignores the size of the second window.

A simple wordaround is to close and open the activity overview.
It seems that the gnome shell does recognize new popped up windows if you currently drag one of them.
Comment 1 Jonathan Strander 2011-02-08 23:51:28 UTC
I get an effect similar to what's described simply by zooming into a window while another window is being opened on the current workspace. It seems that the windows aren't retiled (although the window title appears in the correct spot generally).
Comment 2 Allan Day 2011-11-18 13:10:17 UTC
Confirming.
Comment 3 Vít Stanislav 2012-01-13 09:22:50 UTC
Created attachment 205170 [details] [review]
patch - just concept

This patch should rearrange windows on drag/zoom end. It's just a prove of concept, so it does repositioning of all windows on every drag end. I'm curious whether it's completely wrong, or could be usable after restricting to cases when there was window rearrangement while drag, and repositioning of the dragged window only.
Comment 4 Owen Taylor 2012-01-25 22:24:52 UTC
Review of attachment 205170 [details] [review]:

It is a corner case, so I'd be willing to accept a less-than-ideal solution, but still I don't think getting it "right" is incredibly hard:

* Instead of calling  clone.actor.set_position(x, y), clone.actor.set_scale(scale, scale), call clone.update_placement(x, y, scale);
* When inDrag update the local dragOrigX/OrigY/OrigScale and also add a DND._Draggable.updateOrigin() and call that so that snap back is correct
* Update zoomLocalOrig when zoomed
* zoomGobalOrig is the trick one - but I think it's not to hard to rewrite the logic that figures out zoomGlobalOrig not from the actor's this.actor.get_transformed_size(), this.actor.get_transformed_position(), but rather from those on the parent. Something along the lines:

  let [parentWidth, parentHeight] = parent.get_transformed_size();
  let [parentX, parentY] = parent.get_transformed_position();
  let parentScaleX = parentWidth / parent.width;
  let parentScaleY = parentHeight / parent.height;
  globalX = parentX + parentScaleX * actorX;
  globalY = parentY + parentScaleY * actorY;
  globalScaleX = parentScaleX * actorScaleX;
  globalScaleY = parentScaleY * actorScaleY;

(check and refine). Refactor things a bit so that you don't have to duplicate that code and it should work even during zoom.
Comment 5 Florian Müllner 2013-09-07 01:14:29 UTC
I can no longer reproduce this problem, so it was probably fixed by the layout rewrite in 3.8.