Version: (using Devel) OS: Linux Installed from: Compiled sources See screenshot https://qa.mandriva.com/attachment.cgi?id=11692 (Mandriva bug https://qa.mandriva.com/show_bug.cgi?id=46070). In the middle of the message text is truncated and this makes the message absolutely meaningless. BTW I have strong feeling that KDE computes not the display width but raw length of messages in bytes. Which for UTF-8 makes them twice as long.
That would be a general kdelibs bug, reassigning to kdelibs.
*** Bug 179649 has been marked as a duplicate of this bug. ***
This attachment is another example: http://bugs.kde.org/attachment.cgi?id=29908
*** Bug 180463 has been marked as a duplicate of this bug. ***
*** Bug 183300 has been marked as a duplicate of this bug. ***
*** Bug 183851 has been marked as a duplicate of this bug. ***
For reference, here's how andreas pakulat described the problem on the mailing lists: Well, unfortunately Qt cannot do proper word-wrapping, especially when url's are involved. If the url is "long enough" you'll get a message box thats larger then the screen. Thats why at some point KMessageBox had a scrollbar, but it seems that was removed now in favor of elided text. I agree that this solution is not really acceptable and suggest you discuss this on kde-core-devel.
On bug #128090 i attached a fix for this problem which makes the maximum dialog size expand up to 80% of screen width, with word-wrapping enabled at >50% of screen width. For me that has fixed both problems fine.
Created attachment 32215 [details] patch for kmessagebox to make them expand up to 80% (instead of 50%) (actually the patch belongs here not in that other bug)
label->minimumWidth() should be used instead of the sizeHint, at least at the second pass. (And you might want to set the width manually on the messagebox in case it is too big)
Created attachment 32961 [details] A popup dialog totally unusable Unfortunately, I've lost the ability to resize the VirtualBox X server, so it uses 640x480. There, the dialog is not placed at the center of the screen, and it cuts the text and the buttons text.
Should a ScrollArea be used to avoid cases like the last one ?
Jaime can you please try this with my patch? Else, if noone has any objections, i'll just commit this as i am using it since months without problems..
(In reply to comment #12) > Should a ScrollArea be used to avoid cases like the last one ? Thats what I did for KDE4.0, but apparently too many people didn't like it, so it was reverted and now we again have the joy of being unable to see the important parts of message boxes.
May be it should be only used on "extreme" cases like the last one. Or setup a layout properly to avoid the dialog being resized too much (when space on screen is available to use)
(In reply to comment #14) > (In reply to comment #12) > > Should a ScrollArea be used to avoid cases like the last one ? > > Thats what I did for KDE4.0, but apparently too many people didn't like it, so > it was reverted and now we again have the joy of being unable to see the > important parts of message boxes. I think the problem in 4.0 is that the scroll was used too often, even when the dialog clearly had space to show the entire message without scrolling, it didn't expand properly and instead showed the scrollbar. I think the solution should be to try to show the message without scrolling (and of course, no ellipsing) while keeping the dialog at a reasonable size (e.g. no 640x480 dialog on a 640x480 screen), and if that isn't enough to display the message, then switch to having a scrollable message.
From what I see in the code, we allow large sizes of the message text label, but only enable scroll bars when the height of the text would not fit. The eliding of long lines still is implemented, so something like that on the first screen shot is still possible. I would suggest to use QTextOption::WrapAtWordBoundaryOrAnywhere which can hard-break URLs etc. even at non word boundaries, but we have to use a custom widget instead of QLabel.
Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann