| Summary: | Dead keys don't work with openoffice-ximian-1.3.9, and they worked with 1.3.8 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Santiago Gala <sgala> |
| Component: | Current packages | Assignee: | Gentoo Office Team <office> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | luisca, skandalfo |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Attachment from Novell Bugzilla | ||
|
Description
Santiago Gala
2005-04-12 08:36:40 UTC
I did: diff -ur ooo-build-1.3.* 2>&1 | less between 1.3.8 (works) and 1.3.9 (doesn't), and this struck my eye: + * Version 1.3.9 + +2005-04-04 Michael Meeks <michael.meeks@novell.com> + + * patches/OOO_1_1/vcl-im-key-plug-m79.diff: + remove stray SetIcon change. + + * patches/OOO_1_1/vcl-gtk-mainloop-m79.diff: fix + acute slowness with very short timeouts; spinning + g_main_context_iteration. It looks like it is related, at least the description makes it a reasonable candidate for completely breaking the acute accent. Can anybody who knows ooo-x internals or just gtk confirm? I'll try to build removing this patch and see if it makes a difference WRT acute handling in Spanish, but it will take looooong time. More info: xev on acute+a (notice that keypress event is " More info: xev on acute+a (notice that keypress event is "á", but keyrelease is "a", which is what ooo-ximian-1.3.9 inserts in my document:
KeyPress event, serial 29, synthetic NO, window 0x4000001,
root 0x48, subw 0x0, time 24718521, (286,188), root:(298,284),
state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES,
XLookupString gives 2 bytes: (c2 b4) "´"
XmbLookupString gives 0 bytes:
XFilterEvent returns: True
KeyRelease event, serial 29, synthetic NO, window 0x4000001,
root 0x48, subw 0x0, time 24718681, (286,188), root:(298,284),
state 0x0, keycode 48 (keysym 0xfe51, dead_acute), same_screen YES,
XLookupString gives 2 bytes: (c2 b4) "´"
KeyPress event, serial 29, synthetic NO, window 0x4000001,
root 0x48, subw 0x0, time 24719141, (286,188), root:(298,284),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: True
KeyPress event, serial 29, synthetic NO, window 0x4000001,
root 0x48, subw 0x0, time 24719141, (286,188), root:(298,284),
state 0x0, keycode 0 (keysym 0x10000e1, U00E1), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 2 bytes: (c3 a1) "á"
XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0x4000001,
root 0x48, subw 0x0, time 24719290, (286,188), root:(298,284),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
The patches between 1.3.8 and 1.3.9 make lots of changes in this area, which I don't understand: see for instance patches/vclplug/vcl-im-key-plug-m79.diff
More problem isolation: running OpenOffice.org like this: export OOO_FORCE_DESKTOP=kde xoowriter & it works and inserts accented character, though the kde ui is clumsy, because I have only small parts of kde installed here. Running it with: export OOO_FORCE_DESKTOP=none xoowriter & it works too, it behaves like "classic" openoffice.org trying with =cde brings the gtk ui and it does not work. This point further towards the patches I signaled previously. I posted it upstream: https://bugzilla.novell.com/show_bug.cgi?id=78372 Same situation with openoffice-ximian-1.3.10: xoowriter (gtk+) <- dead keys insert unaccented letters, acute+p beeps (as if the input method had recognized an illegal combination) and inserts nothing. All other applications work right. OO_FORCE_DESKTOP=none xoowriter works as expected OO_FORCE_DESKTOP=kde xoowriter works as expected This bug affects x86 arch too. Would you be so kind as to "testify" in the Novell bugzilla bug? see comment #4 As an example, I've spent a whole evening try to convince gaim developers about a crash with glib 2.6, and they only accepted the report when a "huh, GNU/Debian, hub GNU/Linux" person arrived confirming the crash. I'm getting tired of trying to push bugs just to have the reports ignored, I think I'll refrain from further effort until slow distributions (say debian, redhat, etc.) find it and confirm it. For history: it is a regression provoked by gtk backend changes between 1.3.8 and 1.3.9 ximian builds. Where I wrote OO_FORCE_DESKTOP=none, I should have written OOO_FORCE_DESKTOP=none, BTW. This workaround is good, at the expense of horrible dialogs. It also works for the "F5 navigation below presentation in slide mode" bug. Por supuesto As was said before this is not only ppc. I am running x86 (athlon-xp) and I have the exact same problem. I updated to 1.3.10 and the problem is still here, the only one without it is 1.3.6 The steps to reproduce this bug in x86 arch are the same has been described by Santiago. gentoo root # emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 28 2005, 00:17:47)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.4_p6, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LANG="es_ES@euro" LC_ALL="es_ES@euro" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X aalib alsa apm avi berkdb bitmap-fonts cdr crypt cups curl divx4linux dvd dvdr dvdread eds emboss encode esd fam flac foomaticdb fortran gd gdbm gif gnome gpm gstreamer gtk gtk2 howl imagemagick imlib ipv6 java jpeg ldap libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg ncurses nls nntp nptl nvidia ogg oggvorbis opengl oss pam pdflib perl png ppds python quicktime readline samba scanner sdl spell ssl svga tcpd tiff truetype truetype-fonts type1-fonts usb vga vorbis xine xml xml2 xmms xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, LINGUAS *** Bug 91074 has been marked as a duplicate of this bug. *** @Santiago: I can understand you frustration, the current situation is really unfortunate, my bugs are usually also ignored. To add to this, it's not even 100 percent clear, where to report bugs, as besides bugzilla.novell.com there is still bugzilla.ximian.com.... Thanks anyway for your work in this area, am going to try, again, to sort this out with the Novell people... My bug report, 91074, was marked as a duplicate of this one. This thread however seems to focus on the Ximian version of Open Office. I have the same problem in the regular and the Ximian version. Another thing just struck me. Isn't a dead-key something you press that acts as a modifier for the next key pressed? The characters that won't work for me are directly mapped to keys on my keyboard. There's no need to press anything before using them. Are you sure this is the same problem as bug 91074? I updated to 1.3.11 and the problem is still here. I am experiencing the same problem. I did not touch the Linguas setting or anything. (Just simple emerge openoffice-ximian, ACCEPT_KEYWORDS="x86" and no special optimisation.) I have this on my desktop with a Belgian keyboard and with a French keyboard lay-out on my laptop. Same problem here with 1.3.11 (binary version). The OOO_FORCE_DESKTOP=none workaround indeed works, apart from the ugly appearance :-) I updated to 1.3.14 and the problem is still here. I have this bug also, ooo-ximian-1.3.14 on a x86. This bug does not depend on having "LINGUAS" set to anything special. This bug is also a x86 bug, not just PPC. Alexandre, post in Novell Bugzilla to, please Still happens in 1.3.14, I just built it. OOO_FORCE_DESKTOP=none works around it, which makes obvious that the problem is in the gtk+ frontend I'll take a round of comments in the different upstream bugs, but given the zero responsivity we've got so far, I doubt it will be of any help. Created attachment 62234 [details] Attachment from Novell Bugzilla https://bugzilla.novell.com/show_bug.cgi?id=78372 I've tested the patch, works fine for me, so already added it to portage. Special thanks for Santiago for not giving up with upstream. Thanks a lot. Closing It works of for me too I have exactly the same problem. Nice that other people are having this as well. I had posted this on several places already but to no avail (also upstream). I don't seem to be very good at posting bug reports either, no one believes me as well ;-) : http://qa.openoffice.org/issues/show_bug.cgi?id=44841 . |
