Primary palette redraw glitch after secondary palette exposed when rolling cursor between buttons

[garycmartin]

With the new toolbar "Share with" replacement, after the secondary palette has been exposed, then the "Keep" palette, the "Share with" primary palette text "Private" appears in the wrong part of the screen prior to the full secondary palette appearing. Here's the steps to reproduce:

1) Start either Write or Browse
2) Click lock or hover over the toolbar Activity icon
3) Hover over the "Share with" icon and wait for secondary palette
4) Hover over "Keep"
5) Hover over "Share with"

If you click locked the Activity icon, the "Private" text will have appeared in the middle of the screen. If you had hovered over the Activity icon, the "Private" text will have appeared in the secondary toolbar, centred horizontally in the screen.

[garycmartin]

OK, this is looking like another metacity issue. I've just tried the same trick with icons in the Frame and have the same results with Frame device icons, and Activity instance icons. It seems to be triggered as you roll you cursor from one button to the next AND let the secondary palettes show up.

[garycmartin]

Trivial, but is may be related to other Metacity issues.

[alsroot]

gtk-doc says
"Asks the window manager to move window to the given position. Window managers are free to ignore this; most window managers ignore requests for initial window positions (instead using a user-defined placement algorithm) and honor requests after the window has already been shown."
So, it looks like matacity ignores first move() at some point.

Gary: could you try to reproduce bug with attached patch applied
(I tried for 10min w/o success:)

[garycmartin]

Replying to alsroot:

Gary: could you try to reproduce bug with attached patch applied
(I tried for 10min w/o success:)

Patch applied and is working very well, I've not had a palette show in centre screen since the change (and much trying) :-) If you have the will, there is still one related case now that you've got this far. Pretty sure it's the same move() cause. To reproduce:

1) Goto Home favourites view (ring)
2) Hover your cursor over an Activity at the BOTTOM of the ring
3) Wait for the full palette to appear
4) Move your cursor to an adjacent Activity icon
5) Move your cursor back to first Activity icon

The first stage palette will now open in the same position as it was when the palette was fully opened (far up screen, lot's of space between first stage palette and mouse cursor). The first stage palette should appear next to the mouse cursor and then move up as palette animates.

This happens with all palettes near the bottom of the screen (device icons would be another example), but is not noticeable for palettes near the top of the screen, as their first stage palette doesn't get moved by the animation.

[alsroot]

Replying to garycmartin:

Replying to alsroot:

Gary: could you try to reproduce bug with attached patch applied
(I tried for 10min w/o success:)

Patch applied and is working very well, I've not had a palette show in centre screen since the change (and much trying) :-) If you have the will, there is still one related case now that you've got this far. Pretty sure it's the same move() cause. To reproduce:

1) Goto Home favourites view (ring)
2) Hover your cursor over an Activity at the BOTTOM of the ring
3) Wait for the full palette to appear
4) Move your cursor to an adjacent Activity icon
5) Move your cursor back to first Activity icon

The first stage palette will now open in the same position as it was when the palette was fully opened (far up screen, lot's of space between first stage palette and mouse cursor). The first stage palette should appear next to the mouse cursor and then move up as palette animates.

This happens with all palettes near the bottom of the screen (device icons would be another example), but is not noticeable for palettes near the top of the screen, as their first stage palette doesn't get moved by the animation.

thats another case, I've created #1268
in #1135 sugar calculates right positions but can't move palette,
but in #1268 sugar calculates wrong positions

[tomeu]

Looks like the best we can do here, thanks!

[alsroot]

 http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/commits/2b78463830451b3300dd8005a19789d2a4ab3000