--nextPart7268148.YKPvUoB7vD
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi!

Not sure, if this discussion is taking place somewhere else already, but I=
=20
can't find any place.

I came across this bug by coincidence, when I was looking for the release d=
ate=20
of 3.5.6. Out of curiosity, I went to look at what Lubos was doing to fix=20
this, and found out, I have a share in this bug, but suggesting the=20
correction to QXEmbed, that now seems to be breaking workarounds in several=
=20
apps (according to the comment for r626522).

I don't know, whether the issue is resolved, yet. If not, here's a dirty=20
suggestion to avoid a long hold-up: Revert r609135 for now (but add a comme=
nt=20
in the sources), and deal with the issue after 3.5.6.

It seems, I have been the first to notice this bug in years, so it is proba=
bly=20
safe to assume, no other app besides RKWard is currently hit by the bug fix=
ed=20
with r609135. RKWard itself is released outside of KDE's release schedule,=
=20
and hence the only practical solution for us is to include our own correcte=
d=20
copy of QXEmbed in our sources anyway (and we're already doing this).=20
Therefore RKWard will *not* be negatively affected by reverting r609135.=20
Chances are, no other application will be either (unless they already dropp=
ed=20
their workarounds). Hence reverting may do more good than harm in the short=
=20
term.

Well, it's just a suggestion in case all other options would continue to ca=
use=20
delays.

Regards
Thomas

--nextPart7268148.YKPvUoB7vD
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBFtz+0EKRv+5DVNhgRAl6zAJ0XkzcULkqB/gsb64XSplchqLeNNACfUYEG
SswBaSMKbBD7X0SV34RceGU=
=zYHl
-----END PGP SIGNATURE-----

--nextPart7268148.YKPvUoB7vD--