Summary: | Author Name doesn't accept special characters | ||
---|---|---|---|
Product: | [Developer tools] kdevplatform | Reporter: | Amilcar do Carmo Lucas <a.lucas> |
Component: | appwizard | Assignee: | KDevelop Developers <kdevelop-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | block111, flameeyes, hoea, pupeno, rodseth |
Priority: | NOR | ||
Version: | 1.0.0 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Amilcar do Carmo Lucas
2003-07-10 10:43:32 UTC
The project file is easy to fix, in "parts/appwizard/blah/script" replace the "install()" for the .kdevelop file with "installHTML()", that should escape the stuff correctly. As for the KAboutData: This is not so trivial, needs a special escape, for example "Ingo Kl This is not due to KAboutData. It's a bug in kdevelop(gideon). This bug has been annoying me for a long time since I started to use kdevelop CVS. When I use Chinese characters (I'm Chinese) as the author name in the appwizzard for whatever project, the author part in the .kdevelop file of the created project is in a mass. All the characters of my name is replaced by a series of numbers. They're something like: {„... I'v browsed some part of the source code and found: When appwizzard finishes, it calls a perl script in the project template and passes the author name as a parameter to the script. The script then generates the project by using the functions in the perl file "gideon.pm", which is in kdevelop/parts/appwizard/common of the source tree. In "gideon.pm", a function "customHTML()" is called and it translates all the none-letter characters (characters other than the 26 Latin characters) to the strange form mentioned above. These characters are saved to the .kdevelop file, a DOM file. When opening the project, kdevelop uses the DOM parser of QT to parse the .kdevelop file. When not specified, the DOM parser decodes with UTF-8, but the author name section isn't encoded with UTF-8. In fact, the strange number mentioned above is the decimal form of the aothor name characters without any encoding process. So, when I open the general project options dialog, my name is in a mass. As UTF-8 is a good solution to i18n issues, I think this bug can be fixed by: Translate the author name to UTF-8 before passing it to the perl script. This may also works for other sections such as email address or description of the project. Use "install()" function in "gideon.pm" instead of "installHTML()" in the script. I haven't got any kdevelop CVS account, so can anyone help me? Subject: Re: Author Name doesn't accept special characters I sympathise, Albert. When ARE we going to get this simple problem fixed? I reported it on 10 July and it is still at NEW status. It is ridiculous that a package originating in Germany cannot support its own language character set (e.g. Sure. If you use ENGLISH, everything is OK. This bus has existed for a time, but I managed to get some time recently to find what has happened. It is still in the latest CVS version. So, can anybody help us or give some comments? I think do the following may fix this bug: 1. At about line 433 in file kdevelop/parts/appwizard/appwizarddlg.cpp, replace "m_cmdline += KShellProcess::quote(author_edit->text());" with "m_cmdline += KShellProcess::quote(QString::fromLocal8Bit((author_edit->text()).utf8()));" (without the quotation marks). 2. In the function "installHTML" of kdevelop/parts/appwizard/common/kdevelop.pm, replace "customizeHTML" with "customize".(at about line 86) Subject: kdevelop CVS commit by aclu: Fix Bug 61031: Author Name doesn't accept special characters Convert Author name to UTF8 Patch idea submitted by: Albert Liu. Thank you. CCMAIL: 61031-done@bugs.kde.org CCMAIL: albert_lew2002@eyou.com CCMAIL: ianw@netspace.net.au M +1 -1 languages/ada/app_templates/adahello/script 1.4 M +1 -1 languages/bash/app_templates/bashhello/script 1.4 M +1 -1 languages/cpp/app_templates/chello/script 1.4 M +1 -1 languages/cpp/app_templates/chello_gba/script 1.4 M +1 -1 languages/cpp/app_templates/cpphello/script 1.3 M +1 -1 languages/cpp/app_templates/cppsdlhello/script 1.3 M +2 -2 languages/cpp/app_templates/generichello/script 1.3 M +1 -1 languages/cpp/app_templates/gnomeapp/script 1.3 M +1 -1 languages/cpp/app_templates/kapp/script 1.3 M +1 -1 languages/cpp/app_templates/kateplugin/script 1.3 M +1 -1 languages/cpp/app_templates/kdedcop/script 1.3 M +1 -1 languages/cpp/app_templates/kdevlang/script 1.3 M +1 -1 languages/cpp/app_templates/kdevpart/script 1.3 M +1 -1 languages/cpp/app_templates/kdevpart2/script 1.3 M +1 -1 languages/cpp/app_templates/khello/script 1.3 M +1 -1 languages/cpp/app_templates/kioslave/script 1.3 M +1 -1 languages/cpp/app_templates/kmod/script 1.3 M +1 -1 languages/cpp/app_templates/kpartapp/script 1.3 M +1 -1 languages/cpp/app_templates/noatunui/script 1.3 M +1 -1 languages/cpp/app_templates/noatunvisual/script 1.3 M +1 -1 languages/cpp/app_templates/qmakeapp/script 1.3 M +1 -1 languages/cpp/app_templates/qmakesimple/script 1.3 M +1 -1 languages/cpp/app_templates/qtopiaapp/script 1.3 M +1 -1 languages/cpp/app_templates/wxhello/script 1.3 M +1 -1 languages/fortran/app_templates/fortranhello/script 1.3 M +1 -1 languages/haskell/app_templates/haskellhello/script 1.3 M +1 -1 languages/java/app_templates/kappjava/script 1.3 M +1 -1 languages/java/app_templates/superwaba/script 1.3 M +1 -1 languages/pascal/app_templates/fpcgtk/script 1.3 M +1 -1 languages/pascal/app_templates/fpchello/script 1.3 M +1 -1 languages/pascal/app_templates/fpcsharedlib/script 1.3 M +1 -1 languages/pascal/app_templates/pascalhello/script 1.3 M +1 -1 languages/perl/app_templates/perlhello/script 1.3 M +1 -1 languages/php/app_templates/phphello/script 1.3 M +1 -1 languages/python/app_templates/pyqt/script 1.3 M +1 -1 languages/python/app_templates/pythonhello/script 1.3 M +1 -1 languages/ruby/app_templates/rubyhello/script 1.3 M +1 -1 languages/sql/app_templates/sqlsimple/script 1.2 M +1 -1 parts/appwizard/appwizarddlg.cpp 1.57 This problem is not resolved yet, it still doesn't read the "&" char for example. kdevelop version 3.0.3 Yes, jeroen, you're pretty right here. I'm reopening this now. The "&" Problem is true for the 3.0.x series of kdevelop. & needs to be stored as & into the .kdevelop file. Maybe Amilcar (or even someone else) wants to fix this for the 3.0.x release series. However, for kdevelop 3.1.x series the complete bug is valid again (due to appwizard rewrite) Closing it again now, because fixed in HEAD. HEAD behaves like: - replace "<", ">" and "&" with xml entities (<, > and &) - leave every other thing as it is, because we store utf-8 and it should be pretty safe to have i.e. "รค" (ä) in an utf-8 file. - "]]>" which is also not allowed in XML does not get translated, but i assume, that the underlying QDomDocument will do that if neccessary. However, i consider this a rare bordercase ( which is critical only if one embeds <[CDATA[-TAG-containing-xml into xml - what we do not do ). The problem for KDevelop 3.0.x is still present. *** Bug 81006 has been marked as a duplicate of this bug. *** *** Bug 77721 has been marked as a duplicate of this bug. *** *** Bug 73579 has been marked as a duplicate of this bug. *** *** Bug 85458 has been marked as a duplicate of this bug. *** *** Bug 86773 has been marked as a duplicate of this bug. *** |