Version: unspecified (using KDE 4.4.3) OS: Linux When creating a new transaction, if there are categories in Greek that contains accents, the filtering while typing does not work for the accented characters. For example, for the category Σούπερ Μάρκετ, I cannot type Σούπερ Μάρκετ, instead the output is Σο´υπερ Μ´αρκετ while typing. It appears that the accent is somehow dead and is not placed on top of the letter. Reproducible: Always Steps to Reproduce: Enter a category in Greek with accents. Create a new transaction. In the category name, start typing to filter out the desired category. The accent is not placed properly. Actual Results: The accent is placed by itself followed by the vowel without the accent. This creates problems while searching for a category that contains accents. Expected Results: The filtering of the category should work in either case of accented and non-accented category names. KMymoney 3.98.1 Qt 4.6.2 OS: Linux (x86_64) release 2.6.34-gentoo Compiler: x86_64-pc-linux-gnu-gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2)
I analyzed this and it is very complex to solve in the current (historical Qt3 driven) setup. Since the widget that causes the problem is to be replaced with the MVC combo box anyway, I suggest not to fool around with the code at this point in time. The MVC combos seem to work in this respect, as I have tested the procedure given on the payee widget w/o problems. The payee widget is already based on the MVC combo. We know, that it is a bug, but I suggest to stay with the stability we gained at this point rather than playing with this complex part of the code. If anyone feels to dive into this one, please speak up here and attach your patches.
Does this still happen after everything has been ported to Qt4?
(In reply to comment #2) > Does this still happen after everything has been ported to Qt4? I thinks so since at the time Thomas did the analysis that part was already ported to Qt4 without Qt3Support.
Out of curiosity, does this happen with other languages with accented characters, or is it specific to Greek?
Yes, I used é and è (available in e.g. French) to duplicate the problem.
Is this an input problem? How is the é and è inputted? I recall using ă,â,î,ş,ţ without any problems. I'm using 'AltGr' to enter these characters.
Yes it is. é is typing ´ and e or ê is done by pressing ^ and then e. You might not be able to do this using your keyboard layout.
I can type é, á, and other accents, and the input is handled correctly and in other transactions, the completer recognizes them correctly. (My KDE regional settings are Spanish - Argentina, and the keyboard layout is LatinAmerican, both of which handle these accents) Perhaps this is a problem with the KDE settings for the keyboard layout?
Yes, that works here fine also, unless the selection window is open or was opened at least once during the lifetime of a e.g. category widget. I created an income called tést (I don't have any accounts with an accent). Then start a new transaction in a checking account. Tab to the category field and enter ' followed by e. The popup opens and the relevant accounts are shown. Clear the text in the category with backspace. All accounts are shown in the popup. So far so good. Now type ' followed by e again as above. I do see two characters now: 'e . In that state, backspace so that the category field is empty again. Press ESC to close the popup. Now type ' followed by e and things start to work again. My assumption is, that this behavior is somehow related to the popup selector. I do see the same behavior on the payee widget. Just another method to reproduce the problem: Type any matching character in the payee or category widget, then press ' and e and you now see three characters instead of two.
Now that we have a stable release of KMymoney, is there a chance someone will take a closer look at this issue?
Can someone give a description of what input language to use so that pressing 'e would give me é?
(In reply to comment #11) > Can someone give a description of what input language to use so that pressing > 'e would give me é? I use a USA international keyboard with AltGr dead keys with Compose set to the menu key. Pressing Compose + ' + e gives é.
I've managed to reproduce it. I'll take a look at it.
SVN commit 1192829 by conet: BUG: 241044 This was the hardest bug I've ever fixed. Our custom editable combobox is really hard to maintain regarding input events. Let's hope this is fixed now. After some testing in trunk we should backport this to the stable bugfix branch so reporters please test this thoroughly. The fix consists of two parts. The first one is to replace the completer window type from popup to tooltip. This was done to avoid stealing the keyboard input from the combobox's lineedit. So far we where relaying key press/release events to the line edit but this is not enough for using input methods (see QInputContext). The first part enabled using input methods after showing the popup but for the first time we show the popup. This was because somehow showing the popup would mess up the input context of the widget. Work around this with a second fix: create a new input context for the combobox each time the popup is show. M +1 -1 kmymoneyaccountcompletion.cpp M +0 -6 kmymoneycombo.cpp M +17 -9 kmymoneycompletion.cpp M +2 -5 kmymoneyselector.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1192829
I created a patch from the changed files and tried to emerge it in my Gentoo box using version 4.5 (does the patch really apply for this version?). It fails while linking libkmm_kdchart.so: [ 31%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/LeveyJennings/KDChartLeveyJenningsGrid.cpp.o [ 31%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/LeveyJennings/KDChartLeveyJenningsGridAttributes.cpp.o [ 31%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/PrerenderedElements/KDChartTextLabelCache.cpp.o [ 32%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Scenery/ChartGraphicsItem.cpp.o [ 32%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Scenery/ReverseMapper.cpp.o [ 32%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Ternary/KDChartAbstractTernaryDiagram.cpp.o [ 32%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Ternary/KDChartTernaryAxis.cpp.o [ 32%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Ternary/KDChartTernaryCoordinatePlane.cpp.o [ 33%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Ternary/KDChartTernaryGrid.cpp.o [ 33%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Ternary/KDChartTernaryLineDiagram.cpp.o [ 33%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Ternary/KDChartTernaryPointDiagram.cpp.o [ 33%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Ternary/TernaryConstants.cpp.o [ 33%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/Ternary/TernaryPoint.cpp.o [ 34%] Building CXX object libkdchart/src/CMakeFiles/kmm_kdchart.dir/moc_KDChartEnums.cxx.o Linking CXX shared library ../../lib/libkmm_kdchart.so [ 34%] Built target kmm_kdchart make: *** [all] Error 2 emake failed Any ideas?
I can't tell what's wrong since you didn't post the actual error. If you are running make with -j greater than 1 then the actual error could be way before in the log because of the parallel make steps. Error 2 is caused by something before KDCharts. And no the patch is not against 4.5 but against trunk although it should work against 4.5 also since there are no big changes against trunk and 4.5. If you run gentoo you can try to use the following method when installing kmymoney: 1 . checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdesdk/scripts/createtarball and use create_tarball.rb to create a 4.5 tarball from trunk '$./create_tarball.rb -n -a kmymoney' 2. '$cp kmymoney-4.5.tar.bz2 /usr/portage/distfiles/' 3. 'ebuild --force /usr/portage/app-office/kmymoney/kmymoney-4.5.ebuild manifest' 4. emerge kmymoney This way you can always install from trunk.
SVN commit 1193386 by conet: BUG: 241044 This was the hardest bug I've ever fixed. Our custom editable combobox is really hard to maintain regarding input events. Let's hope this is fixed now. After some testing in trunk we should backport this to the stable bugfix branch so reporters please test this thoroughly. The fix consists of two parts. The first one is to replace the completer window type from popup to tooltip. This was done to avoid stealing the keyboard input from the combobox's lineedit. So far we where relaying key press/release events to the line edit but this is not enough for using input methods (see QInputContext). The first part enabled using input methods after showing the popup but for the first time we show the popup. This was because somehow showing the popup would mess up the input context of the widget. Work around this with a second fix: create a new input context for the combobox each time the popup is show. Backport to the stable branch. M +1 -1 kmymoneyaccountcompletion.cpp M +0 -6 kmymoneycombo.cpp M +17 -9 kmymoneycompletion.cpp M +2 -5 kmymoneyselector.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1193386