freenode/#clim - IRC Chatlog
Search
4:09:02
loke
Right now the actualy rendering function doewsn't return anything. That means that the calling code needs to first render the text, and then call the string-text-extents function to determine where to place the cursor afterwards. There issue is that drawing the string already computed this, and performing this measurement requires you to perform all the rendering (except not actually drawing it to the screen), meaning that you end up
4:11:28
loke
jack_rabbit: My proposed change is to have the render function return the same values as string-text-extents does, so the caller can reuse it.
4:12:00
loke
I guess the functionc an be defined such that if it return NIL, the caller will call the string-extends function instead
4:13:37
jack_rabbit
That makes sense. I mean a change from an API function that returns NIL to one that returns *something* is probably the easiest, least dangerous API change one can make.
4:14:49
jack_rabbit
mmm Is it documented to return something, or is it just some coincidental object?
4:18:23
loke
I think what happens is that it calls the medium-text-extents when creating the output record.
4:19:48
loke
I have added a new &KEY parameter to DRAW-GLYPHS, it's :DIRECTION parameter that can be set to :LTR or :RTL
4:23:29
loke
I can create an :AROUND method on CLIM-CLX::FONT-DRAW-GLYPHS that splits the string into these runs, and then renders each one individually.
4:23:57
loke
This works, but since my splitting function isn't very fast, I'm not sure I want to add it as a standard part of CLIM
4:24:27
loke
I guess I could spend time making it fast. It's a naïve port of an Emacs Lisp function:
4:24:37
jack_rabbit
Right. Is there any simple way to specialize FONT-DRAW-GLYPHS on the freetype renderer?
4:25:42
loke
FONT-DRAW-GLYPHS is specialised on the font object. There is a FREETYPE-FONT object that represents this.
4:26:00
loke
here's that code: https://github.com/lokedhs/McCLIM/blob/freetype2/Extensions/fonts/freetype.lisp#L243
4:26:58
jack_rabbit
That's probably ok, I would think, as long as the direction function isn't *TOO* slow.
4:29:01
loke
This is the correct one: https://github.com/lokedhs/clim-test/blob/master/freetype-test.lisp#L91
4:32:45
loke
THe thing is, this stuff is only needed if you want to render RTL text, which is actually quite rare. And there are other problems with CLIM and RTL. For example, I'm not sure what the text editor widgets have to say about it :-)
4:34:28
jack_rabbit
You could always make a defvar to flip on and off for people who want to render RTL.
4:35:11
loke
It's just this :AROUND method right now, and I'm considering putting it as an :AROUND on a higher level, to make the RTL functionality available regardless of font renderer in use
4:35:50
loke
That said, I really don't like :AROUND methods, and I'd rather rename the generic function and have RENDER-GLYPHS be a normal function that does everything and calls into the (now renamed) generic function.
4:39:07
loke
Well, it just seems lazy. Also, If someone else wants to add even more specialised functionality they can't add another :AROUND method to do that becasue this one already exists.
4:42:17
loke
They stack if they have different qualifiers. So I can stack (FOO (X INTEGER)) with (FOO (X STRING)) etc... but I can't add another with the same parameter types.
4:48:49
jack_rabbit
hmmmm. Unrelated question. Have you noticed the text selection for the current git version of McCLIM makes the text disappear instead of highlighting it?
5:07:39
jack_rabbit
Seems related to PR #456. I filed an issue. https://github.com/robert-strandh/McCLIM/issues/470
5:12:10
makomo
loke: an unrelated question. how come in DIMENSION-BIND you use ",@(if ... `((...)))" instead of ",(if ... `())"?
5:15:51
loke
No. because ,(if xx nil) results in NIL, and then you'll see a form like this: (LET ((X ...) NIL NIL) ...)
10:33:04
jackdaniel
prompted by your bug report I want to write a blueprint how it should look like and create a bounty on implementing it
10:33:32
jackdaniel
right now cut-and-paste-mixin simply hijacks dispatch-event and handle-repaint waht is an extreme hack
10:35:51
jackdaniel
the problem is that it fails to draw a background (but it draws foreground correctly, which happens to be white)
10:40:26
loke
jackdaniel: If you are going to redesign the text selection, we should really take RTL text into account
10:40:54
loke
Remember that if you have one run of LTR followed by a run of RTL the selection will not be continuous on the screen.
10:42:44
jackdaniel
I'd like to be able to test (and witness the difference), then we can make it a requirement to support that
10:43:03
jackdaniel
without anything to test on it would be futile to require something you can verify if it works
10:44:25
loke
Since if you have a string "foo123456abcdef" (where 123456 is a sequence of arabic letters), they will be rendered on the screen as "foo654321abcdef". So if you select from "oo" to "4", then the selection should be drawn on top of the "oo" and the letters "4321". I.e. there will be a gap in the visual representation of the selection.
10:44:59
loke
I'm sure you've seen this behaviour if you've gone to a web page that contains arabic.
10:46:08
loke
Go here for example and try doign a text selection that covers both english and arabic text at the same time: https://blogs.transparent.com/arabic/20-common-verbs-in-arabic/
10:46:26
jackdaniel
as far as I know arabic output doesn't work now on McCLIM, so there is no way to test the actual implementation of such rtl selection
10:47:42
jackdaniel
I won't review such PR before Monday (still in Spain), just dropped in to comment on text-selection bug
10:51:14
loke
This is the current version. Is this better? https://photos.app.goo.gl/qU4Nmc0vcPKdn3CG2
10:51:53
loke
The bounding box issue with mixed RTL and LTR text is one of the problems I want to fix before I cerate a pull request.
10:52:39
loke
Yeah. The old version had a problem in that I didn't detect the language properly so it used the Latin font shaper instead of the arabic one.
10:54:15
loke
jackdaniel: if you want to look at my work, it's in this branch: https://github.com/lokedhs/McCLIM/tree/freetype2
10:56:22
loke
There are some issues with the bounding boxes, but other than that it's pretty stable.
10:56:59
jackdaniel
ACTION goes to spend some time on Marbella's beach and read a (non technical!) book
11:05:49
smokeink
loke: https://pastebin.com/VxVsGBtZ I've got the ime thing working (in C, so far )
11:07:12
smokeink
at least that's my guess: I think gtk and qt based IMEs also use XIM behind the hood
11:09:22
smokeink
now the only problem is that I can't figure out how to setup the fonts so that XwcDrawString doesn't draw gibberish
11:14:56
smokeink
the prog above just draws the characters that one inputs. The English chars are displayed fine, but the non-English ones are not- I still have to see why it doesn't choose the proper font