Hi André
I must apologize: you are right, and /home/user/.XCompose actually
works. One thing I didn't notice until now was that together with the
upgrade to KDE 5, all Compose files on my local machine were overwritten
with their original versions — a very rude thing to do to a user who
already suffers from regular overrides of his stunnel and sshd conf …
but I won't complain, because the upgrade was an operation bordering on
giving birth to sextuplets, and maybe I made some mistakes myself. So
what I actually copied to /home/user/,XCompose was the standard X11 key
composition table. Unfortunately, I only do a very simple 2-generation
backup, so the original is long lost since then, but thanks God Emacs
made its own backup copies to Compose~, hence I lost only my most recent
change.
I'm very glad that this problem and riddle is solved now, and hopefully
other people can read the solution in the discussion on the Qt interest
group this thread is hopefully posted to.
Thanks to all
Dominik
On Mon, Oct 17, 2016 at 12:45:32PM +0200, Dominik Wezel wrote:
Hi
I had to upgrade to KDE 5 recently. One of the first things I immediately
noticed was that my key composition table was no longer working. In earlier
versions, I managed to force Qt and GTK to use XIM, which supported my huge
additions to /usr/share/X11/locale/en_US.UTF-8/Compose.
As a mere KDE user without deeper insight, I first blamed KDE for it, but
was kindly redirected to Qt as the underlying problem. When searching the
net I found some emails from 2013 written by Paeglis Gatis, where I learned
that XIM is deprecated in Qt5 and that support for key composition tables is
planned to be done directly in Qt.
However, it seemed that task https://codereview.qt-project.org/#/c/48185/ is
abandoned.
Note the abandoned reason. This was finally merged as
https://codereview.qt-project.org/#/c/51555/
Andre'
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
