Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Segmentation fault on running wish(Tk)

74 views
Skip to first unread message

hongk...@yahoo.com.hk

unread,
Jan 11, 2009, 5:55:02 AM1/11/09
to
compiling tk8.5.6 on fedora 7, compilation completed without error,
'wish' generated and when execute,fail with a message 'segmentation
fault', even the latest binary version from activetcl got the '
segmentation fault', tcl8.5.6 is ok. can anyone help? Thanks
screen from debug is as follows :
[root@localhost]# gdb wish8.5
GNU gdb Red Hat Linux (6.6-16.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.
...
This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /usr/local/bin/wish8.5
%
Program received signal SIGSEGV, Segmentation fault.
0x06ce9a5f in XGetICValues () from /usr/lib/libX11.so.6
(gdb)

Alexandre Ferrieux

unread,
Jan 11, 2009, 10:10:16 AM1/11/09
to

Going into gdb and *not* typing 'bt' or 'where' is... frustrating :-)

-Alex

hongk...@yahoo.com.hk

unread,
Jan 11, 2009, 10:29:30 AM1/11/09
to
On 1月11日, 下午11時10分, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:

with bt result as follows:


[root@localhost]# gdb wish8.5
GNU gdb Red Hat Linux (6.6-16.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.


This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /usr/local/bin/wish8.5
%
Program received signal SIGSEGV, Segmentation fault.
0x06ce9a5f in XGetICValues () from /usr/lib/libX11.so.6

(gdb) bt
#0 0x06ce9a5f in XGetICValues () from /usr/lib/libX11.so.6
#1 0x0013be1b in CreateXIC (winPtr=0x9009de8)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:365
#2 0x0013bee1 in InvokeInputMethods (winPtr=0x9009de8,
eventPtr=0x90ba0c0)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:408
#3 0x0013cba5 in Tk_HandleEvent (eventPtr=0x90ba0c0)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:1344
#4 0x0013d32f in WindowEventProc (evPtr=0x90ba0b8, flags=-3)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:1804
#5 0x00319cf4 in Tcl_ServiceEvent (flags=-3)
at /home/download/tcl8.5.6/unix/../generic/tclNotify.c:675
#6 0x0031a0fe in Tcl_DoOneEvent (flags=-3)
at /home/download/tcl8.5.6/unix/../generic/tclNotify.c:978
#7 0x0013d778 in Tk_MainLoop ()
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:2133
#8 0x0014f2a0 in Tk_MainEx (argc=-1, argv=0xbfb7b188,
appInitProc=0x8048798 <Tcl_AppInit>, interp=0x8fe2eb8)
at /home/download/tk8.5.6/unix/../generic/tkMain.c:321
#9 0x08048788 in main (argc=1, argv=0xbfb7b184)
at /home/download/tk8.5.6/unix/../unix/tkAppInit.c:68

Donal K. Fellows

unread,
Jan 11, 2009, 12:21:48 PM1/11/09
to
> Going into gdb and *not* typing 'bt' or 'where' is... frustrating :-)

It's in the input methods stuff, which is one of the worst documented
parts of X11. Part of that is probably because those of us who use
phonetic languages don't use input methods, and part of that is that
there are huge numbers of assumptions involved, and I think they're made
by people who only check against a very limited set of toolkits...

Donal.

Alexandre Ferrieux

unread,
Jan 11, 2009, 1:16:00 PM1/11/09
to

Thanks. Next interesting thing would be to climb to frame 1 (in
CreateXIC) and look at the arguments passed to XGetICValues (wouldn't
be surprised to see that the first arg, the input context, is NULL or
some 0xDEADBEEF). While you're at it, also please print all fields of
*winPtr in that same frame.(and please try to replicate with 8.6/
HEAD).

Donal, Joe: looking at that code I see that the winPtr->inputContext
just returned by XCreateIC() is not even checked against NULL. Is it
safe ?


-Alex


(line numbers and code taken from HEAD, hence 8.6 branch)

345 : winPtr->inputContext = XCreateIC(dispPtr->inputMethod,
346 : XNInputStyle, dispPtr->inputStyle,
347 : XNClientWindow, winPtr->window,
348 : XNFocusWindow, winPtr->window,
349 : preedit_attname, preedit_attlist,
350 : NULL);
351 : dkf 1.29
352 : jenglish 1.35 if (preedit_attlist) {
353 : XFree(preedit_attlist);
354 : }
355 : dkf 1.29
356 : jenglish 1.35 /*
357 : * Adjust the window's event mask if the IM requires it.
358 : */
359 : XGetICValues(winPtr->inputContext, XNFilterEvents,
&im_event_mask, NULL);

George Peter Staplin

unread,
Jan 11, 2009, 1:22:50 PM1/11/09
to
hongk...@yahoo.com.hk wrote:

It appears to me that nothing is unusual about the state of things when the
segv occurs. WindowEventProc is being called with TCL_ALL_EVENTS. There
isn't enough state visible to determine what is wrong.

Please also provide: bt full 4

That should provide a lot more useful output.

It would also help us further I suspect (if the bt full 4 doesn't provide
enough information) to have the output for frames 0 and 1. You can get
that information by using a debug version of libX11.so. Debian and some
other GNU/Linux distributions provide a debug libX11 package.

Thanks,

George

George Peter Staplin

unread,
Jan 11, 2009, 1:41:06 PM1/11/09
to
Alexandre Ferrieux wrote:


I think right here it makes sense to add:
if (winPtr->inputContext == NULL) {
return;
}

> 356 : jenglish 1.35 /*
> 357 : * Adjust the window's event mask if the IM requires it.
> 358 : */
> 359 : XGetICValues(winPtr->inputContext, XNFilterEvents,
> &im_event_mask, NULL);

InvokeInputMethods() (which I put together years ago IIRC when refactoring
the tkEvent.c code) is designed to test for the winPtr->inputContext not
existing. It appears though that CreateXIC is wrong.

Side note: I want to move this XIC code into: tk/unix/tkUnixXIC.c. From
what I see it has little reason to be in generic/tkEvent.c, other than to
provide a bit more encapsulation, because CreateXIC is static. We could
name it something more specific with a Tk prefix, and it would work fine.


George

George Peter Staplin

unread,
Jan 11, 2009, 2:46:52 PM1/11/09
to
George Peter Staplin wrote:

I committed the change to the core-8-5-branch and HEAD. If the original
poster could test with the following sources it would help us confirm that
this fixes the problem:

Use an empty password with this:
cvs -d:pserver:anon...@tktoolkit.cvs.sourceforge.net:/cvsroot/tktoolkit
login

cvs -z3 -d:pserver:anon...@tktoolkit.cvs.sourceforge.net:/cvsroot/tktoolkit
co -r core-8-5-branch -P tk

Thanks,

George

Donal K. Fellows

unread,
Jan 11, 2009, 3:53:29 PM1/11/09
to
George Peter Staplin wrote:
> Side note: I want to move this XIC code into: tk/unix/tkUnixXIC.c. From
> what I see it has little reason to be in generic/tkEvent.c, other than to
> provide a bit more encapsulation, because CreateXIC is static. We could
> name it something more specific with a Tk prefix, and it would work fine.

Sounds reasonable to me. Your understanding of that part of the code is
better than mine, but I've split things for analogous reasons in the past.

Donal.

KOON

unread,
Jan 12, 2009, 9:01:47 AM1/12/09
to
> cvs -d:pserver:anonym...@tktoolkit.cvs.sourceforge.net:/cvsroot/tktoolkit
> login
>
> cvs -z3 -d:pserver:anonym...@tktoolkit.cvs.sourceforge.net:/cvsroot/tktoolkit

> co -r core-8-5-branch -P tk
>
> Thanks,
>
> George

cvs tried, Tk seems ok but no chinese input except by copy and paste,
any further solution?
anyway thanks a lot

Alexandre Ferrieux

unread,
Jan 12, 2009, 1:40:31 PM1/12/09
to

Well, George's was an emergency action: just avoid the segfault when
XCreateIC fails. But of course this doesn't help proceeding along what
XCreateIC was about to do ! So the next thing would be to analyze
XCreateIC's parameters (hence my request to look at all those fields),
and understand whar in the system environment makes it fail, and how
to circumvent that without removing the whole arm.

-Alex

George Peter Staplin

unread,
Jan 12, 2009, 1:47:16 PM1/12/09
to
KOON wrote:

What is the output of /usr/bin/locale on your system? How are you trying to
enter the Chinese input? What toolkits do work (Gtk? Qt?)? Are you using
an input method, such as SCIM?

If you could provide the code you're using with whatever widgets, and the
sequences needed to reproduce the problem we will be able to help further.

George

Alexandre Ferrieux

unread,
Jan 12, 2009, 3:28:32 PM1/12/09
to
On Jan 12, 7:47 pm, George Peter Staplin <georg...@xmission.com>
wrote:
>

> If you could provide the code you're using with whatever widgets, and the
> sequences needed to reproduce the problem we will be able to help further.

George, he is just spawning vanilla wish, and that is crashing before
the prompt (see gdb "run" command). So no user code nor extension, nor
any widget apart from the "." toplevel and the console.

I think the relevant info is in the parameters passed to XCreateIC and/
or his environment.

-Alex


George Peter Staplin

unread,
Jan 13, 2009, 1:46:26 AM1/13/09
to
Alexandre Ferrieux wrote:

OK. Sorry, I've been busy, and I forgot the original post. :)

My guess at this point is that OpenIM() in tkUnixEvent.c doesn't handle
enough styles.

George

KOON

unread,
Jan 13, 2009, 11:45:54 AM1/13/09
to

the gdb output as follows:


Starting program: /usr/local/bin/wish8.5
%
Program received signal SIGSEGV, Segmentation fault.

XGetICValues (ic=0x0) at ICWrap.c:292
292 if (!ic->core.im)
(gdb) bt
#0 XGetICValues (ic=0x0) at ICWrap.c:292
#1 0x0013be1b in CreateXIC (winPtr=0x9f10df0)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:365
#2 0x0013bee1 in InvokeInputMethods (winPtr=0x9f10df0,
eventPtr=0x9fc3008)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:408
#3 0x0013cba5 in Tk_HandleEvent (eventPtr=0x9fc3008)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:1344
#4 0x0013d32f in WindowEventProc (evPtr=0x9fc3000, flags=-3)


at /home/download/tk8.5.6/unix/../generic/tkEvent.c:1804
#5 0x00319cf4 in Tcl_ServiceEvent (flags=-3)
at /home/download/tcl8.5.6/unix/../generic/tclNotify.c:675
#6 0x0031a0fe in Tcl_DoOneEvent (flags=-3)
at /home/download/tcl8.5.6/unix/../generic/tclNotify.c:978
#7 0x0013d778 in Tk_MainLoop ()
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:2133

#8 0x0014f2a0 in Tk_MainEx (argc=-1, argv=0xbf81ff88,
appInitProc=0x8048798 <Tcl_AppInit>, interp=0x9ee9eb8)
at /home/download/tk8.5.6/unix/../generic/tkMain.c:321
#9 0x08048788 in main (argc=1, argv=0xbf81ff84)
at /home/download/tk8.5.6/unix/../unix/tkAppInit.c:68
(gdb) bt full 4
#0 XGetICValues (ic=0x0) at ICWrap.c:292
var = <value optimized out>
total_count = 10859200
args = (XIMArg *) 0xbf81fb28
ret = 0x0
#1 0x0013be1b in CreateXIC (winPtr=0x9f10df0)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:365
dispPtr = (TkDisplay *) 0x9efdb80
im_event_mask = 0
preedit_attname = 0x230790 "preeditAttributes"
preedit_attlist = (XVaNestedList) 0x9f1a550
#2 0x0013bee1 in InvokeInputMethods (winPtr=0x9f10df0,
eventPtr=0x9fc3008)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:408
dispPtr = (TkDisplay *) 0x9efdb80
#3 0x0013cba5 in Tk_HandleEvent (eventPtr=0x9fc3008)
at /home/download/tk8.5.6/unix/../generic/tkEvent.c:1344
handlerPtr = (TkEventHandler *) 0x1
winPtr = (TkWindow *) 0x9f10df0
mask = 4194304
ip = {eventPtr = 0x111000, winPtr = 0x138414, nextHandler =
0x11449c,
nextPtr = 0x2492f0}
interp = (Tcl_Interp *) 0x0
tsdPtr = (ThreadSpecificData *) 0x9f0f428
(More stack frames follow...)
(gdb)

Joe English

unread,
Jan 13, 2009, 1:54:50 PM1/13/09
to
KOON wrote:
>
> cvs tried, Tk seems ok but no chinese input except by copy and paste,
> any further solution?

Next step is to figure out why XCreateIC() is failing in the
first place. Try compiling and running this program:

<URL: http://www.flightlab.com/~joe/repos/ximinfo/ximinfo.c >

it may provide more clues. If you could provide any other
relevant information such as:

+ What input method platform is in use (SCIM, UIM, ...)
+ Which input methods you have selected (pinyin, wubi, canna, ...)
+ Any locale settings (LANG, LC_* environment variables...)
+ Operating system version and distributor;
+ What desktop environment you're running (including version);
+ Does chinese input work for other, non-Tk application?
+ Value of GTK_IM_MODULE and/or QT_IM_MODULE environment variables,
if set...

it would also be helpful.

But I must warn in advance: I've seen a pretty low success rate
when it comes to diagnosing and fixing IM-related problems.
Very few people in the Tk community understand how all this
stuff is supposed to work.


--Joe English

KOON

unread,
Jan 13, 2009, 9:01:14 PM1/13/09
to

output from ximinfo as follows:
./ximinfo: locale=zh_HK.UTF-8
./ximinfo: codeset=UTF-8
./ximinfo: XSupportsLocale => True
./ximinfo: XServerVendor => The X.Org Foundation
./ximinfo: XSetLocaleModifiers => @im=SCIM
./ximinfo: supported style XIMPreeditPosition|XIMStatusNothing
./ximinfo: supported style XIMPreeditCallbacks|XIMStatusNothing
./ximinfo: supported style XIMPreeditNothing|XIMStatusNothing
./ximinfo: supported style XIMPreeditPosition|XIMStatusCallbacks
./ximinfo: supported style XIMPreeditCallbacks|XIMStatusCallbacks
./ximinfo: supported style XIMPreeditNothing|XIMStatusCallbacks
environment variables as follows:
declare -x COLORTERM="gnome-terminal"
declare -x CVS_RSH="ssh"
declare -x declare -x DESKTOP_SESSION="default"
declare -x DISPLAY=":0.0"
declare -x GDMSESSION="default"
declare -x GDM_XSERVER_LOCATION="local"
declare -x GNOME_DESKTOP_SESSION_ID="Default"
declare -x GNOME_KEYRING_SOCKET="/tmp/keyring-aVroSO/socket"
declare -x GTK_IM_MODULE="scim-bridge"
declare -x GTK_RC_FILES="/etc/gtk/gtkrc:/root/.gtkrc-1.2-gnome2"
declare -x G_BROKEN_FILENAMES="1"
declare -x HISTSIZE="1000"
declare -x HOME="/root"
declare -x HOSTNAME="localhost"
declare -x INPUTRC="/etc/inputrc"
declare -x LANG="zh_HK.UTF-8"
declare -x LESSOPEN="|/usr/bin/lesspipe.sh %s"
declare -x LOGNAME="root"
declare -x
LS_COLORS="no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.svgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.dz=00;31:*.gz=00;31:*.bz2=00;31:*.tbz2=00;31:*.bz=00;31:*.tz=00;31:*.deb=00;31:*.rpm=00;31:*.jar=00;31:*.rar=00;31:*.ace=00;31:*.zoo=00;31:*.cpio=00;31:*.
7z=00;31:*.rz=00;31:*.jpg=00;35:*.jpeg=00;35:*.gif=00;35:*.bmp=00;35:*.pbm=00;35:*.pgm=00;35:*.ppm=00;35:*.tga=00;35:*.xbm=00;35:*.xpm=00;35:*.tif=00;35:*.tiff=00;35:*.png=00;35:*.mng=00;35:*.pcx=00;35:*.mov=00;35:*.mpg=00;35:*.mpeg=00;35:*.m2v=00;35:*.mkv=00;35:*.ogm=00;35:*.mp4=00;35:*.m4v=00;35:*.mp4v=00;35:*.vob=00;35:*.qt=00;35:*.nuv=00;35:*.wmv=00;35:*.asf=00;35:*.rm=00;35:*.rmvb=00;35:*.flc=00;35:*.avi=00;35:*.fli=00;35:*.gl=00;35:*.dl=00;35:*.xcf=00;35:*.xwd=00;35:*.yuv=00;35:*.svg=00;35:"
declare -x MAIL="/var/spool/mail/root"
declare -x PATH="/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/
bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/
bin"
declare -x PWD="/root"
declare -x QTDIR="/usr/lib/qt-3.3"
declare -x QTINC="/usr/lib/qt-3.3/include"
declare -x QTLIB="/usr/lib/qt-3.3/lib"
declare -x QT_IM_MODULE="xim"
declare -x SHELL="/bin/bash"
declare -x SHLVL="2"
declare -x TERM="xterm"
declare -x USER="root"
declare -x WINDOWID="46437423"
declare -x XMODIFIERS="@im=SCIM"

Joe English

unread,
Jan 15, 2009, 12:48:44 PM1/15/09
to
KOON wrote:
> output from ximinfo as follows:
> ./ximinfo: locale=zh_HK.UTF-8
> ./ximinfo: codeset=UTF-8
> ./ximinfo: XSupportsLocale => True
> ./ximinfo: XServerVendor => The X.Org Foundation
> ./ximinfo: XSetLocaleModifiers => @im=SCIM
> ./ximinfo: supported style XIMPreeditPosition|XIMStatusNothing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

OK so far; the IM and Tk have matching supported input styles,
X supports the locale; and it's using UTF-8.
Can't see why this shouldn't work.

> ./ximinfo: supported style XIMPreeditCallbacks|XIMStatusNothing
> ./ximinfo: supported style XIMPreeditNothing|XIMStatusNothing
> ./ximinfo: supported style XIMPreeditPosition|XIMStatusCallbacks
> ./ximinfo: supported style XIMPreeditCallbacks|XIMStatusCallbacks
> ./ximinfo: supported style XIMPreeditNothing|XIMStatusCallbacks
> environment variables as follows:

[... edited to include just the relevant ones...]

> declare -x GTK_IM_MODULE="scim-bridge"


> declare -x HOME="/root"
> declare -x HOSTNAME="localhost"
> declare -x INPUTRC="/etc/inputrc"
> declare -x LANG="zh_HK.UTF-8"

> declare -x QT_IM_MODULE="xim"
> declare -x XMODIFIERS="@im=SCIM"

Can you type Chinese into any Qt applications? How about Gtk+ ones?
What input method do you use? (SCIM is the IM engine, there's
usually a dialog box or taskbar button that lets you select
different input methods.)

With the above environment, Qt apps use the same mechanism
to talk to the IM as Tk does, while Gtk+ apps will bypass XIM
and talk to SCIM directly. So if Gtk+ apps work and Qt ones don't,
that's a clue.

... what to do with that clue, alas, I have no idea.
Troubleshooting this sort of thing is very difficult.

Anyone else? Certainly there must be *somebody* on this
newsgroup who knows how to make this stuff work.


--Joe English

George Peter Staplin

unread,
Jan 15, 2009, 3:49:50 PM1/15/09
to
Joe English wrote:

> KOON wrote:
>> output from ximinfo as follows:
>> ./ximinfo: locale=zh_HK.UTF-8
>> ./ximinfo: codeset=UTF-8
>> ./ximinfo: XSupportsLocale => True
>> ./ximinfo: XServerVendor => The X.Org Foundation
>> ./ximinfo: XSetLocaleModifiers => @im=SCIM
>> ./ximinfo: supported style XIMPreeditPosition|XIMStatusNothing
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> OK so far; the IM and Tk have matching supported input styles,
> X supports the locale; and it's using UTF-8.
> Can't see why this shouldn't work.
>
>> ./ximinfo: supported style XIMPreeditCallbacks|XIMStatusNothing
>> ./ximinfo: supported style XIMPreeditNothing|XIMStatusNothing
>> ./ximinfo: supported style XIMPreeditPosition|XIMStatusCallbacks
>> ./ximinfo: supported style XIMPreeditCallbacks|XIMStatusCallbacks
>> ./ximinfo: supported style XIMPreeditNothing|XIMStatusCallbacks
>> environment variables as follows:
>
> [... edited to include just the relevant ones...]

This is odd...

Should the == be an & here (from OpenIM()):
if (thisStyle == (XIMPreeditPosition | XIMStatusNothing)) {
bestStyle = thisStyle;
break;
} else if (thisStyle == (XIMPreeditNothing | XIMStatusNothing)) {
bestStyle = thisStyle;
}

When I have some time I'll study the libX11 code and make sense of what sort
of values thisStyle may actually contain to verify if the & fixes anything.

KOON, could you try changing the 2 == to & in tkUnixEvent.c:OpenIM() in that
chunk of code I pasted above, and then test Tk again?


>> declare -x GTK_IM_MODULE="scim-bridge"
>> declare -x HOME="/root"
>> declare -x HOSTNAME="localhost"
>> declare -x INPUTRC="/etc/inputrc"
>> declare -x LANG="zh_HK.UTF-8"
>> declare -x QT_IM_MODULE="xim"
>> declare -x XMODIFIERS="@im=SCIM"
>
> Can you type Chinese into any Qt applications? How about Gtk+ ones?
> What input method do you use? (SCIM is the IM engine, there's
> usually a dialog box or taskbar button that lets you select
> different input methods.)
>
> With the above environment, Qt apps use the same mechanism
> to talk to the IM as Tk does, while Gtk+ apps will bypass XIM
> and talk to SCIM directly. So if Gtk+ apps work and Qt ones don't,
> that's a clue.
>
> ... what to do with that clue, alas, I have no idea.
> Troubleshooting this sort of thing is very difficult.
>
> Anyone else? Certainly there must be *somebody* on this
> newsgroup who knows how to make this stuff work.

I'm trying my best...

George

Joe English

unread,
Jan 15, 2009, 8:22:55 PM1/15/09
to
George Peter Staplin wrote:
>
> This is odd...
>
> Should the == be an & here (from OpenIM()):
> if (thisStyle == (XIMPreeditPosition | XIMStatusNothing)) {
> bestStyle = thisStyle;
> break;
> } else if (thisStyle == (XIMPreeditNothing | XIMStatusNothing)) {
> bestStyle = thisStyle;
> }

Nope, "==" is right. An XIMStyle is basically a pair of enums
(XIMPreedit{Area|Callbacks|Position|Nothing|None} and
XIMStatus{Area|Callbacks|Nothing|None}) mushed into a
single word. The constants are defined in such a way
that they look like they're independent bits, but they
really aren't: exactly one of the XIMPreedit* and exactly
one of the XIMStatus* bits are set.

I think. Could be wrong about that, but that's my understanding.

>> Anyone else? Certainly there must be *somebody* on this
>> newsgroup who knows how to make this stuff work.
>
> I'm trying my best...

:-)

And it's appreciated -- if anyone can figure this out,
it's probably you...


--JE

KOON

unread,
Jan 15, 2009, 10:19:40 PM1/15/09
to

I can input chinese on software installed except wish from evolane
( etcl ) linux x86 version. Input method use is canjei, most popular
for traditional chinese. Tcl console mode both from etcl or from
source: chinese can be input but 2 backspace to delete chinese
character. the cursor position is misplaced
press backspace once, the word ,明,can't be deleted
% a明
after press backspace twice, output as follows:
%a
further press backspace, it make no difference:
%a
the first character will never be deleted on console mode after
chinese character input.
may be you are right, the qt library and xim caused the problem
(segmentation fault), even though I dont have any idea how to fix it.

Thanks

George Peter Staplin

unread,
Jan 19, 2009, 9:52:32 PM1/19/09
to
KOON wrote:

KOON, please submit a bug report via: http://tcl.sf.net

I don't want to lose track of this issue, and I'm busy with some other stuff
at the moment.

George

0 new messages