freenode/#clim - IRC Chatlog
Search
19:00:55
jackdaniel
we probably should add history after 2001 to the "development history" chapter in "auxiliary material" part of our manual
19:02:44
jackdaniel
we could, but I'd rather want someone review it first (i.e to see if there are no lingering obsolete parts)
19:03:21
jackdaniel
also "Using views' Part of the usedr manual is written in the most confusing manner I could imagine
19:09:07
scymtym
i agree. and as i said to krwq, the incremental redisplay section may be in the wrong place given that it is an advanced topic and relatively rarely used
19:09:32
scymtym
i'm asking because the pdf version is available at common-lisp.net, but not the HTML version
19:18:02
jackdaniel
I don't have opinion on that, we may put html version (it is trivial, we use coleslaw to generate the website)
19:25:32
scymtym
if we don't want to remove the pdf version before revising it, i don't see why we shouldn't publish the HTML version
19:26:23
scymtym
i think having it, even if it isn't perfect, is better than not having it. and the HTML version should make it easier to point people to specific sections, functions, entries, etc.
19:32:43
scymtym
btw, the broadway story continues. i mentioned that the canvas-based approach was actually the obsolete one from gtk's perspective, so i thought i wouldn't implement it. but i went back on that decision and implemented a hybrid approach combining both. the canvas-based approach basically has a poor person's video codec with run-length encoding, delta encoding and block references. it seems completely superior for raster (as opposed to
19:41:34
scymtym
and i came up with a (maybe stupid idea) for handling double-buffering and thread synchronization in the broadway backend: when the server wants to send a "frame" (in the screen-content sense, not CLIM sense) to the client, say after dispatching some mouse events, it enqueues a GET-MIRRORS-PIXELS event carrying a callback onto the top-level pane's event queue. when the pane gets to processing the event, it copies its pixel data (could
19:41:34
scymtym
swap buffers here) and calls a callback in the event with that data. in the callback, the server receives the pixel data and puts it onto its own outgoing queue to be send to the client
22:52:19
frgo
Hello all: I am still trying to run McCLIM on AllegroCL 10.1. I am now using CLX from sharplispers bit now I get:
22:52:27
frgo
-adobe-helvetica-medium-r-normal--24-240-75-75-p-130-iso8859-1 host.docker.internal:0 10485785>
6:25:13
beach
loke: You know a lot about Truetype fonts, right? I am trying to understand how to control the scaling and rendering process, in that I am trying to influence how glyphs are positioned in the pixel grid.
6:25:17
beach
I tried to draw some text using fractional coordinates, but the rendering looks the same as if I use integral coordinates, which I take to mean that the rendering is cached, and the coordinates are rounded.
6:25:27
beach
So for example, I would like to figure out how to take the oval shape representing a notehead, and make sure that the left and right edges are aligned with the pixel grid, presumably using perhaps a combination of scaling parameters (size and relative position) and drawing parameters (fractional coordinates).
6:25:28
beach
I can settle for scaling and relative position parameters and always use integer coordinates for drawing.
6:26:06
beach
I said "loke" but answers from anyone else having more information would be appreciated of course.
6:28:08
beach
I suppose this subject is related to "hinting", which I feel a bit queasy about, because whenever it is discussed, an environment with a static programming language, so they use a bytecode interpreted language for hinting.