[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    KDE2 actually doesn't support Unicode
From:       Wolfram Diestel <wolfram () steloj ! de>
Date:       1999-12-20 20:55:23
[Download RAW message or body]

Hello,

In several press releases I read, that KDE2 will
support Unicode. Thats what I would expect as a user from this:

  In every application, which handles text I
  can mix arbitrary languages, can save such
  multilanguage documents and reread them.

Looking on KDE 1.89 the only difference to
KDE1 seems to be, that internal Qt classes
like QString use Unicode. But all that comes
from outside goes through a default codec "CodecForLocale"
and all that comes out goes through this
codec ones more. For displaying texts the codec
for the charset of the font is used, thats ok.

This means, that in KDE 1.89 I'm more
limited than in KDE1. Why? In KDE1 I could
read arbitrary 8-bit documents, I just
had to use a convenient font for it.
In KDE 1.89 I'm bound to the charset,
that Qt thinks best for the language
given in the LANG environment variable.
As a german the only way to see a
russian text correctly is "LANG=ru kedit",
otherwise it will be converted to
Latin-1 (or to Latin-3 for me with LANG=eo),
what doesn't look very fancy.

To overcome this limitation, I think we
have to flee in forward direction. Everywhere, where
it makes sence, we should *actually* support
Unicode. The essential points are the following:

1. It should be possible to save and read documents
   as UTF-8/UCS-2. This affects applications like
   KEdit, KWrite, KWord, KSpread, but graffic and
   other applications too. Think about a multilanguage
   poster, presentation, email a.s.o.

2. All interapplication protocols dealing with text
   should understand UTF-8 and/or UCS-2 (clipboard, drag&drop, MIME...).
   May be this works at the moment, if there are used Qt classes,
   otherwise may be not.
   Some Internet applications are already UTF-8 aware, thats ok.

3. There has to be an abilty to input characters of different
   languages with the keyboard. In KDE 1.x I could use
   Kikbd for this. This doesn't work now in KDE 1.89,
   because Qt converts any character coming from the
   XServer to Unicode with this "CodecForLocale", so
   I limited to my default language settings ones more.
   (An input method by a graffical character table is useable
   only for some special character but not for different
   languages).

                    * * *

I think, if the important text applications KEdit,
KWrite, KWord, KMail could import and export UTF-8 and
I had a facility for putting Unicode characters with
the keyboard into a document, this should be enough
for KDE 2.0. More Unicode support could follow in small steps
in the releases after 2.0

Trying to note, what should be done for such a minimal support:

a) For fileimport/-export most suitable in my opinion
would be an option in the file dialogs. If the applications
uses the Qt standard classes for saving and reading files,
such as QTextStream, or the derived classes such as KFile,
it's enough to change the codec, when this option is set.
(e.g. if (saveAsUTF8) file.textStream()->setCodec(
 QTextCodec::codecForName("utf-8")); )
If the standard classes aren't used, it will be some more work
for the developper.

b) In order to input characters with the keyboard,
first we need a Qt API function to change the variable
application_x11.cpp:input_mapper. The bigger task
is an application, which makes it possible to create
keyboard layouts and to change the keyboard layout
while typing a text.

I don't know, if we have to write this from the scratch
or if we could modify Kikbd, which now manipulates the
XServer, not the manner Qt interpretes keyevents.

Ok, it was easy for me to write down the wishes from 
a KDE users point of view. As a KDE developer it
may be difficult not to forget that some Unicode
stuff while learning to deal with this many new
concepts like Corba, DCOP, XML...
For Windows NT it took 4 years to bring the internal
Unicode implementation to the user interface.
I think we should do this in KDE within the next 
4 months :)

  Wolfram.

--
Wolfram Diestel <wolfram@steloj.de> http://www.steloj.de/

[prev in list] [next in list] [prev in thread] [next in thread]