Qt/SCIM broken (Cannot enter numbers in to spinbox widget)

[mhanski]

Kubuntu/Dapper: There is an issue with entering numbers into real number fields -- the number is always reset to 0. It happens both with the "official" scribus 1.2.4.1.dfsg-1ubuntu4 package from the ubuntu main and with self built scribus 1.3.3 from the scribus development branch. Possibly a problem with qt.

To reproduce the bug, please do the following:

-- launch scribus
-- File>New Document
-- Try do change the page size in the document properties

[mhanski (ma-han2000)]

Please see also the thread which starts with this mail:

http://nashi.altmuehlnet.de/pipermail/scribus/2006-March/016375.html

mhanski

[Alexandre Otto Strube (surak)]

The last message I found on this thread was:

> > comma-separated input is always reset to zero (for instants
> > margins) when you continue with the TAB-shift to the next
> > field; in general, numeric input resets vlues to zero.
> Specifically with regards to comma-separated lists,
> how does this work in locales that use a comma to
> separate the whole number part from the
> fractional part of a number?
> Germany uses 2,3 for 2 + 2*10**-1 ie 2.3 . How does that
> work in a list?

> Does the issue go away if you run Scribus as:
> LANG=en LC_ALL=en scribus
> ?

no, changing the language settings doesn't solve the problem. Strange enough: In all languages it's sufficient to run either the
FontSample-script or the FontTemplate to get out the described troubles.

In fact - I can live with this problem (which must not be a Scribus, but could be an Ubuntu Dapper bug!) now I know how to procede. Nevertheless - it could discourage people who start anew with Scribus, and that would be to regret!

mhanski, It seems you were using the CVS version of scribus. Could you please try doing the same with dapper's official scribus? Thanks for your attention.

[mhanski (ma-han2000)]

>mhanski, It seems you were using the CVS version of scribus. Could you please try >doing the same with dapper's official scribus?

I've tried both the cvs version (1.3.3cvs) and the dapper's official version 1.2.4.1.dfsg-1ubuntu4, both with the same results. I also asked other Scribus users, whether they encounter similar issues with their distros, which is not the case. I strongly suspect this could be related to the QT version of dapper (3.3.6), but unfortunately I don't know any other qt application which utilizes real number fields (apart from scribus) to check it.

[mhanski (ma-han2000)]

setting the status to confirmed, since Alexandre Otto Strube has observed the same behaviour.

Will anybody take care of this?

[Matt Zimmerman (mdz)]

Clearly an upstream issue, please forward upstream

[mhanski (ma-han2000)]

>Clearly an upstream issue, please forward upstream

What does it means in the plain language of us, mortals?

I strongly suspect the qt version which is delivered with ubuntu/kubuntu, because _noone_ of other Scribus users using other distros experiences this problem.

[mhanski (ma-han2000)]

The final note, since as a simple user I don't intend to put more effort into convincing Ubuntu makers to do sth about it:

-- It's only happens in Dapper Drake (everything works fine in Breezy)

-- It doesn't matter how old and how official the Scribus version is -- the issue can be easily reproduced

Please do with it whatever you want.

Truly yours
Maciej

[mhanski (ma-han2000)]

yet another final note:)

Think, I know what triggers this behaviour -- see the screen shot.

Scim as default input method for those qt fields seems to lock them -- after switching to other input method things start working as they should.

I have only two "*scim*" packages on my system, which seem to have been installed by default with kubuntu-desktop:

scim-qtimm
libscim8c2a

[mhanski (ma-han2000)]

http://bugs.scribus.net/view.php?id=3826

[Dennis Kaarsemaker (dennis)]

Developers determine their priorities - no need for users to do that for them

[Craig Ringer (ringerc)]

This sounds like it's probably a Qt issue. It wouldn't be the first one. In fact, it could even be related to this bizarre issue:

http://bugs.scribus.net/view.php?id=2425

which turned out to be a Qt bug in SuSE and some other distros that'd adopted the same patch.

[Daniel Frein (danielfrein)]

As mentioned above, only spinboxes with real numers inside reveal this bug, so there could be something wrong with the decimal seperator in spin boxes. QSpinBox does not allow to handle real numbers, therefore scribus has its own implementation 'MSpinBox' in mspinbox.cpp. I assume that something within this function does not like ubuntu's patches in qt-x11-free/libqt-mt.

For me, setting LANG to something different than de_DE.UTF-8 solves the problem, but I still hope that the bug will be fixed.

[mhanski (ma-han2000)]

echo "export LC_ALL=pl_PL" >> ~/.bash_profile

or

echo "export LC_ALL=de_DE" >> ~/.bash_profile

or

LC_ALL=whatever_your_language_is

solves the problem. Any thoughts, Ubuntu devs?

[Rocco Stanzione (trappist)]

I can't reproduce this on edgy. But, my locale is set to C.

[Risto H. Kurppa (risto.kurppa)]

Same problem here (Kubuntu dapper, finnish as primary language).

If I start scribus normally, the problem is there (line width etc. go to zero etc). But starting it with
 LANG=en LC_ALL=en scribus
removes the problem.

I noticed the same problem with KPhotoAlbum, it kept loosing dates.

See discussion here:
First mailing: http://mail.kdab.net/mailman/pipermail/kphotoalbum/2006-September/002314.html
(follow the thread)
and what I found out:
http://mail.kdab.net/mailman/pipermail/kphotoalbum/2006-October/002402.html

Is it a bug in the program or in Dapper localization settings / the way they're implemented? Someone, please take this forward..

r

[n3storm (n3storm)]

Spanish language desktop.

I removed the scim and skim packages from Kubuntu Dapper 6.06.1 and everything works perfectly withouth using any parameter on the commandline.

Just in case it helps to debug the problem.

I have already added the comment to the scribus bugtracker too.

Yours sincerly: n3storm

[mhanski (ma-han2000)]

 <quote>
I solved the problem by removing scim and skim packages from my Kubuntu 6.0.6.1 installation.
</quote>

I don't have scim installed, only scim_qtimm and skim. Removing scim_qtimm solves the problem in my case, but this is a really dirty workaround, since kubuntu-desktop depends on scim_qtimm and will be removed too:

 maciej@pan:~/tmp$ sudo apt-get remove scim-qtimm
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  kubuntu-desktop scim-qtimm
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 303kB disk space will be freed.
Do you want to continue [Y/n]?

This workaround solves the Scribus issue, but deprives me of keeping my system up to date with the current kubuntu development.

Question: Does kubuntu-desktop really need this dependancy?

[P Linnell (mrdocs)]

> Clearly an upstream issue, please forward upstream

We cannot solve this in Scribus. A number of tests convinces me this is not fixable by us.

[Oleksandr Moskalenko (malex)]

I am the scribus and scribus-ng package maintainer in Debian. This issue looks to be Ubuntu-specific based on the testing I've done as well. I think that Ubuntu developers should look at their modifications to qt3 and the scim issue. If there is a a need for Debian testing/comparisons I'd like to offer my help.

[mhanski (ma-han2000)]

Looong Time Support seems to mean here something different as widely assumed: 7 months has passed without a single message, not even a "boo", from the person to whom this issue is assigned. We have many, many reports and suggestion from user, even two Scribus team members (mrdocs and Craig Ringer) and the Scribus packager (Oleksandr Moskalenko) confirmed the broken qt modifications in Ubuntu that cause this issue and offered their help, to no avail.

Honestly, coudn't we have this issue reassigned to somebedy who actually does care a little and _wants_ to do something about it?

[Thom Hurks (thomhurks)]

This issue is bothering me too, it's even listed on the Scribus webpage now under "Ubuntu Issues". I mean, Scribus is even in the Ubuntu Weekly News #19 but they refuse to fix this bug.

Strange...

[Josef Assad (josefassad)]

I can reproduce this in edgy.

locale is set to en_GB.UTF-8

[Paul Sladen (sladen)]

I _can't_ reproduce this in edgy. en_GB.UTF-8 and selecting SCIM, or XIM. Is there a different example of how to reproduce this, other than the example given in the first description.

[Paul Sladen (sladen)]

In Dapper, there were four *separate* issues to do with SCIM and Qt being broken or less usable. Bug #57081 is a long bug discussion that eventually, I believe, gets to the root of the problem.

Is it the case that this bug report exists because of 3 of those 4 issues with SCIM on dapper? If so, we should repoint this bug at 'scim-foo', or 'qt-*' rather than scribus even if, in this case, people are *seeing* the bug show up in scribus.

[Paul Sladen (sladen)]

Based on my reading of:

  http://www.suse.de/~mfabian/suse-cjk/kde-input-style.html

In the SCIM style of input for various far-eastern Asian languages, the result (completition) is built up as more keys are typed.

The problem seems to come down to whether possibily completions are displayed *in* the widget (such as a spinbox), or *over* the widget.

Over the Widget means that the completion is not pasted back to the widget until the completion is finalised. A spin-box having a constraint (eg. "great that zero") may complain at a half-completed result and instead set the spinbox value to zero.

Suse suggest "Over the widget" where completions are displayed in a separate window until finalised.

[Paul Sladen (sladen)]

jriddell: this bug actually needs assigning to 'qtimm' or 'scim-something' or another Qt library. Do you know which one?

[Paul Sladen (sladen)]

These should possibly be all dup'ed to: bug #57081.

[Paul Sladen (sladen)]

mvo: you were handling bug #57081 ("scim-chewing generally broken"). Do you think this (scim-qtimm spinbox brokenness) has been caught?

[Ming Hua (minghua)]

FWIW, I hope this bug NOT be merged with bug #57081.

There are actually three issues here:

1. scim-chewing corrupts user configuration data on some abnormal exits (the main issue of bug #57081, fixed in edgy by new upstream scim-chewing and libchewing).

2. scim-chewing's im-switch setting uses scim-qtimm by default, which breaks in Ubuntu installs with user-installed KDE apps (independent to issue 1, but unfortunately mixed together in bug #57081, also fixed in edgy by changing the im-switch setting in scim-chewing).

3. scim-qtimm breaks scribus, i.e., this bug. This is strictly a scim-qtimm issue, has nothing to do with scim-chewing.

[Paul Sladen (sladen)]

Hello cjk-hackers!

Can anyone replicate these Scribus/spinbox issues? It may only be on Dapper.

If they can be reproduced on Dapper, has the spinbox and qtimm gone away again in Edgy?

[Josef Assad (josefassad)]

https://launchpad.net/distros/ubuntu/+source/scim-qtimm/+bug/37711/comments/22

Not sure if you were only looking for input from cjk-hackers, which I'm not. But it's edgy and reproducible here.

[Jiahua Huang (huangjiahua)]

I can't reproduce this in edgy. zh_CN.UTF-8, scim, skim.

[Ming Hua (minghua)]

I can NOT reproduce this on a fresh Kubuntu 6.10 (edgy) install, using alternative CD, choosing US and English. My locale is en_US.UTF-8 (the default after installation).

After installing scribus, I can start it and choose "File -> New" menu, then in the "New Document" dialog window, change "Page Size -> Size:" to "Custom", then change the Width: and Height: spin box at will, either by using the up and down arrow buttons, or by just inputing numbers by hand.

In this default setup, my "[right click] -> Select Input Method" menu shows "XIM", if I change it to "scim", the whole scribus program freezes. If I start scribus by "QT_IM_MODULE=scim scribus" from terminal, the program will also freeze when I choose "File -> New" menu to bring up the dialog window. However, I assume this is an unrelated bug.

[Ming Hua (minghua)]

I am therefore starting to suspect this bug share the same causes with bug #35760, and both of them can only be reproduced with a non-US X keyboard map setting.

Would everyone who can reproduce this bug, either on dapper or edgy, provide your X keyboard map setting? I think you can look at your /etc/X11/xorg.conf file and search for the line with 'Option "XkbLayout"' to find out what X keyboard map you are using. I don't know if there is an easier way.

[Josef Assad (josefassad)]

Linux jassad-laptop 2.6.17-10-386 #2 Fri Oct 13 18:41:40 UTC 2006 i686 GNU/Linux
ubuntu edgy, no backports, nothing pinned.

From my xorg.conf:
 Option "XkbLayout" "us_intl,ara,dk"

(yes, English, Arabic, and Danish; ain't easy being binational!)

Let me know if there's additional information I can provide.

[yannek (yannek-deactivatedaccount)]

kubuntu edgy, no backports, nothing pinned

Option "XkbLayout" "de"
Option "XkbVariant" "nodeadkeys"

I'am also open to further questions.

[mhanski (ma-han2000)]

Kubuntu Dapper Drake LTS:

 Option "XkbLayout" "de"
 Option "XkbVariant" "nodeadkeys"

I also use two switchable keyboard maps "de basic" and "pl" in my system (to be set in KDE System Settings)

[Bruno S. (fischkudder-deactivatedaccount)]

I still experience this issue in Edgy. "LANG=de LC_ALL=de scribus-ng" solves it.

[Benoit St-André (benoit-st-andre)]

I can reproduce this on Edgy. My locale is fr_CA , and my xorg conf contains this

        Option "XkbModel" "pc105"
        Option "XkbLayout" "ca"
        Option "XkbVariant" "fr"

Also, thought you might know that starting scribus-ng with those parameters seemed to solve the problem

 "LANG=fr_CA LC_ALL=fr_CA scribus-ng"

except that all the spinbox using that any spinbox using inches as length turns to a bizarre high value and makes them unable to change any value in them.

 "LC_ALL=C scribus-ng" does the same thing.

With "LANG=en LC_ALL=C scribus-ng", everything is back to normal. The problem there is that the interface is not localized that way, but scribus works anyway.

Just ask me if there are other tests that might be needed.

[Oleksandr Moskalenko (malex)]

Thank you Benoit St-André and silentb. I added your info to the bug report in the Scribus BTS.

[Jan Claeys (janc)]

I can't reproduce this on Feisty (with a 'be' keyboard and a nl_BE locale, if that matters). Could other people who saw this bug before please test this on Feisty too?

[yannek (yannek-deactivatedaccount)]

It's still that way.
Im with a de_DE locale and a de no_deadkeys keyboard, on a feisty that dist-upgraded yesterday evening.

With scribus-ng: If you try to modify a spinbox with decimal values in it via its up down arrows or enter directly the value into it, it resets to zero.

[Warhog (warhog)]

I can reproduce the bug. I'm running a Kubuntu 6.10 Edgy Eft which was upgraded from a Dapper Drake Installation (thus it's not a fresh one).

I tested the official scribus package (some 1.2.x version) and compiled version 1.3.3.8 myself, in both versions the bug occurs. You might most simply note it when you want to enter a custom zoom-factor like 150% - in my case it is always set to 10%, which is the minimum for that spinbox, i suppose.

My Locale is normally set to de_DE.UTF-8, running scribus using LC_ALL=C solves the problem (but then I can't use my ä-ö-ü-Keys in Scribus). Annoying.

My keyboard-layout is de-nodeadkeys.

[mhanski (ma-han2000)]

Sadly, I missed the first anniversary of this "high importance" bug (yes, I submitted it over a year ago).

But, I'm still there on Kubuntu Dapper Drake Long Time Support with all current updates, and the bug is still there too.

I haven't given up on Kubuntu yet and would really like to see some action, at least an attempt to solve the issue.

[Giuped (giuped)]

problem persists in kubuntu 7.04

[Pavel Kaspar (xpalko)]

You must remove all scim a skim packages and libraries (libscim, libskim, atc.), not only scim and skim packages - I'm running Kubuntu 6.10 in LC_ALL=cs_CZ and I have no problem.

[yannek (yannek-deactivatedaccount)]

Thanks Pavel,

that is the old mokey problem. This didn't work out 'once',
like mhanski wrote down:
---
I don't have scim installed, only scim_qtimm and skim. Removing scim_qtimm solves the problem in my case, but this is a really dirty workaround, since kubuntu-desktop depends on scim_qtimm and will be removed too:
[...]
Question: Does kubuntu-desktop really need this dependancy?
---
Yet the answer today is: No it doesn't! It it does no longer depend on it.

At least with feisty you can simply remove the s[ck]im related libs, hope that you will not need this input methods, and live happly ever after with a scribus that behaves as expected, and a kubuntu-desktop meta-package installed. Yippy!

[humufr (humufr-deactivatedaccount)]

other software than qt/scim software are touch by the same kind of problem, perhaps it's linked somewhere.

https://bugs.launchpad.net/ubuntu/+source/python-stdlib-extensions/+bug/111917

[Jakob (jlemvig)]

problem persists in kubuntu 7.04 for scribus 1.3.3.9 and scribus-ng 1.3.4 (from debian.scribus.net following http://wiki.scribus.net/index.php/Getting_Scribus_on_Ubuntu/Kubuntu_up_and_running). LANG=en LC_ALL=en scribus fixes it.

[Jonas Diemer (diemer)]

For me, "LC_ALL=C scribus" also fixes the problem, but does not affect the program's GUI-Language (German in my case).

I suggest that the Ubuntu package maintainers fix the K-Menu / Gnome-Menu entries for Scribus to e.g. "LC_ALL=C scribus-ng %f". This way, the problem is fixed for every user for now.

[humufr (humufr-deactivatedaccount)]

That will change nothing. Scribus will work but not in the langage of the user and this is bad especially because ubuntu is one of the rare distribution with this problem. This problem is more general, it doesn't concern only qt software but also some python/tk software. What's next? Gnome and KDE software? In a certain sens I hope because this problem is very very important.

But we can't do "LC_ALL=C scribus", "LC_ALL=C pyraf", "LC_ALL=C another_software_with_the_same_problem"

[Jonas Diemer (diemer)]

Yes, you are right: The GUI Language is the expected, but the number format will not be correct. And I agree that this problem should be fixed instead of implementing the workaround.

But since this bug has been pending for more than a year w/o a fix, my suggestion is that the workaround should be enabled by default so the everyday user can work with scribus. This is until there is a real fix of course.

[humufr (humufr-deactivatedaccount)]

I understand your point very well but I'm pretty sure that would be a bad idea. More people will put bug report on it more chance we will have a correction. I'm very surprised that this bug is still here because ubuntu is the only distribution (with the last Suse) touch by this so the chance must come from an ubuntu bug (debian doesn't have the problem). Is it more UTF-8 related and not Qt-Scim? I think so or perhaps some developper can explain me why the same behavior happen with python/tk software...

[humufr (humufr-deactivatedaccount)]

and like I explain in the related bug (I think) but qith python/tk this bug stop me to install ubuntu in all the computer in my lab, a shame!

[Silvano (silvano-jorge)]

Hello

I have this bug, and I would like to temporaly fix it. I know that this isn't properly here, but I need some help, please.
Can I execute Scribus as a new user who have a different system language?
If yes, I know how to execute as a different user, but, how can I change the language for each user?
this would fix the problem for the moment?

Thank all!!

[humufr (humufr-deactivatedaccount)]

Hi,

you can do an alias

alias scribus-ng='LANG=C LC_ALL=C scribus-ng'

in a global file like /etc/bash.bashrc

it's not very good but that work for all user who will use bash for shell.
Or you can change the /usr/share/menu/scribus-ng file. I think that is the
file use to create the menu.

I hope that will help.

Nicolas

On Tuesday 19 June 2007 08:06:36 Silvano wrote:
> Hello
>
> I have this bug, and I would like to temporaly fix it. I know that this
> isn't properly here, but I need some help, please. Can I execute Scribus as
> a new user who have a different system language? If yes, I know how to
> execute as a different user, but, how can I change the language for each
> user? this would fix the problem for the moment?
>
> Thank all!!

[Silvano (silvano-jorge)]

Success!!!!!

Thank you very much Nicolas

[Łukasz Jernaś (deejay1)]

It's not a Scribus bug, general scim-qtimm

[Rolf Leggewie (r0lf)]

Is this still an issue?

[Silvano (silvano-jorge)]

Hi
It is fixed, at least in Scribus 1.3.8
thank you

On Tue, Aug 10, 2010 at 4:18 PM, Rolf Leggewie <email address hidden>wrote:

> Is this still an issue?
>
> --
> Qt/SCIM broken (Cannot enter numbers in to spinbox widget)
> https://bugs.launchpad.net/bugs/37711
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[yannek (yannek-deactivatedaccount)]

In Lucid Scribus 1.3.3.14 works fine too.

[Rolf Leggewie (r0lf)]

Thank you for your feedback. I'm closing this ticket as fixed based on the two positive reports. Please feel free to reopen if you still experience this issue.