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

List:       wine-devel
Subject:    Re: Support for dead keys
From:       "Dmitry Timoshkov" <dmitry () sloboda ! ru>
Date:       2001-01-25 4:59:59
[Download RAW message or body]

Joao clemente <jpcl@oninet.pt> wrote:

...
>: 2. There are two approaches in implementing support for DK:
>: a. Do all the character composing in Wine itself, completely ignoring X.
>
>You mean, having to write something like those tables that exist to handle
>the keyboard?

Not at all. Those tables already exist and widely used in Wine.

>I really don't approve that (I still haven't got why can't wine use the X11
>keys).
>I think that using this aproach means having more trouble, having more
>source code, and depending on a lot of external help to get things to work
>with every keyboard that has deadkeys... You just don't know by yourself the
>DK that exist spread all over the world!

Really all standard compositing pairs (defined by Unicode) will work. Any
user-defined custom DKs will not. As far as I understand there is a possibility
to define any character sequence and assign it to some DK.

>: b. Delegate all the character composing tasks to Xlib. This will allow the
>user
>: to have his/her familiar environment, but will lead to some cases, when
>
>I like this one better...
>I think that wine will need less source code to work, and one only needs to
>have X11 configured properly so that he has all keys working right. That way
>is ONE place do get the keyboard to work (at X11 keyb config), ONE less
>place to worry about maintenance of wine...

On the one hand you are right. Having Xlib to do all DK composition is an easy
way to go. But there are (at least in theory) another drivers. Having DK support
in Wine itself will simplify creating those drivers, assuming that new driver
should not worry about character composing, only deliver keystrokes.
But such an internal support for DKs in Wine core should not affect any driver
at all: driver just will never say "I have DK for processing", it just will
silently process it itself.

>In other words, I think this is more "wine developer friendly" and "wine
>user friendly"

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