freenode/#clim - IRC Chatlog
Search
10:18:19
dk_jackdaniel
scymtym: I'm testing events in your branch: enter/exit events seem to be distributed fine to me, I'm looking into changes now and design.org file
10:19:23
dk_jackdaniel
n.b ieh-2 branch seem to not work anymore correctly with regard to keyboard focus (events are distributed to the sheet under the pointer), I'm confused because it is my branch and it worked when I have tested it last time, but that's not relevant to pointer events right now
10:19:52
dk_jackdaniel
I've probably sneaked in a regression during one of numerous rebases on ieh-1
11:03:24
scymtym
dk_jackdaniel: thanks for looking at the branch. assuming everything works, should i clean the commits up in a new branch?
11:10:01
dk_jackdaniel
yes, please, then I'll look at it once again and after merging I'll start working on ieh-2
11:11:00
scymtym
sounds like a plan. one thing i'm not sure about are menus. they seem to work reasonably in the branch, but i'm not certain their behavior is completely unchanged
11:14:47
dk_jackdaniel
we are going to change their behavior to click-to-focus soon™ anyway, so given they seem to work I wouldn't stress too much about that
11:34:13
dk_jackdaniel
regarding postscript, I don't really like that it depends on clim-core, it seems like the order of dependencies is reversed (because postscript doesn't really require commands neither work with them)
11:35:14
dk_jackdaniel
ideally all backends would build on top of abstractions defined in clim-basic without any knowledge of what is in clim-core (although frame-managers would require extra thought with this regard)
11:37:32
scymtym
we could make the basic output destination mechanism independent of commands to achieve that, but ACCEPTing output destinations is arguably a part of the mechanism so that wouldn't work super well
11:38:58
dk_jackdaniel
maybe we could maintain a port registry with some characteristics and output-destination could use that. right now we do depend on symbol property lists, but having a real protocol to register backends would be more obvious solution
11:41:01
scymtym
i'm not prepared to tackle that problem right now. but let me suggest https://github.com/scymtym/architecture.service-provider for later
11:42:38
scymtym
i will probably finish my general testing pr first. the postscript/pdf/rasterimage one already has too much stuff in it
11:46:42
dk_jackdaniel
I even have a macro somewhere which creates a set of functions to manipulate a certain collection
16:34:27
scymtym
jackdaniel: i made https://github.com/McCLIM/McCLIM/pull/845 for the test stuff. i think it makes sense to work on this one first since it has the PRINT-TEST-PAGE utility which the other pr could use for the backend tests