Description of problem: Round 1 final prerelease classical iso (64 bit used, but I assume either arch applies): Similar (I think) to diskdrake detaching from the main installer window as in https://bugs.mageia.org/show_bug.cgi?id=11988 (fixed), the Desktop selection window gets detached from the main window and can be moved around the screen. Afterwards the guis that follow are also detached from the installer and may be moved. Screenshots to be attached. Reproducible: Steps to Reproduce:
Created attachment 4828 [details] desktop selection window
Created attachment 4829 [details] custom package selectio window that follows
Whiteboard: (none) => 4finalBlocks: (none) => 11704
@tv: I don't really mind the detaching window, but others at #mageia-qa would prefer to not have it.
CC: (none) => thierry.vignaud
I should say: the window gets detached after a few clicks on the various options / images shown on screen (not immediately when one comes here).
Note that you can move it back by pressing Alt + using the mouse
CC: (none) => olavSource RPM: (none) => gtk+3.0
Are you sure you didn't just moved the window?
@tc re #c6: No, why should I want to do that? Click (for example) on the thumbnail of 'custom' desktop, and the gui will move by itself spontaneously at the same moment.
That should have read: @tv. My apologies!
Olave, I've traced the installer through both: - the attached patch that basically makes perl-Gtk3 reports each gtk_window_move() call - rebuilding drakx-in-installer with %debug set as 1 then I've run it from gdb with a breakpoint on gtk_window_move There's no call to gtk_window_move() to strange position. However, when booting my test VM with a lonely partition on half the disk, when I delete it, the window jumps to the left (see bug #11790, #11988 & #11977) when its contents slighly enlarge it. We catch the size-allocate event and we move it back to its center place. Now at partitioning time, it no more jumps, it just flickers but it still happens later. When partitioning, when it flickers, there's only one gtk_window_move() happening, the one that results in the window to move back to its right position. If I disable it, the fact that gtk+ make it jumps makes the installer quite less usable. Can you look at this gtk+ issue? There's been similar reports (See https://www.google.com/search?q=gtk3+window+jump)
Assignee: bugsquad => olav
Created attachment 4837 [details] trace all gtk_window_move() calls
URL: (none) => https://www.google.com/search?q=gtk+window+jump
Asked upstream, no real thoughts. I'm wondering if this is something matchbox isn't handling. E.g. maybe fallout from https://mail.gnome.org/archives/commits-list/2013-October/msg03528.html
Blocks: (none) => 14069
Essentially still present; though it can now happen earlier.
Whiteboard: 4final => 5beta1
Still happens for me at the disk partitioning stage, as per bug 11988 (not really fixed). The window grows to the full display width.
CC: (none) => mageia
Priority: Normal => release_blocker
Dup *** This bug has been marked as a duplicate of bug 12422 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE