The installer looks fine in a VMWare VM, but when run on a physical machine with widescreen monitors (1920x1080 native resolution) once it gets to the partitioning stage, the installer pops up into a floating window which is flush with the left side of the screen, and covers the blue column that should be on the left showing the list of steps. Reproducible: Steps to Reproduce:
Note that the installer isn't actually running at 1920x1080, it looks like a much smaller 4:3 resolution being stretched to fit the screen. I would take a screenshot, but F2 creates /mnt/root/DrakX-screenshots, but does not populate it with any files.
Created attachment 4867 [details] Screenshot of installer OK, it's 800x600 and F2 does work during the Summary step. Screenshot attached.
Just in case it matters, it was while installing packages that the F2 didn't work.
David told me that it was during the installation of packages that screenshotting didn't work. I hadn't done that for a while, it doesn't work with the 32bits DVD from the 2nd round of final isos, either (drakx-installer-stage2-16.26.5) AFAIK it works everywhere else, with both 16.26.5 and 16.26.6
CC: (none) => marja11
when we're chrooted during a transaction, fb2png isn't available thus taking a screenshot fails. One solution would be to like for displaying release notes: - set a boolean - wait for transaction to end - then take the screenshot Another would be split backend (installation using urpm modules) & frontend (GUI), quite a bigger job... As for the original issue, can you attach the /root/drakx/report.bug.xz file of the affected machine?
Keywords: (none) => NEEDINFO
(In reply to Thierry Vignaud from comment #5) > when we're chrooted during a transaction, fb2png isn't available thus > taking a screenshot fails. > > One solution would be to like for displaying release notes: > - set a boolean > - wait for transaction to end > - then take the screenshot > > Another would be split backend (installation using urpm modules) & > frontend (GUI), quite a bigger job... > Thanks for the explanation, Thierry. It is nice to have, but isn't worth a lot of work, so I'm fine with the first solution
Created attachment 4885 [details] report.bug.xz
I have reported this endlessly on the PAD for ages [32-bit Classic installs], without knowing that this bug existed (there is another not disimilar). It is bad for "image" but does not impede the installation. I think it should be fixed for M4 release, but OTOH should not delay that if it cannot be done.
CC: (none) => lewyssmith
*** Bug 13871 has been marked as a duplicate of this bug. ***
CC: (none) => dvgevers
Hardware: i586 => AllKeywords: NEEDINFO => (none)Source RPM: drakx-installer-stage2-16.26.6-2.mga4.src.rpm => drakx-installer-stage2Whiteboard: (none) => 5alpha2
Source RPM: drakx-installer-stage2 => drakx-installer-stage2-2.16.38-1.mga5
Shouldn't this bug be split? The fb2png issue is different from what this bug is about. FWIW, during testing of m5a2 install from dualarch dvd and also in virtualbox, once you open details during package installation stage, and moving the handle on the scrollbar around, one can drag the whole window around the screen.
CC: (none) => doktor5000
As before in 5b1 first build of today (64 bits )
Source RPM: drakx-installer-stage2-2.16.38-1.mga5 => drakx-installer-stage2-2.16.44-1.mga5Whiteboard: 5alpha2 => 5beta1
Applies to 5beta2 build 1
Whiteboard: 5beta1 => 5beta2
applies to Mageia-5-beta2-x86_64-DVD, Sun Dec 21 18:53:19 CET 2014
CC: (none) => westel
In vbox it looks to come back too, it was less critical as you could move the windows and not all step where on the left, but now it is
Priority: Normal => release_blocker
Thierry, do you see anything relevant in attachment 4885 [details], or would you need a more recent report.bug.xz from Mageia 5 beta 3?
CC: (none) => remi
On a 32bits laptop, with an ancient sized (higher and less wide) screen and where this issue did not exist in Mageia 4, I now have it, too (from the partitioning step onwards). It is the system I use to grab screenshots for the manual for traditional installer. The foreground screen covers the left panel completely. However, even if it would be possible to move it to the right, it would still cover part of the left panel: the foreground screen is larger than it used to be.
btw, this is with boot.iso and the newest stage2: the image size of the left panel's background is correct.
Testing the dual arch ISO for 5beta3, round 3 (2015-02-09) in a 32bit VM (Vbox) and I don't see this bug anymore. To confirm with other ISOs.
It does still happe with all isos if you enter advanced partitioning only. Using simple one does not have any effect
CC: (none) => ennael1
> It does still happe with all isos if you enter advanced partitioning only. Using simple one does not have any effect Indeed, I can confirm this with the dual arch ISO. I'll see if I can locate the code that spawns the advanced partitioning window then.
Summary: installer runs in floating window covering the left column => installer runs in floating window covering the left column after the advanced partitioning step
Created attachment 5897 [details] windowonleft.png Confirming Annes findings in comment 19. Adding a screenshot. The window stays there during the rest of the install and can't be dragged back to it's normal position.
CC: (none) => eeeemail
Disclaimer: I don't understand perl nor Gtk, so I might be completely wrong in what follows, but I've tried to narrow down the code that spawns diskdrake to see if it uses some wrong arguments. The custom partitioning (a.k.a. diskdrake) is referred to here: http://gitweb.mageia.org/software/drakx/tree/perl-install/fs/partitioning_wizard.pm#n258 Which refers to this subroutine: http://gitweb.mageia.org/software/drakx/tree/perl-install/fs/partitioning_wizard.pm#n53 which spawns diskdrake::interactive::main, i.e.: http://gitweb.mageia.org/software/drakx/tree/perl-install/diskdrake/interactive.pm#n198 And then this one spawns the Gtk window I suppose: http://gitweb.mageia.org/software/drakx/tree/perl-install/diskdrake/interactive.pm#n203 i.e.: http://gitweb.mageia.org/software/drakx/tree/perl-install/diskdrake/hd_gtk.pm#n54 Hope this helps whomever understands that stuff :-)
Some more browsing through the code: The custom partitioning windows is spawned with [1]: $w = ugtk3->new(N("Partitioning")); The corresponding subroutine is here [2]. I wonder if it's not missing an optional argument to initialise it on top of the main window. [1] http://gitweb.mageia.org/software/drakx/tree/perl-install/diskdrake/hd_gtk.pm#n61 [2] http://gitweb.mageia.org/software/drakx/tree/perl-install/ugtk3.pm#n823
Summary: installer runs in floating window covering the left column after the advanced partitioning step => M5B2 installer runs in floating window covering the left column after the advanced partitioning step
This is also valid for M5B3 Ben :)
Summary: M5B2 installer runs in floating window covering the left column after the advanced partitioning step => installer runs in floating window covering the left column after the advanced partitioning stepWhiteboard: 5beta2 => 5beta3
(In reply to Rémi Verschelde from comment #23) That's not the issue. Actually we reuse the same main window. See ugtk3/mygtk3. The issue is that sometimes gtk+3 resizes the dialog b/c of its contents instead of either clipping or displaying a scrolled bar (in the cases where we use a scrolled window) When that happens, either gtk+ or matchbox make the window to jump I think it's gtk+3 as: 1) it never happened with gtk+2 (famous last words) 2) it happens with either matchbox or mutter 3) I'd checked it by patching gtk+ for traces on resize and it happened when content didn't fit anymore When it happened previously for mga4, I tried to make the partition buttons sizing code to be more robust in order to prevent it to. For partition buttons, we can try either tp fix again the sizing (rosa is now using a different logic, I can look at that) or put the blue/red buttons in a scrolled window ('never' vertically & 'automatic' horizontally).
CC: (none) => olavSource RPM: drakx-installer-stage2-2.16.44-1.mga5 => drakx-installer-stage2-2.16.44-1.mga5, gtk+3.0
commit 32a9e3c6366361c1c6e6fce1594e2fc01da299ba Author: unknown <ex.thierry.vignaud@...> Date: Thu Feb 12 15:38:30 2015 +0100 switch to logarithm sizing of partition buttons instead of using a ratio to the total disk size in order to compute width share, we now use the log of the partition size to the smallest one. this reduce the risk of having too small buttons, fixes several issues in the installer: - buttons being too big causing their box & thus the dialog to increase which triggers a gtk+ bug which makes the window to jump (mga#12422) - as well as several other related issues (mga#11988, mga#14839, mga#15272) (from Rosa but simplified) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=32a9e3c6366361c1c6e6fce1594e2fc01da299ba Bug links: Mageia https://bugs.mageia.org/14839 https://bugs.mageia.org/15272 https://bugs.mageia.org/12422 https://bugs.mageia.org/11988
Tested today with a test iso using last stage2. Unfortunately, issue is not fixed. Adding screenshot
Created attachment 5930 [details] Advanced partitioning screen (iso with up to date stage2 18/02)
commit 1d57ba59bedf6fae41301720e71839eb91db3cce Author: Thierry Vignaud <thierry.vignaud@...> Date: Thu Feb 19 09:41:04 2015 +0100 use an horizontal scrolling bar when needed gtk+ sometimes doesn't respect our sizing which causes the container to enlarge (see previous commit) with previous commit, this reduce the risk of having too small buttons, and fixes several issues in the installer: - buttons being too big causing their box & thus the dialog to increase which triggers a gtk+ bug which makes the window to jump (mga#12422) - as well as several other related issues (mga#11988, mga#14839, mga#15272, mga#15264) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=1d57ba59bedf6fae41301720e71839eb91db3cce Bug links: Mageia https://bugs.mageia.org/14839 https://bugs.mageia.org/15272 https://bugs.mageia.org/12422 https://bugs.mageia.org/15264 https://bugs.mageia.org/11988
You can try Cauldron once your favorite mirror has this morning's installer (16.62). Check install/stage2/VERSION eg: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/stage2/VERSION (not yet up to date)
Potentially fixing five bugs with one commit, I like that :-) I'll test asap.
Tested here with a test iso. Unfortunatelly still floating window on advanced partitionning :/
really with 16.62? can you attach a screenshot?
Same here, see https://bugs.mageia.org/attachment.cgi?id=5931
I was testing with distrib-coffee's boot.iso from ~20 min ago, I'll retry in a little while to make sure that it's not just a syncing issue.
distrib-coffee is still at 16.61... not 16.62 yet...
See comment #30
Tested from rabbit, the build server for isos: cat /home/bcd/build_bcd/build/Mageia-5-beta3-dual-DVD/i586/install/stage2/VERSION 16.62
(In reply to Thierry Vignaud from comment #36) > distrib-coffee is still at 16.61... not 16.62 yet... Well it says 16.62 for me after reloading the page (caching issue).
what does it says when you go on alt+ctrl+f2 for me it says 16.61...
Confirmed here, 16.62
Humm, gtk+3.0 has still enlarged the window by nearly 50px and then moved it... Whereas the scrolled window is not put in action (unlike in standalone mode).
Summary: installer runs in floating window covering the left column after the advanced partitioning step => installer runs in floating window covering the left column after the advanced partitioning step (gtk+ enlarging then moving the window)
Olav why gtk+3.0 behavior differs when there's not a full window manager? Even fixing the scrolled window width doesn't prevent gtk+ to resize it and then to move the window
Not a developer, not a GTK+ developer. Could you give me the most simple demo? I can have actual developers look at it.
CC: (none) => anaselli
CC: lewyssmith => (none)
Tv can we reuse window position as it was correct before moving? As a workaround for now as it seems it will be hard to fix it for final release ?
valid first round dual Mga5rc, both platforms DrakX v16.62
Whiteboard: 5beta3 => 5rc
commit a674dfbf7d84330dca4f3bf58f61f4ef35fd15fc Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Feb 27 20:02:20 2015 +0100 fix too wide buttons closing mga#12422, mga#13471, mga#14839, mga#15379 issue introduced in commit 1d4957dddcbf98c3a985186b8b61be2b3f004b3c but was showing only in some cases --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=a674dfbf7d84330dca4f3bf58f61f4ef35fd15fc Bug links: Mageia https://bugs.mageia.org/12422 https://bugs.mageia.org/13471 https://bugs.mageia.org/14839 https://bugs.mageia.org/15379
*** Bug 14839 has been marked as a duplicate of this bug. ***
*** Bug 13471 has been marked as a duplicate of this bug. ***
CC: (none) => gerard.haxaire
*** Bug 15379 has been marked as a duplicate of this bug. ***
CC: (none) => zen25000
Closing
Status: NEW => RESOLVEDResolution: (none) => FIXED
*** Bug 12369 has been marked as a duplicate of this bug. ***
commit 77cd051688f1e8aae47aed0c8ac40ea45360461a Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Feb 27 20:02:20 2015 +0100 fix too wide buttons closing mga#12422, mga#13471, mga#14839, mga#15379 issue introduced in commit 1d4957dddcbf98c3a985186b8b61be2b3f004b3c but was showing only in some cases --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=77cd051688f1e8aae47aed0c8ac40ea45360461a Bug links: Mageia https://bugs.mageia.org/12422 https://bugs.mageia.org/13471 https://bugs.mageia.org/14839 https://bugs.mageia.org/15379