Opera runs fine but when you try to use dead key characters such as the french:
Opera runs fine but when you try to use dead key characters such as the french: è â à ç, it doesn't work. The accent will type first not waiting for the other key. For example, as soon as type the "`" key I see the "`" character being outputted in the dialog instantly not waiting for the other key to apply the modifier on it like it should -> "`" + "e" should give "è" and not "`e". Typing in another window where dead keys works and then using cut and paste will work. Reproducible: Always Steps to Reproduce: 1. Open opera 2. Try to type a french accent in whatever dialog supports it (address bar, input type=text, file dialog, etc.) 3. Experience how it doesn't work Actual Results: The dead keys activated characters are not correct. Expected Results: It should have handled dead keys correctly thus giving me (for example) "è" instead of "`e" Problems were experienced with the ~amd64 masked ebuild of Opera 7.51. I had the problem also when I was using a hack I found on the forums to get opera 7.23 installed on a amd64 machine using opera.com bins. AMD64 system, I don't have a non amd64 system so I haven't tried to replicate on x86 hardware. My system's locales are configured to use UTF-8 where possible. From my modest understanding, I would say the problem is located somewhere in QT's 64 -> 32 bit compatibility layer since dead keys works well in my KDE environment which uses a fully 64 bit enabled locally compiled QT. .::workaround::. Type your text in another window (gedit for example), cut it and paste it into opera. .::emerge info::. Portage 2.0.50-r7 (default-amd64-2004.0, gcc-3.3.3, glibc-2.3. 2-r9, 2.6.3-gentoo-r2) ================================================================ = System uname: 2.6.3-gentoo-r2 x86_64 4 Gentoo Base System version 1.4.15 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http: //mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib alsa amd64 apm arts avi berkdb cdr crypt cups doc dvd encode esd foomaticdb gdbm gif gnome gphoto2 gpm gtk gtk2 imlib joystick jpeg kde libg++ libwww mikmod motif mozilla mpeg ncurses nls nogcj oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline ruby samba sdl slang spell ssl tcpd truetype unicode utf8 xinerama xml2 xmms xv zlib"
Sorry, Olivier. The problem is the locale setting in 32bit glibc (located in emul-linux-x86-baselibs) and I won't change this. As everyone needs it and we I can't create binary packages to suit all needs, this package cannot contain all things you want it to. We're working on a real multlib environment where you can emerge all libraries you need in 64bit and 32bit with all the customization you want, but don't expect it to be working anytime soon.
2 question: 1) I experience the same dead key problem with OpenOffice, is it for the same reason? 2) Is this because of my locale's UTF-8 character encoding setting? Would it work with ISO-8859-1?
Yeah, OOo-bin will have the same issues as Opera. It's a 32bit precompiled executable using the same emulation libraries as Opera.
