[Xorg] [PATCH] Cached XIM data

[Lubos Lunak]

On Monday 09 of August 2004 21:30, Jim Gettys wrote:
> Thanks Lubos, for the data...  You are confirming what we were
> already suspecting, from a different direction (just the size
> information).
>
> >  There are several things I'm unsure about the patch:
> >
> > - It uses things like mmap() or posix_memalign() which could cause
> > trouble to all those crappy Nulix platforms out there. It should be just
> > a matter of few #ifdef's, but I don't know how you do checks for such
> > features.
>
> On platforms without mmap support (are there any around we still care
> about?), you'd just open and read the data...

 Of course. What I meant was that I didn't know how to write configure checks 
equivalents for the make World stuff X currently uses.

> > - I'm not sure where to store the cache file. KDE has special place for
> > cache files, but I don't know how to do that with non-KDE apps. The patch
> > now stores it in /tmp/xim, the /var/X11R6/cache/ or /var/cache are
> > Linux-ism AFAIK. Moreover this should be probably saved per-user for
> > paranoia reasons, or shouldn't it?
>
> Computing this once at build time seems more sensible to me.

 Hmm ... yes, probably. It just started as a proof of concept hack when I was 
examining the problem and possible solutions. I wanted to spare me diving 
into XIM and finding out how much of it would need rewritting, and since this 
patch doesn't change the internal representation format, other parts of XIM 
didn't need to be touched. Somehow it ended up as a normal usable solution. 
I'm afraid I don't plan becoming XIM hacker in order to offer a better patch.

>
> But is there any reason why these files are so gigantic?

 I guess the utf8 Compose file simply includes all possible compositions, be 
it Slavic language or Japanese. E.g. the iso8859-2 file is only 5% of the 
utf8 size, and it would do for me too. Moreover there are e.g. 5 ways to 
enter aacute, the normal one with dead acute+a, plus 4 more using the multi 
key (which I even don't know what is).

> And whether 
> there are other solutions?  Is there someway we can leverage libc
> functions that may not have existed when the Xlib implementation was
> (mis)designed?
>
> Does anyone really understand the input method stuff properly?
>
> (we were just discussing this area today on the architecture call,
> and what to do about it.  Thanks for the ammunition to go after it).
>                               Regards,
>                                     - Jim

 How about the second smaller patch? Is that one ok (so that it doesn't get 
lost in the discussion)?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/