freenode/#clim - IRC Chatlog
Search
8:32:26
loke
The orange thing is a chain tensioner: https://ep1.pinkbike.org/p3pb2102474/p3pb2102474.jpg
9:13:06
loke
jackdaniel: I'm wondering if perhaps the CLIM code that reconfigures a window _always_ performs both an XMoveWindow and an XResizeWindow together, even when the intent is to only do a resize.
9:18:53
loke
jackdaniel: Hmm... I'm looking at the CLX code, and in it, window psotioning and resizing seems to be implemented using accessors, so that if you SETF WINDOW-X then that is translated to a later invocation of XConfigureWindow.
9:19:42
loke
XConfigureWindow accepts a mask of which values should be changed, so the key is to not SETF the WINDOW-X property at all. Then its position will not change and the window manager will not move it.
9:22:33
loke
OK, there is PORT-SET-MIRROR-TRANSFORMATION which seesm to be called when a window should be resized. The problem is that when it does so, it _also_ sets the X/Y coordinates, which is the actual problem.
9:23:15
loke
The question is how to fix this, could it perhaps just compare if the old and new coordinates are the same, and if so, not SETF them?
9:24:04
loke
(when you SETF this value, even if it's equal to the old value, it sets the flag in value mask which results in a subsequent call to XConfigureWindow with those coordiantes set.
10:27:02
jackdaniel
it is an indexed-pattern 25x25 with two inks being rectangular patterns of size 25x25 which have as inks patterns 20x20
10:29:43
loke
jackdaniel: xrender does, and I already have a prototype implementation of xrender for lines and plygons.
10:29:47
jackdaniel
but when I'm done with adjusting code to that, I want to provide xrender alternative, yes
10:30:15
jackdaniel
but this has to work for fallback. I'm not brave enough to abandon x servers without xrender extension
10:31:16
loke
also, you can't even draw truetype text without it (both freetype and truetype implementation suse xrender to draw the glyphs)
10:32:40
jackdaniel
I'm not saying we won't abandon it in the future, I'm just saying I'm not ready to do it now
10:34:50
jackdaniel
and all should work without clx (except maybe some recent additions, but in that case it is a bug that such thing doesn't have a fallback)
10:36:17
loke
jackdaniel: fair enough, but I tried it some time ago and all I got was the default "FIXED" font for everything.
10:39:40
jackdaniel
is it a reasonable limitation to forbid using indirect inks in pattern? when we have such ink it is impossible to collapse it (each change of indirect-ink value will invalidate rgba array)
10:41:14
jackdaniel
so if you change medium foreground color and you have something drawin with +foreground-ink+, then repaint / replay will fix that automagically
10:42:28
loke
So you're saying that if you create an output record containing such ink, and then change the enclosing ink and redraw the output record, then the output record's ink would change correspondingly?
10:43:15
loke
I see... WOuldn't it make sense that the effective ink used would be "locked in" when the output record is created?
10:53:07
jackdaniel
verifying on clim side if x/y didn't change and setfing accordingly is fine by me
10:53:33
loke
jackdaniel: I haven't experimented with any potential solutions yet, because I'm not entirely sure of the cirumstances under which you had the window walking beahviour
10:56:14
loke
I think I see how that could happen... It'd change the desired size, which results in a call to set-mirror-transformation, which then sets the x/y coordinates to the old values, resulting in that behaviour
10:56:45
loke
OK, and just changing the x/y to 0/0 that we discssed a couple of days ago should revert back to that old behaviour?
13:48:21
loke
I'm wondering if it is because I have a compositing window manager. If you do, you never get window reconfigure events when moving a window anyway...
15:59:28
loke
jackdaniel: Since we can't reproduce it, how about reinstating the 0/0, and if we see it happen again I now know how to fix it properly.
17:44:25
jackdaniel
slyrus: is it possible for you to use old png load code on clisp (instead of pngload library)?
17:44:42
jackdaniel
it seems that pngload depends on static-vectors which deliberely states, that it won't support clisp
20:24:19
slyrus1
it would be nice if pngload worked on clisp but I don't really want to go back to png-read
20:25:19
slyrus1
jackdaniel, loke: can you take a look at https://github.com/slyrus/McCLIM/tree/scigraph-vertical-text
20:25:55
slyrus1
some of the changes are independent of the vertical text, and could be broken out -- particularly the removal of clim-postscript::*transformation*