freenode/#clim - IRC Chatlog
Search
8:12:01
slyrus
it would be nice if our drawing were performant/clean enough to be able to do this, e.g.: https://anvaka.github.io/city-roads/?q=paris&areaId=3600007444
8:14:05
jackdaniel
btw I've hacked together a proof of concept zooming behavior after email exchagne with admich
8:14:28
jackdaniel
just as I thought, medium-transformation is the way to go, but it included some hacks which are not suitable for a pull request
8:18:49
slyrus
you probably remember my little demo from a couple years back: https://github.com/slyrus/zoom-viewer
8:20:08
slyrus
it's been a while but a quick glance suggests that the demo runs better than it used to :)
8:21:23
slyrus
well, would like to check out your new demo one of these days. goodnight for today though!
9:07:30
jackdaniel
as you can see, some glitches appear, because repaint region is not adjusted accordingly
11:16:36
jackdaniel
n.b another approach for zooming would be handling it as an interaction with output-record, then we could be able to zoom individual objects
11:57:44
scymtym
experimenting with static invariants, i discovered SUBMENU-BORDER which looks like an abstract pane type. but 1) it is not in the specification 2) it is not a superclass of SUBMENU-BORDER-PANE
12:01:26
jackdaniel
looking at the code there is a funny behavior involved: submenu-border-pane is never used explicitly but is created, while submenu-border is used but is never created
12:41:15
jackdaniel
well, docstring is not exactly wrong, documentation for list-pane in the spec says that it is instantiable
12:42:58
jackdaniel
I think that the specification is wrong. what is a difference between generic-list-pane and list-pane then? I can only think as if list-pane is an abstract gadget
12:43:37
jackdaniel
and n.b that's how McCLIM implements it, I don't see any "concrete" methods for handling repaint etc
12:44:07
scymtym
also, SHEET-XMIRROR and friends tripped me up again. in my opinion, it is hack that should not have been merged
12:46:49
jackdaniel
it is possible that they were a hack to add after/before methods at some point of time
12:47:10
scymtym
they give the clx-fb backend a way to inject some behavior of its own, if i understand correctly
12:48:51
jackdaniel
I see now, sheet-direct-xmirror does some trickery. but clx-fb had many hacks which proved to be unnecessary
12:49:33
jackdaniel
so I wouldn't be suprised if we could have remove these generic functions in favor of specialization of the usual functions
12:50:27
scymtym
probably. it seems the clx-fb backend was merged when it was at a proof-of-concept stage
12:50:34
jackdaniel
i.e inheritance basic-sheet -> image-pixmap-mixin -> clx-fb-pixmap <- gadget is questionable at best
12:51:21
jackdaniel
that is true and it was my lack of dilligence. I've spent countless hours to revert some changes in the core without foresaking the functionality.
13:35:37
scymtym
this experimentation gave me an idea for including initargs in the "traits" prototype
13:40:47
jackdaniel
ACTION tries to write down all insights he has gained while working with input processing from port way up to typed input
13:41:33
jackdaniel
unsurprisingly it is very easy to implement it wrong (or to have a partial hackish implementation)
13:49:52
jackdaniel
and that gives me some foggy ideas how we could have typed input across different frames, but it is just a hunch yet
14:06:18
scymtym
if the ELS deadline wasn't so close, writing a paper on the traits system might have been good
14:16:22
jackdaniel
here is a sketch of an idea to make cross-frame sensitive input work: https://gist.github.com/dkochmanski/f04e9bddf94854c44b3439b618b3fab5 ; I'm sure there are many things to consider before making that happen
14:21:35
jackdaniel
currently when we dispatch event, we dispatch it to an event queue associated with the target sheet, which is initialized to be the same as the frame
14:22:29
jackdaniel
then when we read a gesture, input-wait-test and input-wait-handler check, if a gesture selects an object which the input context (i.e we wait for a presentation of type integer) and if it does, then it performs a non-local exit
14:23:36
jackdaniel
each frame (usually) runs in a separate thread and has a separate event-queue, and their stream-read-gesture is run in a different typed input context, so we can't know what presentation type other frames "wait for"
14:24:14
jackdaniel
so the typed input context in which the event is considered depends on the queue in which it is dispatched
14:25:18
jackdaniel
in one frame we wait for integer (which is focused), then we click on a presentation displayed on a sheet in a different frame. if the event is queued "to us" we may use the presentation.
14:29:05
jackdaniel
method dispatch-event checks, what is the port's focused-sheet and takes the event-queue from it
14:32:47
jackdaniel
n.b same applies to a tracking-pointer, we can't track it across different frames if they do not share the same event-queue
15:03:46
slyrus
jackdaniel: regarding the zooming via interaction with output-record, I would think we should support (and test) both approaches.
15:04:31
jackdaniel
slyrus: I can only work on so many things at the same time :) regardless, I think that this proof of concept is at least interesting
15:06:56
jackdaniel
it won't work for text output records, but that's a bug in the implementation of medium-draw-text (at least I think it is without taking a deeper look) -- there is no around method for transform-coordinates-mixin
15:07:36
jackdaniel
instead text otuput records inherit from gs-transformation-mixin, what works quite differently, however is meant for the same thing as pre-transforming coordinates when outputting output records