Description of problem: Install from classical 64 bit DVD dated 13/8, update sources at the end and elect to install available newer packages. If there are less than 10 packages, presumably, buttons are shown at the bottom. If there are dozens, the list is broken up and the buttons appear at the end. But if (in my case) there are 14 packages, the buttons are invisible (below the edge of the screen). One can press [ enter ] to proceed, but the buttons should actually be visible. Screenshot follows (F2 screenshot from installer actually showed the next step, not this step).
Keywords: (none) => 6RC
Created attachment 8345 [details] screenshot showing buttons are missing
CC: (none) => marja11Assignee: bugsquad => thierry.vignaudSource RPM: 64 bit classical DVD dated 13/8 => drakx-installer-stage2
Source RPM: drakx-installer-stage2 => drakx-installer-stage2, urpmi
Humm, strange as: - the size is not really big - we ask for center position...
Source RPM: drakx-installer-stage2, urpmi => drakx-installer-stage2, urpmi, mutter
Valid for 6sta2 (classical 64 bit iso dated 05 DEC 2016)
Keywords: 6sta1.5 => 6sta2
corecting keyword
Valid for M6 rc (classical 64 bit iso dated 23 Mar 2017) There is no keyword for M6rc
Keywords: 6sta2 => (none)
*** Bug 20571 has been marked as a duplicate of this bug. ***
CC: (none) => mageia
Not sure how confusing this can be, but is certainly something that cannot be fixed after release, so setting to release blocker for now.
Priority: Normal => release_blockerCC: (none) => thierry.vignaudAssignee: thierry.vignaud => mageiatools
The answer is simple: the focus is on the "ok" button or similar, so pressing [ Enter ] works, except a first time user does not know that. So obviously it ought to be fixed ;)
We could try RPMProgressDialog->new() to call set_position('center_always') instead of 'center'
Source RPM: drakx-installer-stage2, urpmi, mutter => drakx-installer-stage2, urpmi , mutter
(In reply to Thierry Vignaud from comment #9) > We could try RPMProgressDialog->new() to call set_position('center_always') > instead of 'center' I don't know if it's exposed to our bindings, but there seems to be a `WindowPosition.CENTER_ON_PARENT` flag too. Could we try one of those on the next set of ISOs?
Keywords: (none) => PATCH, USABILITY
Created attachment 9184 [details] ie something like this
But that would not please gurpmi users after install. Though there should not be much, people are using rpmdrake.
Could someone test the patch in comment 11?
Status comment: (none) => Patch available, needs to be tested and applied if good
@Thierry: Would drakx-in-chroot pick the system's urpmi version? If so it should be relatively easy to test the patch by patching one's own urpmi. (https://wiki.mageia.org/en/Drakx-installer_tips_and_tricks#drakx-in-chroot)
I tested the patch locally and I don't see much impact on gurpmi usage, so I guess it's fine (the progress dialog is centered both with and without the patch).
commit 410cac6cff39dcb65371ba8cbc98f9c389a9f577 Author: Rémi Verschelde <rverschelde@...> Date: Wed Apr 26 21:06:23 2017 +0200 Enforce gurpmi ProgressDialog centering Should help with mga#19196. --- Commit Link: http://gitweb.mageia.org/software/rpm/urpmi/commit/?id=410cac6cff39dcb65371ba8cbc98f9c389a9f577
Patch pushed in urpmi-8.107-1.mga6, let's see if it improves things in the next set of ISOs. BTW Thierry, we still have a stranded patch in the SVN: http://svnweb.mageia.org/packages/cauldron/urpmi/current/SOURCES/0001-increase-transaction-size-from-8-to-50-mga-18426.patch?view=markup It would be good to commit it to git if it's meant to be kept.
It's best to use "git commit --author=...." in such cases
(In reply to Thierry Vignaud from comment #18) > It's best to use "git commit --author=...." in such cases Right, sorry. Can someone confirm that the bug is fixed in today's set of ISOs?
Status comment: Patch available, needs to be tested and applied if good => Patch applied and included in current ISOs, bugfix needs confirmation
Installed Mageia 6 rc using Mageia-6-rc-x86_64-DVD.iso and the update dialog was centered but there were only 3 package needing to be updated so I'm not certain if this bug is resolved or if it was just not triggered because there were not enough packages to trigger it. New screen shot in attachment. Will try installing again this weekend. Maybe then there will be more package updates and I'll be able to confirm if this bug is resolved or not. $ cat DATE.txt Mon May 8 00:48:36 CEST 2017 $ cat Mageia-6-rc-x86_64-DVD.iso.sha1 fd11e0581a749cb517b203d0cd6f15a919e87e54 Mageia-6-rc-x86_64-DVD.iso
Created attachment 9292 [details] new screenshot showing dialog for 3 package updates
(In reply to PC LX from comment #21) > Created attachment 9292 [details] > new screenshot showing dialog for 3 package updates Thanks. So the patch worked, but I don't think it really fixed the issue: IINM, this dialog is meant to be embedded in the main window, not floating above it.
Status comment: Patch applied and included in current ISOs, bugfix needs confirmation => Dialog floating about the window instead of being embedded
Status comment: Dialog floating about the window instead of being embedded => Dialog floating above the window instead of being embedded
Created attachment 9436 [details] screenshot with installer screen resolution set to 1024x768 Changing the default screen resolution for the installer to 1024x768, as proposed in bug 20624, improves the appearance.
Created attachment 9469 [details] Screenshot with the Mageia 5 installer (In reply to Rémi Verschelde from comment #22) > IINM, this dialog is meant to be embedded in the main window, not floating > above it. The Mageia 5 installer behaves the same way, see the screenshot. The only difference is that with Mageia 5, you see a scrollbar to view the whole list of updates, which seems to be missing in Martin's screenshot. I would suggest to close this bug as FIXED, and file a separate bug about the missing scrollbar.
The GTK theme used in the Mageia 6 installer hides the scrollbars until you move the mouse. IIRC, I was able to scroll down the list when I tested this. I agree, I think this bug can now be closed. It worked satisfactorily for me when I tested last week's ISO.
Status: NEW => RESOLVEDResolution: (none) => FIXED