Maxime Haselbauer posted on Thu, 17 Jan 2013 22:08:42 +0100 as excerpted:
> Since a couple of days I have an issue when reading pdf from rekonq,
> using the "embeded okular": See the link below, half of the screen
> appears to belong to a rekonq toolbar or something. I have no cursor to
> pull it up. Of course I can save the pdf instead of opening it inside
> rekonq, but still it, if someone knows what to do... thks
>
> http://wstaw.org/m/2013/01/17/plasma-desktopKU2142.png
I have no direct answer but perhaps a related data point. That looks
very much like a bug I've so far only seen in gtk related apps (pan, the
news client, primarily), nothing kde. As best I've been able to figure
out, it's related to some sort of race condition whereby some resource
(like an icon or a text string) isn't loading before the GUI is drawn,
triggering a bug when the widget drawing method encounters a zero-size
resource that it's not prepared to deal with.
In my case with gtk/pan (and I'll note that a couple of other pan users
have mentioned seeing it as well), the one instance is in a multi-column
tree-view widget, where two columns normally show icons (representing the
state of the message, read, cached, saved, etc). When those icon
resources fail to load, the columns collapse to zero-width, triggering a
recalculate for the position of the rest of the columns, and instead of a
nicely rendered table layout with multiple columns, I get a single column
taking up the entire width of the widget (nearly full-screen 1920 px
width, in my case).
That in turn screws up the configured layout as pan stores it, so I get
the same problem on pan restart. I have a backup of that config file and
was able to replace the bad one, but it eventually happened again. As it
happens, I was already using a pan wrapper script launcher to setup some
other stuff before starting pan, and I eventually did a diff between the
bad config and the good one, and now invoke patch to apply that diff to
the config file if necessary, as part of the wrapper launch script. It's
a hack, but it works.
The other instance is in the pan prefs dialog. In this instance, it's
apparently a string resource, maybe an invalid UTF-8 character or some
such, triggering a mostly empty dialog several times the height of the
screen! There's a few settings at the very top, and the OK button
waaayyyyy......... dooowwwnnn ...... at the bottom, several screens worth
down.
It's the appearance of this second instance that your png called to my
mind, with all that vertical blank space. Since I've only seen the bug
in that gtk-based app, and you're seeing it in kde/rekonq, it may or may
not be a related bug, but it's certainly similar enough in appearance to
trigger the association here, so I offer it as another possible data
point.
Meanwhile, to try to address the problem... As I mentioned, in the one
instance I was able to trace the reoccurrence to a layout saved in a
config file. Have you tried it using a clean kde config, yet? Either
setup a new user without an existing config to test it with, or
(presumably operating from a text console as root, not logged in as your
normal user) temporarily rename your home dir and replace it with an
empty one for the test. Then log into kde as your normal user, and see
if the problem still occurs with that clean config. If it doesn't occur
there, then you know it's in your config somewhere, and all you have to
do is isolate the problem and correct it. If it does, then it's probably
a distro or upstream kde issue, and much harder for you to deal with
except by doing the save thing to work around it, until it's fixed.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
