Hi, I had a problem with gedit (The most basic editor in GNOME!) while releasing lenny. These input method are very intrusive in terms of input handling routine. If input handling routine of an application has some bug, it can show up very badly: http://bugs.debian.org/374640
We eventually found this was fixed in other distro as: https://bugzilla.redhat.com/show_bug.cgi?id=201284 This ended up to be bug in gedit not SCIM. Please read previous reports and rethink your position. I suspect similar situation here since other more popular softwares are initialized properly, this is a bug in how each softwares is written to use SCIM. Have you tried ibus? That is another POV. Not all softwares are perfect. No one knows if it is SCIM or other application. Checking functionality under several situation helps dissect issues. On Sat, Jul 31, 2010 at 07:40:50PM -0700, Aaron Barany wrote: > > How do you know that their documentation is perfect to support SCIM on > > Debian? > > Correct me if I'm wrong, but I thought SCIM was supposed to be a plug-in for > the various UI frameworks (like gtk and QT) so that individual applications > don't have to worry about it. Since it's only relying on subsystems that > SCIM plugs into (in this case QT), I would expect it to be handled > automatically. Nothing is automatic if individual applications has funky bug. > > I can not second guess what is going on your system nor your compile > > problem. Are you sure you do not have some local files installed which > > interfairs with situation. > > I think you misunderstood me. What I was trying to say was since I > recompiled with the most recent libraries currently installed, I ruled out > any possibility of the binary being linked to an old version of a library > that was updated. Probably so provided you had all required -dev packages. Some autoconf compiles differently depending on the availability of library. > > This is your local problem. If you find a bug in current SCIM, please let > > us know it with fix patch. I do not have time to fix your local compile > > problem. It may be more helpful to contact bsnes upstream. > > Once again, I think you misunderstood what I said. I was trying to > demonstrate that as soon as the application starts, it initializes QT, which > in turn initializes SCIM, where it crashes. This isn't a "local problem", I > was trying to show that it follows the standard initialization procedure > instead of doing something abnormal. How do I know initialization code or your compile condition is bug free. > > So SCIM is working for QT :-) This means it is not my bug. Closing > > this bug. > > Since "normal" applications like text editors seemed to work fine, I > searched for another game that was based on QT to try and reproduce the > problem. I came across hedgewars, which is in the Debian repository. ( > http://packages.debian.org/squeeze/hedgewars) Looking at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577089 This application's input handling may be a bit buggy. You can feel free to file bug on hedgewars if it segfaulted. > This game also segfaults on > startup, with a stack backtrace that is almost identical to the backtrace > for **bsnes. One similarity that I can find between hedgewars and bsnes is > they use both QT and SDL. Since both QT and SDL provide input functionality, > I'm wondering if they are conflicting. Hey, I am not good enough to give you advise on these. When compiling software, many things can go wrong. If you find exact code to fix it, please send me one if I need to add it. > I also wanted to note that removing SCIM fixed the segfaulting. But that is not the proof of bug for SCIM. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
