freenode/#clim - IRC Chatlog
Search
11:13:04
scymtym
jackdaniel: i came up with a strategy for further investigating the event issues. i made an event logger and visualizer that shows events generated by the port and what gets distributed/synthesized. i it already very helpful, but i need one more thing before i can really attack the actual problem: i have to draw things onto arbitrary sheets. what i have only works for some sheets and is also unreliable. is it even possible to draw onto
11:36:15
jackdaniel
to prevent recording, you may do: (if (output-recording-stream-p sheet) (with-recording-options (sheet :draw t :record nil) #1=(drawing)) #1#)
11:39:21
jackdaniel
in principle we could provide dull method specialized on a sheet invoke-with-output-recording options (which would allow :draw t :record nil and :draw nil :record nil, but not :record t option) but that would be arguably a leaked abstraction
11:40:01
scymtym
jackdaniel: thanks, i did the recording part but for some sheets, nothing appears or something appears quasi-randomly
11:47:29
scymtym
this is the thing: https://github.com/scymtym/McCLIM/tree/stupid-event-logger . (ql:quickload '(:clouseau :clim-examples)), then load event-log.lisp and set *LOGGING* to T and interact with the demo for a short while
11:48:27
scymtym
it should highlight the event sheet and indicate the pointer position if you move the pointer over the event in the inspector
11:53:06
jackdaniel
n.b at one time I've been thinking about a separate "overlay" sheet on which we could draw highlightning or other tips which could span multiple sheets in a frame (something like an overexposed top-level-sheet with transparent background)
11:53:53
jackdaniel
I didn't pursue the idea because of lack of time, but it could be a valuable concept
12:39:41
scymtym
jackdaniel: should a leave event be produced for the parent when entering a child? or is the pointer considered to be "in" both sheets at the same time?
13:43:38
jackdaniel
given we are talking about parent-child relation, not unrelated overlapping sheets of course
13:44:57
scymtym
no, i that was referring to the intended behavior, there is a problem when moving from the child to the parent (both without a direct mirror) as i described in the new review comment
13:48:24
scymtym
jackdaniel: before flood the channel with more random details, how would like to proceed with the pull request?
13:53:26
jackdaniel
I'm flooded today ,) I will go over your remarks tomorrow and try to fix things I agree with and try to persuade others (I've left some comments yesterday with some arguments or answers)
13:56:30
scymtym
no, that's ok. i will continue my investigation regarding the clx problem. https://github.com/scymtym/McCLIM/commit/57a399d0d3f621b2ac12db94ec2d8b6153e9fa58 may help with the SYNTHESIZE-BOUNDARY-EVENTS problem i mentioned above and described in the review comment
13:56:41
jackdaniel
I can answer here sparingly, but introspecting the code on my part is out of question I'm afraid
14:43:18
scymtym
wow, X entry/exit events are pretty complicated, but the one of the complications, the "int detail" member, saves us from having to maintain a stack of sheets, i think
14:44:38
scymtym
X generates an exit event when the pointer moves from a parent to a child. we don't consider that "exiting" the parent, as far as i can tell
14:45:19
scymtym
in this case, however, the detail member is NotifyInferior so we can recognize and ignore such events
14:47:32
jackdaniel
first we should rework menu to work with click-to-focus and be expanded when focused
14:50:02
scymtym
i haven't looked into menus but i tend to agree. we probably still have to handle X enter/exit events with NotifyUngrab mode, but hopefully we can turn them into "normal" events before dispatching
15:00:45
scymtym
here is the current behavior for non-grabbing-related enter/exit events for the clx-fb (non-mirrored, synthetic) and clx (mirrored, "natural") cases. note how the pane highlighting works and has transparency for clx-fb: https://techfak.de/~jmoringe/event-logger-1.ogv
15:03:37
jackdaniel
with this unified implementation nothing stands in a away to have a single mirror on normal "clx"
15:04:46
scymtym
but shouldn't we keep the logic working for potential multi-mirror backends? it thought this stuff was part of the spec
15:04:46
jackdaniel
n.b, regarding introspecting sheets, wouldn't it be easier to have a separate reflection of said hierarchy (like in the demo, but prettier)
15:05:33
jackdaniel
because spec only says that some sheets may have a direct mirror, it does not specify which
15:06:36
jackdaniel
to test with configurations where sheet hierarchies have both mirrored and not mirrored sheets intermingled
15:07:49
jackdaniel
regarding drawing on a sheet which is "below" its children, you can't have it visible if both have mirrors. having an overlay would solve said issue (at an expense of playing with coordinatess)
15:11:11
jackdaniel
I was thinking about a child of top-level-sheet which is above all other children and has transparent background
15:11:50
jackdaniel
I think that X actually allows for transparent windows, it is just really bad with semi-transparency
15:13:43
scymtym
yes, i would have approached the it the same way, but overlapping children require stacking order and i don't know whether a transparent window is easy to do with CLIM abstractions (TRANSPARENT-INK?)
15:15:29
jackdaniel
that's what I've meant by that we would need to verify it. if you draw a figure with transparent ink then things below it are visible, but I don't know if it applies to spaces between drawables
15:16:28
scymtym
i see. i would rather not get sidetracked by that now. the event logger is helpful enough as it is
15:41:59
scymtym
with grabbing, the question will be whether we want to enter/exit other sheets while a button is pressed and held
16:38:43
jackdaniel
imo: definetely yes (while delivering motion event duplicate to the pressed sheet in its own coordinate system), as I've proposed
16:39:11
jackdaniel
two cases: dragging a scroll bar, dragging object to drop over another (on different sheet)
16:44:17
scymtym
dropping all grab-related enter/exit events seems to solve the remaining issues. so your suggestions for menus seems very appealing