Version: (using KDE KDE 3.5.0) Installed from: SuSE RPMs OS: Linux I use US English and Greek languages but unfortunately the "Include latin layout" option is always disabled, even when i select the Greek language! So the effect is that i cant use some shortcuts like Ctrl-C when writing in Greek ... Is there any way to enable it manually?
Some of my friends, using new Kubuntu, run into the same problem. So I did some looking through the kxkb code. For "Include Latin layout" to work, X's xkb has to support grouping of layouts, which is a feature of XFree86 4.3.0 and newer, and Xorg. So kxkb tries to detect whether X server is 4.3 or newer, by probing for the directory <X11_DIR>/xkb/symbols/pc, which was introduced precisely in XFree86 4.3. However, in (latest?) Xorg, at least the one which ships with new Kubuntu, this directory is no longer present (instead there is a file named pc). Thus, kxkb misdetects the availability of grouping, and "Include Latin layout" is deactivated.
I have installed KDE 3.5 in my SUSE 9.2 and the "Include latin layout" option works fine... But i found out that in Suse 10.0 this option is always disabled (since KDE 3.4.2). So i dont think that KDE 3.5 has introduced this problem.
It is not that a bug has been introduced by KDE 3.5, but that the grouping detection method is flawed, so that sometime recently it "got carpet pulled under its feet" :) I don't know how to make it better though, but browsing through XFree branch history, and checking in XOrg and XKeyboardConfig trees, I see that since XFree 4.3.0.1 and onwards, there exists file <X11_DIR>/xkb/symbols/group (the one which contains definitions of group switching symbols). So a quick and (again) dirty fix would be to check for the existence of that file, rather than the directory <X11_DIR>/xkb/symbols/pc as it is now. Any comments from the maintainer? This is indeed a nasty bug for users of non-Latin keyboard layouts and should be resolved in any way, even if provisionary, for KDE 3.5.1.
BTW have u got any ideas on what dirty hacks to make in my <X11_DIR>/xkb/symbols/ directory to make kxkb to work again?
Dirty hacks, eh? In symbols/, you'd have to rename file pc to something else, and then make (empty) directory pc. However, file pc is used in include statements in other files in symbols/, so you'd have to correct them all to what you renamed pc (there are also self referencing includes in pc itself). This can be easily performed with a perl one-liner, but would render your symbols/ directory impossible to update automatically. (Sorry for the late answer :)
I also believe that this problem could be solved if the "Command" textfield (under Layout tab) was editable... See bug#108917
*** Bug 119158 has been marked as a duplicate of this bug. ***
Every attempt to guess the version from a layout of a filesystem is doomed to fail when the layout is changed again in a new version of X. Is it possible to detect the version of X directly? I mean calling "X -version" gives some information here which could get parsed. Here I get: X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: SuSE Linux [ELF] SuSE Current Operating System: Linux jhe500m 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 i686 Build Date: 12 September 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present It should be not too hard to check this for the other versions of X as well.
Talking to folks on XKeyboard-Config list, -print parameter to setxkbmap can be used to get output sent to xkbcomp, and there one can see if grouping is supported. Eg: setxkbmap -print -layout xx,yy -variant aa,bb will give several lines of output, one being like: xkb_symbols { ... +pc/xx(aa)+pc/yy(bb):2+ ... }; where 'yy(bb):2' indicates that grouping and variants are understood. (It doesn't make fuss about xx and yy not being on the system, that is job of xkbcomp later on). I made a patch based on parsing this, but since I am fresh with KDE machinery, I feel reluctant to commit it.
Created attachment 14133 [details] Determine grouping availability by setxkbmap -print
Created attachment 14134 [details] Determine grouping availability by existance of X11_DIR/symbols/group As a low code-intrusion alternative, in case that previous one is too much...
Nice! I hope someone commits it before KDE 3.5.1 hits the streets ;)
For those who need this problem fixed now! Here are easy instructions for applying Chusslove Illich patch and recompiling kxkb: 1. Get the latest Konstruct package from http://developer.kde.org/build/konstruct/ 2. Unpack it to your preferred working folder (hereforth - [workingfolder]) and change to it. 3. Edit the [workingfolder]/konstruct/kde.conf.mk file so that YOUR preferred mirror is the 1st on list ( in my case it's ftp.oregonstate.edu, some examples are in the file) 4. cd to [workingfolder]/konstruct/kde/kdebase 5. download and extract the kdebase by "make extract" (22Mb downloaded and extracted) 6. cd to [workingfolder]/konstruct/kde/kdebase/work/kdebase-3.5.0/kxkb 7. find "if( QDir(X11_DIR + "xkb/symbols/pc").exists() ) {" in file "rules.cpp" and change it to "if( QFile(X11_DIR + "xkb/symbols/group").exists() ) {" 8. cd to [workingfolder]/konstruct/kde/kdebase/work/kdebase-3.5.0 9. do a "configure --prefix=[put distro-specific path to KDE here]" ( in my case (Suse) --prefix=/opt/kde3) 10. (IMPORTANT!) cd to [workingfolder]/konstruct/kde/kdebase/work/kdebase-3.5.0/kxkb 11. do a "make" and (2 minutes later, and assuming no errors) "make install" 12. For a good measure, log out, log in and you'll have "Include Latin Layout" option available.
I tested both patches on Suse 10 and KDE 3.5 from SVN: 1. the X11_DIR/symbols/group patch works fine here 2. the other patch does not compile :-( but when I execute the command in a console I get the expected output, so the patch is probably correct I really want to have one of the patches in KDE 3.5.1 but I do not know which one is the better solution.
ok, I've taken a look at the short patch, and it may do the job, but it breaks the idea, the line if( QDir(X11_DIR + "xkb/symbols/pc").exists() ) was there to check if it's XFree 4.3 or later while if you're doing if( QFile(X11_DIR + "xkb/symbols/group").exists() there's a problem as this file is preset also for 4.2 and earlier so the check is invalid I'm finishing my environment for 3.5 tonight, so I'll be able to put more proper check of X version.
Ok, as there's no quick right fix for this, I just removed check for XFree 4.3 so it may not work on older XFree versions. Hopefully it'll be not an issue for KDE 3.5.1. If somebody can retest from SVN and let me know if the problem is gone, I'd close this bug.
I did test it and it is working with Suse 10. But my opinion is that to disable the check is not a real solution. What about the other patch that reads the output of setxkbmap?
"I just removed check for XFree 4.3" Chnaces are - ppl running kde 3.5.1 will not be running it on "ancient" X. Besides, no matter what the check is for, it will eventually fail when X changes again. (Saw this on PBS: NASA programmers coded in a check into software that ensured that angles more than 360 degrees cannot occure > and couldnot cause errors. As a result a robot's arm could not rotate around it's axis. Moral - apply checks sanely.)
I agree with Daniel about chances, plus I don't know easy way to tell if current version of XFree supports the structures we need to check variants in kxkb. It's not only about grouping availability, in 4.3 XFree symbols/pc/ directory has been added which I had to check first (if some option hasn't been set) and fail back to symbols/ if anything goes wrong. Now SuSE removes that dir, while other distros have it... To provide some functionality with variants and fix 'shortcuts in non-lating layouts' I had to put some complex code back then so I don't think any fix for 3.5.x will be perfect - but for KDE4 I am planning to redo that all.
SVN commit 509665 by rysin: - refactoring kxkb sources to more modular structure - reintroducing feature to allow switching same layouts with different variants - fixing couple of small problems (like X calls resulting in BadWindow error) - optimizing caching of precompiled layouts (no reopening the file - just rewinding) better optimization could be done by caching in memory GUI: add column 'Variant' in layout list, adding '<default>' to list of variants BUG: 121520 BUG: 121409 BUG: 121284 BUG: 120037 BUG: 117468 BUG: 116619 BUG: 110811 BUG: 104828 (partially) M +6 -3 Makefile.am M +173 -60 extension.cpp M +22 -16 extension.h M +355 -374 kcmlayout.cpp M +7 -33 kcmlayout.h M +28 -3 kcmlayoutwidget.ui M +31 -0 kcmmisc.cpp M +2 -0 kcmmisc.h M +201 -443 kxkb.cpp M +26 -130 kxkb.h A kxkbconfig.cpp [License: UNKNOWN] A kxkbconfig.h [License: UNKNOWN] A kxkbtraywindow.cpp [License: UNKNOWN] A kxkbtraywindow.h [License: UNKNOWN] A layoutmap.cpp [License: UNKNOWN] A layoutmap.h [License: UNKNOWN] M +71 -279 rules.cpp M +10 -18 rules.h A x11helper.cpp [License: no copyright] A x11helper.h [License: no copyright]
Mostly Q's to Andriy: Found these similar-in-nature bugs. Was wandering if your patch applies to them as well http://bugs.kde.org/show_bug.cgi?id=107864 http://bugs.kde.org/show_bug.cgi?id=83732