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.