freenode/#clim - IRC Chatlog
Search
1:21:35
smokeink
loke: for linux there are at least 3 popular IME frameworks: iBus, SCIM (Smart Common Input Method platform) and fcitx . All three of them are good and all three of them have their limitations/bugs
1:25:31
smokeink
that's for the graphics mode. For text console mode (framebuffer console actually) there's fbterm-ucimf which works well. There are a couple of others as well but I couldn't get them working. The console mode IME's are rarely used nowdays so we won't bother to integrate them with CLIM
1:27:00
smokeink
on Windows I'm not sure, it might be the case that the IMEs work by default when mcclim uses the native backend
1:57:13
loke
Now I have a problem... To get Harfbuzz to shape the fonts correctly, I have to set the language code prior to rendering.
1:57:52
loke
Arabic will be completely screwed up if I set anything but AR. But Elish doesn't look good unless I choose EN. I expect all other scripts to require similar behaviour.
1:58:27
loke
I guess I could look at the code points and choose a reasonable default based on the Unicode block, but that feels very ugly.
2:46:50
loke
it looks at a buffer (a line of text, basically) and guesses the parameters that I haven't supplied. In this case, it guesses the appropriate script parameter.
3:01:20
fittestbits
I ran into a code pattern today that I wanted to ask mcclim supporters about. It's near the bottom of Extensions/render/backend/port.lisp.
3:02:05
fittestbits
At top level in the file there's (let (<some hash tables>) <some function definitions using the local bindings> )
3:03:12
fittestbits
I had a problem I was trying to track down related to those hash tables, but there was no way to get access to them.
3:03:44
fittestbits
So, yes the data was encapsulated, but it seems like it was overly encapsulated.
3:05:31
fittestbits
The exact same code (almost) is at the bottom of xrender-fonts as well, I saw it in port.lisp.
3:06:12
fittestbits
And the key was a list created on the fly, so there was never a hit in the has table.
3:06:47
loke
Stuff like that (and other stupidities) was the reason I threw out all of xrender-fonts.lisp and started working on a brand new font engine.
3:06:59
fittestbits
I noticed that xrender-fonts was using equal for all of the hash tables - which lead me to the fix for port.lisp.
3:07:36
loke
Another “great” idea they had was to override the the font engine by adding an :AROUND method around some central functions so they could replace the rendering part.
3:10:30
loke
Guess what happened when I wanted to implement my own renderer? The code was never called... funny that.
3:19:40
fittestbits
froggey has a repository Iota which is an LLVM to common lisp transpiler. I don't know what the status of that is.
3:20:58
froggey
yeah, Iota converts C (or LLVM IR in general) to CL. it's more of a proof of concept than anything useful right now
3:21:39
froggey
with a bunch of work it could be used to interface with C libraries, but I haven't really thought about how to make that work
3:24:55
loke
Unless anyone is willing to spend a ridiculous amount of time replicating the functionality of Harfbuzz and Freetype in Lisp, the Iota seems to be the only reasonable approach.
3:26:56
fittestbits
So, without Harfbuzz and Freetype, we'd have to stay with the existing font code on mezzano?
3:27:50
froggey
it's portable too, it doesn't use anything mezzano specific. but I'm not sure why any other implementation would use it as they all have FFI support
3:28:54
loke
There is a TTF implementation (is it what Mezzano uses today?) which is what the old McCLIM implenmentation uses.
3:32:54
fittestbits
It seems to be working OK for what I've been doing with it - clim-demo and clim-listener.
3:33:34
fittestbits
But, I've been following the stuff you've been talking about and it would be nice to have all the features.
6:25:13
jackdaniel
something what piggybacks on ffi won't become default, so the old rendering code will still be there and it will be default (hopefully it will benefit from loke's refactor too)
6:26:38
jackdaniel
unrelated note: it might be worth considering factoring renderer into a separate library
6:53:11
loke
jackdaniel: I don't know. I've mostly left the old ttf code that way it is, and just adapted it a bit to conform to the new interface between clx and the font renderer
8:10:39
smokeink
loke: I spent many hours trying to make iBus work on my slackware , but my conclusion is that iBus is crapware, it has many idiotic dependencies and it's full of bugs . In the end I managed to compile and install it but it just doesn't want to work with any Chinese table, no matter it's pinyin or something else. Japanese doesn't work either. Russian and English and the other non-table European languages work fine though
8:16:14
smokeink
the crappiest thing I've ever seen in my life is python. iBus depends on python... and all these chinese tables which should just be a single file or something similar, they also depend on obscure python libs such as pyzy - which fail to run because python is split into ver2 and ver3, but both ver2 and 3 (I think) are also split into ucsc4 and ucsc_something else, and they're incompatible as far as parsing unicode is concerned
8:22:14
smokeink
on my system that pyzy fails to run because re.compile(u'[\U00010000-\U0001FFFF]') doesn't work in python2, it works only in python3 . But the lib is written in python2. "It's because Python (for reasons I don't care to look into) made a decision at some point (I guess it made sense at the time?) to have two kinds of unicode handling. This resulted in "narrow" and "wide" builds of Python in the 2.7 series. In Py3, this is distinction is removed."
8:23:00
smokeink
and if I choose to compile the other python2 build, the wide_ version, then all the other software that I have installed and that uses python will break