Yeah, time for THOSE bugs again - apologies that I didn't think to check this earlier in the F20 cycle :( Haven't checked any other languages yet, but at 1024x768, custom partitioning rendering is broken in Russian. I think we gave up on 800x600 but we're still doing our best to make things work at 1024x768, right?
Created attachment 833381 [details] screenshot Attaching screenshot how it does look like in F20 TC5 KDE.
Proposed as a Blocker for 20-final by Fedora user atorkhov using the blocker tracking app because: The installer must correctly display all sufficiently complete translations available for use.
I tried several languages and I encountered this bug only in Russian. Arabic, Ukrainian, Hindi, Greek (with uncomplete translation) seems to be ok.
Created attachment 833683 [details] customa partitioning rendered incorreclty @ 1024x768 KVM Guest (Spice:QLX) @ F20 Host (x86_64) 0. Boot F20-fTC5 with 'resolution=1024x768' boot parameter. 1. Select the $To_Be_Tested Language in the Welcome Screen. 2. Wait for all spokes to settle down in the Main Hub. 3. Enter SYSTEM: Installation Destination. 4. Either select a disk or just press done in case of a single disk (my case). 5. Select Custom Partitioning (default partitioning scheme) Russian: Issue: Custom Partitioning Screen is rendering incorrectly. Spanish: Ok English: Ok Italian: Ok Magyar: Ok Japanese: Ok Lithuanian: Ok Re-Tested Russian with: * 1366x768 : Same Issue * 1280x1024 : Same Issue * 1600x1200 : Ok * 1920x1080 : Ok * 1920x1200 : Ok
@Adam > I think we gave up on 800x600 I don't know, but i tested it with English and i did not find anything rendered incorrectly. (quick test, entered all spokes, even custom part). So 800x600 works ok, at lest in English. Bug 904999 Comments #11, #12. At that time, 800x600 was the minimum. I don't know current official minimum resolution.
reartes: this is a very well-known type of bug, it's simply about translated string length. The way anaconda's written, if text strings get too long, they overflow the UI and this happens. So this bug tends to happen in languages that are quite verbose compared to English. Russian and German are serial offenders. It's not a new thing we know nothing about, this happens all the time. anaconda team treats it on a 'best effort' basis, AIUI. please, no-one get into the 'why not just have scrollbars?' question here, there are apparently $REASONS :)
Why not use word-wrapping? :)
It's supposed to wrap, actually. wrap on that label is set to True, wrap-mode is PANGO_WRAP_WORD. Reassigning to Gtk.
(In reply to David Shea from comment #8) > It's supposed to wrap, actually. wrap on that label is set to True, > wrap-mode is PANGO_WRAP_WORD. Reassigning to Gtk. Does it constrain this window max size anyhow?
Created attachment 833833 [details] custom partitioning screen from install DVD In install DVD it looks a bit differently - it has background in Free/total space. And it shows part of spokes screen at first - it disappears after a click.
Created attachment 833834 [details] partition details screen Partition details screen is overflowed too.
Shouldn't be the blocker actually as interface is usable. But nice if it will be fixed. Therefore, changing to freeze exception proposition.
Discussed in 2013-12-09 Blocker Review meeting [1]. Voted an AcceptedFreezeException. Obviously cannot be fixed with an update and sucks if you're looking for an obscure partition scheme in russian with a low-res screen, but we're looking for a very safe fix. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-09/
set max-width-chars to a reasonable value
"If this property is set to -1, the width will be calculated automatically." The property is set to -1. Gtk should be able to calculate a reasonable value.
(In reply to David Shea from comment #15) > "If this property is set to -1, the width will be calculated automatically." > > The property is set to -1. Gtk should be able to calculate a reasonable > value. Where the definition of 'reasonable' is left as an exercise for the reader... I'm sorry that GTK+ far from perfect in this area. This is not an easy problem to solve. Evidently, the value that it currently calculates is not to your liking, so if you want a different outcome fro f20, you are best off setting one yourself.
*eats popcorn, swivels head from side to side*
The whole point of this is that there is no reasonable value from anaconda's point of view. We're trying render a label within a widget, and the width of that label in terms of pixels is going to depend on the content of the string within the label, the value of which we don't directly control. We can't just tell it to wrap at a preset number of characters since not all characters are the same width. We just want that label to not be wider than the notebook it's a child of. This is not an unreasonable thing to ask! I appreciate that it's difficult, but that's the whole reason we're trying to get the graphical toolkit to make the decisions here. If you're not going to do anything about this, close it as WONTFIX. Quit trying to get applications to do your job.
Created attachment 895586 [details] unwrapped label with width_in_chars=1 Besides, max-width-chars isn't doing anything. Attached a screenshot of the label not wrapping with both width-chars and max-width-chars set to 1. wrap is set to true and wrap-mode is set to PANGO_WRAP_WORD, so I should be getting a label that's one word wide.
I'm not trying to get anybody to do my job. Unloading frustration in bugzilla is not helping.
So, what does the widget hierarchy look like on that screen ? is there a .ui file I can look at ?
The problem is related to the size of a label in a different page of the GtkNotebook. It still seems pretty weird that width-chars and max-width-chars are basically being ignored, but that wasn't the solution I wanted anyway.
Also appears to affect RHEL 7: https://bugzilla.redhat.com/show_bug.cgi?id=1094489
Sorry, I meant https://bugzilla.redhat.com/show_bug.cgi?id=1098320 .