Version: 3.1.0-beta1 (using KDE KDE 3.2.91) Installed from: Gentoo Packages Compiler: gcc (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) My name is 'Diego Pettenò', so I need to use the extended ascii character ò when I wrote my complete name. But when creating a new project with KDevelop 3.1.0-beta1, I have problems: after the wizard I have an error messagebox which says "This is not a valid project file. XML error in line X, column Y: tag mismatch". Then if I look at the .kdevelop project file, I have: <general> <author>Diego 'Flameeyes' Petten?/author> <email>dgp85@users.sourceforge.net</email> <version>0.1</version> <projectmanagement>KDevKDEAutoProject</projectmanagement> <primarylanguage>C++</primarylanguage> <keywords> <keyword>C++</keyword> <keyword>Code</keyword> <keyword>Qt</keyword> <keyword>KDE</keyword> </keywords> </author> <ignoreparts> <part>KDevdistpart</part> <part>KDevCTags</part> <part>KDevcopyto</part> <part>KDevClearCase</part> <part>KDevFileGroups</part> <part>KDevDebugger</part> <part>KDevDoxygen</part> <part>KDevPerforce</part> </ignoreparts> </general> To make KDevelop load the project I need to fix the error in the <author> tag above, remove the misplaced </author> after </keywords> and remove the ò chacter from <AUTHOR> tag below (in the <subst> tag).
*** This bug has been marked as a duplicate of 61031 ***
As I thought, this isn't a dupe of the #61031, because it's still there in 3.0.92 version. No news from the ones provided before.
*** Bug 86191 has been marked as a duplicate of this bug. ***
If someone can address me to a restricted part of KDevelop sources where to search for this bug, I can try to fix it myself, but it's quite annoying for now, because it disallow me to use my true name for projects.
Check the files under parts/appwizard/* API doc can be found here: http://www.kdevelop.org:8080/HEAD/doc/api/html/
This is fixed in both KDE_3_3_BRANCH and HEAD
not fixed in KDE_3_3_BRANCH at least with today checkout.
Your name (Diego Pettenò) and other strange characters worked fine in my local KDevelop. Please try again today, maybe the mirrors where out of sync.
Thanks, today works fine also for me :)
*** Bug 98283 has been marked as a duplicate of this bug. ***
*** Bug 98946 has been marked as a duplicate of this bug. ***
Question: If this bug was fixed in HEAD before release of 3.2.0, shouldn't it also be fixed in 3.2.0? I'm using a Gentoo package of 3.2.0 and the problem is still there. However, the syntax of the XML file is correctly written (no crippled </author> tag). Only the opening of the file fails if there is an extended character inside. Details can be found at http://bugs.gentoo.org/show_bug.cgi?id=93512
Probably it is a Gentoo specific bug.
Okay, but this doesn't help me very much. :-/ The Gentoo package of 3.2.0 does not apply any patches to the source code, it's just a plain compile-and-install. How could any Gentoo specific errors have been introduced? Compiler bug? Bug in an external library? How do I track this down? Does Kdevelop use any external libraries for parsing xml? The Gentoo package does not have any dependencies related to parsing; only flex, which I think is pretty stable ... Are you certain you cannot reproduce the bug opening the project file I posted at http://bugs.gentoo.org/show_bug.cgi?id=93512 ?
Sorry Amilcar, but you were in error. The problem is not Gentoo specific. I filed another bug report and we found a solution. I think the appwizard has to be fixed again. It should be easily done. Please see #106910 for details.
OK, SuSE does not have this issue, but other dirtros do. The solution is to change the first line of the project file to: <?xml version="1.0" encoding="ISO-8859-1"?> This way the XML parser uses the correct encoding instead of assuming a UTF-8 encoding.
*** Bug 106910 has been marked as a duplicate of this bug. ***
This bug still exists in kdevelop for KDE 3.5 and is confirmed by me. Another user also tested it. This is a big bug in my opinion as a new project does not start when the name contains a special character. In my test the header shows: Copyright (C) 2005 by Anne-Marie �� * and the name should be Anne-Marie Frühauf (which happens to be my maiden name ;)
Testing this with the examples above and Japanese characters, I have the start of the kdevelop file as: <?xml version = '1.0'?> <kdevelop> <general> <author>あつこ。戸。Pettenò Frühauf</author> <email>megan@dragon</email> <version>0.1</version> <projectmanagement>KDevKDEAutoProject</projectmanagement> <primarylanguage>C++</primarylanguage> <keywords> (Other parts of the file also have the author tag - displayed the same) Kdevelop 3.3.92, r601280, builds the project and has no trouble displaying the extended ascii or Japanese. I have no trouble seeing the characters in any kde application or utf-8 aware application. I used the "Simple KDE application" for the test. If I open the .kdevelop file in nedit (this program warns that UTF8 locale is not supported) then I see: <?xml version = '1.0'?> <kdevelop> <general> <author>ãã¤ããæ¸ãPettenò Frühauf</author> <email>megan@dragon</email> <version>0.1</version> <projectmanagement>KDevKDEAutoProject</projectmanagement> <primarylanguage>C++</primarylanguage> <keywords> <keyword>C++</keyword> <keyword>Code</keyword> <keyword>Qt</keyword> <keyword>KDE</keyword> </keywords> I'm running with locale settings of: megan@dragon ~/devel $ locale LANG=en_AU.UTF-8 LC_CTYPE="en_AU.UTF-8" LC_NUMERIC="en_AU.UTF-8" LC_TIME="en_AU.UTF-8" LC_COLLATE="en_AU.UTF-8" LC_MONETARY="en_AU.UTF-8" LC_MESSAGES="en_AU.UTF-8" LC_PAPER="en_AU.UTF-8" LC_NAME="en_AU.UTF-8" LC_ADDRESS="en_AU.UTF-8" LC_TELEPHONE="en_AU.UTF-8" LC_MEASUREMENT="en_AU.UTF-8" LC_IDENTIFICATION="en_AU.UTF-8" LC_ALL= and have full characters set support built into glibc and all applications. Kdevelop uses the underlying libraries to read the files. The libraries must support the character set that the file is encoded with. I'm marking this as resolved. The problem is that libraries on the system do not support the required character sets. Will reopen if more information shows this is not the case.