freenode/#clim - IRC Chatlog
Search
4:09:33
loke
What is the “correct” way to send asynchronous messages to a CLIM thread? (I.e. I have a UI that needs to be updated in real-time based on some external event in a different thread)
7:25:44
jackdaniel
loke: there is no correct way at the moment, both event-queue and stream access are prone to races and/or corruption. you must do it from the same thread as the event loop
7:28:46
jackdaniel
I even have an idea how to mitigate the issue: in case of queue we need a mailbox which is thread safe (some implementations have it, but implementation is not super hard), in case of stream we need around methods which check for thread affinity (if foreign thread, then operation is enqueued)
7:30:57
jackdaniel
but prerequisite to meddle with multithreading is fixing single-threaded run (there is also ticket for that)
7:31:11
jackdaniel
before we make things more complicated we need to assure it works just fine for the simplest of cases
7:32:49
loke
I looked at some older code I wrote, and it seems as though it might be a correct way of doing it
7:34:00
loke
simply call EXECUTE-FRAME-COMMAND on the appropriate frame. There is code in there that, if the current frame is not the same frame, then it will create an event that will execute the command later. The event is then inserted in the event queue, and it does take a lock while doing so, which suggests to me that they thought about this.
7:36:41
jackdaniel
1) this is about commands; 2) event-queue-append is not thread safe, so this solution is erroneous; 3) in principle this is a solution which depends on the event queue being mailbox (as I suggested, though this assumption is not fulfilled)
7:38:17
jackdaniel
no, with with-lock-held it is not efficient, but correct, there is no need to worry
7:38:48
loke
Currently, my need for this has to do with the Maxima client being able to tell the documentation frame to display a specific page of documentation.
7:39:14
loke
But in the longer run, I want to use this mechanism to tell a frame that the “global input context” has changed.
7:44:24
loke
jackdaniel: The bug in question mentions that genera had a concept called the “active application”
7:45:02
jackdaniel
maybe clicking window decoraction (like you have active window with keyboard input)
7:46:32
jackdaniel
why wouldn't it? also: what is the alternative approach? (please add it to the ticket)
7:47:19
jackdaniel
I find it very sane: only active frame is active for input (even if input comes from other frames), that has a direct analogy to how keyboard input works, even if it is a virtual keyboard
7:49:08
loke
Let's say you have windows A and B. I'm working in window A and it's waiting for a presentation of type X. I now click on such presentation in windows B. However, before the mouseclick is delivered to window B, the window manager has already selected window B, meaning that B will not know that application A was “active” before the click.
7:49:48
loke
And it depends on which window manager one uses, if the window is selected before events are delivered to it. If you configure “click to select”, then you can't click in an unselected window.
7:51:38
jackdaniel
we may maintain "activity" status on our own then. all frames must be in the same process anyway (for presentation-aware input). do you happen to have an alternative solution proposal?
7:52:34
loke
Well, the only one has been to consider a “global input context” that would be consulted along with the lcoal one. However, you raised some good points about that idea yesterday.
7:52:50
jackdaniel
last thing (half-jokingly): we may come up with our own window manager, we have blackbox and such ;-)
12:34:38
jackdaniel
scymtym: thank you, but congratulations are preliminary. I hope someone else will double check it (and merge)
12:36:01
jackdaniel
so the next step is to: create new bounties, write a post summarizing changes since the last release and pushing it out of the door
12:39:54
scymtym
jackdaniel: should i rebase the mousewheel changes now? or should i wait until you have more time? (i would really like to get those in - maybe just some parts if others turn out problematic)
12:40:24
jackdaniel
scymtym: please rebase it and I will take a look before doing abovementioned things
12:41:58
jackdaniel
scymtym: and after looking I'll either merge it or sketch a plan for a solution embracing whole system
12:42:19
jdz
jackdaniel: Probably because I'm running with (pushnew :mcclim-ffi-freetype *features*).
12:42:39
jdz
(#<CLIM-FREETYPE::FREETYPE-FONT FACE #<CLIM-FREETYPE::FREETYPE-FONT-FACE DejaVu Sans, Book> SIZE 14>
12:54:08
jackdaniel
scymtym: btw, you may check the performance with my small tweaks (wrt text-size/text-bounding-rectangle*)
12:55:22
scymtym
jackdaniel: yes, i will rebase my optimizations and see if they still apply/make sense
13:15:56
loke
jackdaniel: Did you make a change recently that moved/renamed FIND-REPLACEMENT-TEXT-STYLES?
13:19:08
jackdaniel
you've said you'll look into it when the branch is merged (or something in this spirit)
13:20:51
jackdaniel
font replacement text styles work fine locally without fixes spanning whole system
13:21:47
loke
You'd simply implement that method, and then things will just work. I've tried to write climaxima without dependency on Freetype explicitly.
13:23:04
jackdaniel
I don't remember details, if you had asked me when I've mentioned the change I'd be able to provide better input
13:24:33
jackdaniel
the gist of it is that font replacement requires only subclassing text style and handling it correctly at the renderer discretion, without core nor drei having a separate code for it. I've even benchmarked that and things are faster than they were before afair (with font repacement text style supplied)
13:27:51
loke
I did notice another, different, change ou made. CLIM-CLX::TEXT-STYLE-TO-X-FONT is no lonmger there
13:28:15
loke
I'm calling that directly in order to be able to get my hands on all return values from CLIM-CLX::FONT-TEXT-EXTENTS
13:29:39
jackdaniel
and to have a font from text style you go: (climb:text-style-to-font port text-style)
13:30:02
loke
Yeah. I did it as a workaround since CLIM didn't expose any way to get to the font metrics. Ideally I'd like to ask a "style" what the metrics are. Is such a call exposed?
13:30:49
jackdaniel
no (and there is no need), just call font-text-extents on result of the mentioned call
13:30:49
loke
jackdaniel: OK, sounds good. But I still have to call clim-clx::font-text-extents, right? It would be nice if there was a backend-independent way to get to these values.
13:32:15
loke
a font has a specific ascender and descender. Those are the "guidelines" so to speak. One can estimate them by taking the ascent and descent of the string "Ag", but it would be nicer to get the font-supplied value.
13:33:36
jackdaniel
there is text-style-ascent/descent, and for font there is climb:font-ascent/descent
13:34:23
loke
You explained the new design to me, I remember that. It's coming back to me now, but clearly I didn't actually understand all it then.
13:40:12
jackdaniel
loke: probably non-conforming usage: you need to pass :transform-glyphs if you want them transformed
13:45:03
jackdaniel
it has its own ticket, (nb: we've talked about that today; it is concurrent write to a recording stream - that leads to output record corruption)
13:48:50
loke
Hmm... output records now seem to exactly wrap the drawable part of text, rather than using the font-extents.
13:49:44
loke
I'm not against that idea in general, but now I have to rewrite a large part of the maths renderer ;-)
13:50:49
jackdaniel
there are two functions, text-size gives you general font metrics while text-bounding-rectangle gives you minimal one
13:51:16
jackdaniel
see text size demo to see the difference (preferably with truetype renderer which I know gets it right)
13:52:12
jackdaniel
see font-text-extents docstring and default methods for text-size and text-bounding-rectangle
13:57:34
loke
All my code completely depends on that the extents of the generated output record when drawing some are the font metrics and not the text itself
13:57:54
loke
I have hundreds of calls that measues very complex output records, whose sizes derive from this
13:58:31
loke
now I end up in a situation where sqrt(x) and sqrt(X) renders with different size sqrt-symbols, because X and x have different heights
13:59:57
loke
I guess I could construct an output record subclass that tracks the extended dimensions...
14:01:26
loke
Inline: yes, but with Maxima you don't. I have to make decisions how to render things.
14:03:41
loke
Inline: I tested in LaTeX just now, and I do note that sqtr(x)+sqrt(X) does give me different size sqrt symbols.
14:04:50
loke
and I have been measuring sizes of parentheses, and location of exponents and all sofrts of stuff
14:05:11
loke
there is a lot of manually fudged magic to get it right. Which is why climaxima requires specific fonts.
14:06:42
loke
The question, for example, is how many pixels above the top of the sqrt'ed equation should the sqrt-line be drawn?
14:10:34
loke
(that menas that the distance between the line and the numerator and denominators is 1/4 the height of the font.