freenode/#clim - IRC Chatlog
Search
6:43:33
loke
jackdaniel & beach: I have now two separate, but equivalent, ways to implement fetching data from the clipboard. I'd like to hear an opinion as to which one to prefer:
6:43:53
loke
1) The fetch-from-clipboard function accepts a callback function that will be called when the data is ready
6:44:19
loke
2) some time after fetch-from-clipboard is called, an event is sent that contains the content
6:46:42
jackdaniel
because if it is not McCLIM's event/command thread you'll get races if you work on sheets
6:47:36
loke
jackdaniel: from the "main" thread. McCLIM isn't really thread-safe, so it's not really valid to call most functions from other threads.
6:48:45
loke
The event version also has one particular “benefit” (I put it in quotes because I don't know if it really is a benefit):
6:49:12
loke
If the remote never replies, the event will never be sent. That is a simpler mental model than a closure that is never invoked.
9:37:29
jackdaniel
we have two macros: with-double-buffering and with-possible-double-buffering (first one is broken due to many unfounded assumptions about pixmaps, transformations etc).
9:37:50
jackdaniel
second one depends on medium-invoke-with-possible-double-buffering which delegates things to the backend
9:38:24
jackdaniel
I plan to use only the latter without unnecessary kludges (which are broken anyway), so it is up to backend whenever double buffering works or not
9:40:29
loke
jackdaniel: I have been half-successful in getting the general idea expressed by them to at least draw something.
9:40:50
jackdaniel
medium-invoke-with-possible-db is part of the latter solution and it depends on whenevery you implent that method or not
9:41:21
loke
jackdaniel: yes. I tried implementing it, and ran into issues due to incorrect assumptions about PM's
9:44:01
loke
jackdaniel: Of O recall correctly, where I stopped was when I dscovered that draw-image doesn't work with DB
9:44:30
jackdaniel
draw-image has been eradicated in favour of draw-design and draw-pattern which are both standard
9:44:40
loke
It tries to convert the image to a pixmap of the correct target type, but it trues to determine the colourmap of the target window, but a picmap doesn't have a colourmap
9:45:28
loke
Wait, it must have been draw-pattern that I did use, because the test case that failes was the image-transform demo.
9:47:38
loke
jackdaniel: Yes, but what I mean is, do you intend to get double buffering to work for everything, including the drawing of images?
9:48:18
jackdaniel
if I encounter something impossible or time-consuming I won't fix that, I've already invested a lot of time to this stuff
9:49:52
loke
jackdaniel: That would be awesome. I'm curious if you'll find the same issue that I found when the code attempts to read the colourmap from a pixmap (that said, I believe the entire logic that this is part of is wrong, but I discussed that previously).
9:50:54
jackdaniel
(xlib:find-window-picture-format (xlib:drawable-root mirror)) ← isn't that good enough? afaik it works on pixmaps just fine
9:53:20
loke
It's being called as such (xlib:window-colormap drawable). However, a drawable has no colourmap.
9:55:13
loke
But... I just got confused about that code as I didn't understand what problem it was meant to solve. Eventually I decided that probably it's not needed at all, but never researched it further.
10:57:39
loke
jackdaniel: Can I always assume that every X11 window is mapped to a unique CLIM sheet? (and vice-versa)
14:20:41
jackdaniel
I give up with db for now, I'm just removing broken interface and leave one which may be used to implement db. it should be easier to achieve after we fully migrate to xrender