freenode/#clim - IRC Chatlog
Search
10:25:44
jackdaniel
general question about tracking-pointer: assume we have nested presentations: `board' and `field', when the context type is (or board field) and we move mouse over field (which is nested in board)
10:26:22
jackdaniel
:presentation clause should: a) be called only on the innermost presentation; b) should be called on all presentations (in which order) which are under the pointer and match the context type
10:35:55
jackdaniel
ck_: you've mentioned that :finish-on-release nil is not very useful, after some thought put into it I think I disagree
10:36:33
jackdaniel
while for two objects (drag A->B) finish-on-release makes more sense the alternative is better for dragging A->B->C->D
10:38:03
jackdaniel
while we do not support dnd-translators accepting more than one destination object I can imagine such translator
10:40:29
jackdaniel
also tester function for dnd tranaslator is pretty much useless for some cases without using climi::*dragged-object* undocumented variable
10:40:59
jackdaniel
because object is is bound to a dragged object and to destination object depending on pointer position
10:42:19
jackdaniel
probably we should fix it by having extended arglist for it (it begs for a macro where tester and translator have the same arglist)
10:45:23
scymtym
jackdaniel: i remember added a similar extension for a certain drag-and-drop operation in clouseau that i couldn't implement without it. let me see if i can find it
10:48:55
scymtym
probably this: https://github.com/scymtym/McCLIM/commit/07632fb7664a3fde874dd186e6883e951c07e73e
10:52:58
frgo
jackdaniel: I am using clx from sharplispers. T did not explicitly load any other package.
10:56:47
jackdaniel
scymtym: from a consistency point of view tester should be called with object bound to a dragged object (and presentation) and there should be extra arguments destination-object and destination-presentation (like for dnd-translator body)
10:57:30
scymtym
jackdaniel: sure. i'm not attached to particular names as long as the information is available
11:03:27
jackdaniel
this is certainly error from McCLIM (not CLX), for some reason it picks up x11 fonts (instead of ttf ones)
11:05:38
jackdaniel
frgo: in file Extensions/fonts/xrender-fonts.lisp function climb:text-style-to-font remove (call-next-method) to error right away and try again with that
11:08:14
scymtym
could this be another instance of https://github.com/McCLIM/McCLIM/issues/705 ? in that case, installing the font as described in the issue is a workaround
11:22:45
ck_
jackdaniel: while you're free-floating -- I put a pull request to CLX wrt. McCLIM/#637. I believe it is the correct place for the fix, but of course the buffering might just as well be done inside mcclim. You said the issue was 'important' so I'm pinging you with this here.
11:24:43
ck_
scymtym: I thought of that, and I don't think so, because from cursory looks to the xlib documentation, it is set at inception
11:24:48
jackdaniel
I'n 6m I'm taking over the little one so I won't manage to take a close look right away
11:25:26
scymtym
ck_: could you add a comment to that effect so someone reading the code doesn't have to worry?
11:26:05
ck_
scymtym: I will as soon as you (or anybody else) confirm my interpretation. I'm not very sure-footed with X11
11:27:52
ck_
ah, /that/ thing. Well, ok ... sure, if you think that's better. I personally don't think it reads too bad with the (or..)
11:30:14
scymtym
ck_: an unrelated nitpick: the closing paren on its own line was probably due to the end-of-line comment in line 362; adding another line allows having the closing paren on the same line
11:30:15
jackdaniel
hm, maybe nothing, I don't have strong opinion on that, but (or foo (setf foo …)) is a boilerplate. probably it is not justified for this one place
11:31:53
ck_
scymtym: sure. I'll hold back on the aesthetics until the functional part is greenlit, okay?
11:45:09
scymtym
ck_: it seems the only possibility would be https://tronche.com/gui/x/xlib/window/attributes/#XSetWindowAttributes.html , but it doesn't affect the depth as far as i can tell. so we may be in the clear
11:47:15
ck_
Thank you for checking. I tried to run the clx tests, but didn't get very far; I believe the documentation has diverged a bit from the code state
11:48:24
ck_
for example, in CLX/README.md, it tells me to load clx/demo/menu and then run xlib::just-say-lisp. But I can't find a function of that name in the sources
11:49:16
ck_
(it is "defined" in clx.texinfo, but I don't think that's the point of the exercise, is it?)
11:49:54
ck_
I would, but I'm late, I'm late for a very important date. Also I don't know what color cupcake I'd need to eat.
12:11:18
scymtym
jackdaniel: i played with ideas for the debugger: https://techfak.de/~jmoringe/debugger-ideas.png . what do you think?
12:24:34
ck_
I inspected some things this morning. Clouseau is great! Maybe I'll comment some matter-of-taste suggestions sometime.
12:29:11
frgo
jackdaniel: it turned out that sharplisper's CLX needed quite some tweeking to run on AllegroCL 10.1. I now get:
12:30:29
scymtym
ck_: i would be happy to hear them. i also have a few more improvements of my own planned
12:30:56
beach
If I draw a filled rectangle with coordinates that are not integers, should I get anti-aliasing? When I draw with 10 10 11.5 20 or something like that, I get a 2 pixel wide rectangle.
12:32:09
ck_
beach: there's a comment to that effect in graphics.lisp or medium.lisp. Short answer: no, no anti-aliasing -- but rounding.
12:32:18
frgo
Just as a side note: I am running AllegroCL in a docker container and am using Xquartz on macOX as the X11 Server
12:37:35
scymtym
i believe the clx-fb backend does provide anti-aliased rendering. it is slow, though
12:44:14
loke
beach: Your intuition is correct. The rasteriser only renders a glyph with pixel resolution.
12:45:50
loke
beach: Now, you are also right that hinting is one of the things that makes non-integral positions problematic.
12:47:19
loke
The Xrender backend could indeed copy glyph to a non-integral position. However, you really don't want that since Xrender simply copies a pre-rendered glyph (a bitmap, realy) to the screen. And if you specify the coordinate using subpixel coordinates, you'll end up with image-based antialiasing applied. This will not look pretty.
12:47:47
loke
For that reason, the font renderers (both TTF and FT) rounds the coordinate to the nearest integer position before drawing the stirng.
12:49:22
loke
The rasteriser generates an iage with an alpha-map that Xrender uses when blitting the glyph to the screen.
12:50:19
loke
Good would be if there was not rasterisation step, but that would be horrendously slow.
12:50:29
beach
The font I am using is a bit strange. A notehead, which is symmetric has its left side pixel aligned always, but the right side never seems to fit the grid for any integer point size.
12:51:24
beach
... so I would have liked for some hinting to be applied so that both sides are pixel aligned.
12:51:53
loke
The OSX renderer has three copies of each cached glyph (so a horizontal subpixel positioning of 1/3). But in the recent version of OSX they rolled that back and removed subpixel sampling, citing problems with the glyph cache as reasons, and arguing that high-dpi displays make it unnecessary
12:52:29
loke
beach: Hinting is part of the font. If it's your font, you can manually create such hints.
12:52:48
beach
Yes, and Fontforge seems to allow for it, but the manual says that hinting is then ignored by most renders.
12:54:35
beach
I use the default in McCLIM, but the font does not seem to have any hinting information in it.
12:55:06
loke
You might want to see how the FT renderer does it anyway. It uses subpixel sampling which may give you better result/
12:56:53
beach
I am confused. How is subpixel sampling related to hinting? And by "subpixel sampling" do you just mean a technique for anti-aliasing, or do you mean the equivalent of "subpixel anti-aliasing" where colors are used?
12:58:57
beach
I definitely don't want that. It looks awful on some of my monitors, and it would be impossible to use it with music rendering.
13:01:44
beach
Gray-scale anti-aliasing is fine. But I also think I need to align the left and right side of noteheads with the pixel grid so that I can fit stems that are not blurred with those noteheads.
13:03:31
beach
Also, I remember reading that the bytecodes used for TTF hinting have some copyright or patent problems.
13:08:17
beach
When Fontforge renders a glyph, two parameters are used, the resolution and the point size.
13:08:52
beach
But when I create a text style from a font, can I also give the resolution? Or is that some global information?
13:21:19
jackdaniel
scymtym: I think that it would be better to have inspect and source commands on parameters with dedicated panes for both source and inspector
13:40:15
ck_
I think their response would probably be "you can pry these from my cold dead furlongs (or fourty rods)"
13:49:04
scymtym
jackdaniel: ok. in any case, to make any of this work, i think we would need something like pane-local command tables
13:55:10
beach
I'm going to give up these Clovetree experiments for now, because they are extremely frustrating. However, when I pick up Clovetree one day, I will not make the same mistake that I made for Gsharp, i.e. try to handle all the rendering details from the start.
13:55:21
beach
I will concentrate on the mental model of the score and on the user interactions. Initially, I will just use this font as it is, and try to fit stems on noteheads as well as possible.
13:55:22
beach
Improved rendering can come later, and may not even be required on a 4K monitor, or something with the same resolution.
13:57:46
beach
The font software I defined for Gsharp was in many respects superior to what TTF can do, but I neither have the time, the skill, the patience, nor the right software tools to create my own font using that technique.
15:13:00
loke
beach: resolution and point size are different. If you double the resolution as well as the point size, the result is different.
15:15:50
loke
beach: Here's an example shoing how doubling the point size gives you a different resolut compared to scaling the text: https://photos.app.goo.gl/SSPv7JiLr7dZ1QUo6
15:22:31
beach
I know that they are different. I am just saying that they both influence the result.
15:24:05
loke
Yes, but relying on it to manually duge it to the correct dimensions feels quite hackish
15:25:22
beach
Not that I know why those two results are different, but I assume it has to do with hinting or something like that.
15:25:53
beach
I know that Knuth in the Metafont book spent a lot of time explaining why scaling and changing the point size is different.
15:27:17
beach
I was talking about the fact that two parameters are required in Fontforge in order to render a glyph, namely device resolution (in dpi) and point size.
15:27:46
beach
Presumably, if the point size is the same, the same shape should be rendered, except with a different number of pixels.
16:04:46
loke
beach: There are cases where you'd want the low-resolution shape, scaled up. But I'd say they're pretty rare, an din almost all cases you want to have the scale at 1.0 and just use point size to adjust size, so that the you get th ebest looking shape.
18:26:19
scymtym
if already had the input focus thing, the command processor would look in the pane command table of the pane that has the input focus. each pane command table would have to be treated as if it had :inherit-from <frame-command-table>
18:27:59
scymtym
the debugger illustrate the problem: if, for example, you add an interactor, you can't type an "e" in the interactor because that gesture is bound to a command. it would make more sense if the gesture would only behave this way if the debugger pane has the input focus
18:33:18
jackdaniel
I wonder if a similar effect couldn't be achieved with conditional-commands (here is such module in Extensions/ directory)
18:34:01
jackdaniel
I don't know the module well, but afair it was made to make commands enabled only under certain conditions (I can imagine checking input-focus being one such condition)
18:34:56
jackdaniel
that would probably apply only to translators, because frames are responsible for reading commands (i.e there is no read-command loop associated with a particular stream)