Bug 12422

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

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.mga5
Whiteboard: 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.

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

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 step
Whiteboard: 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) => olav
Source 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)

Keywords: (none) => NEEDINFO

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.

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 => RESOLVED
Resolution: (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