freenode/#clim - IRC Chatlog
Search
7:18:05
jackdaniel
we have clime:draw-glyph (which is basically a single-character variant of draw-text), I plan to eradicate it as undocumented and unnecessary along with medium-draw-glyph from climi package
8:48:45
scymtym
jackdaniel: here is what i have so far: https://techfak.de/~jmoringe/DESIGN.pdf . i'm sharing this at this draft stage to give you a chance to comment on the style and also to discuss an idea
9:23:06
jackdaniel
scymtym: what you wrote there makes sense to me. here are my (minor) remarks: http://hellsgate.pl/files/b40ad8cf-notes.org
9:29:43
jackdaniel
in ieh-1 we do not distribute original event but rather synthetise it (even if it is enter event)
9:31:27
scymtym
there is the notion of "enabled sheets". the implementation in the PR is partially sensitive to sheets being enabled or not
9:32:40
scymtym
i would like to specify how being enabled or not effects boundary events, but i'm not completely sure what "enabled" means
9:33:54
jackdaniel
in other words, if you disable the sheet, that sheet and all its children disappear
9:34:58
jackdaniel
also, regarding z-ordering it might be worth considering how we could leverage sheet-occluding-sheets generic function
9:37:40
jackdaniel
yes, I've just thought that I will forget about this thought, so I've put it here
9:38:38
scymtym
i have thought about overlap and z-ordering as well, but i would like to ignore it for now if that's ok. it should be easy enough to integrate later (famous last words)
9:39:22
jackdaniel
sure, that's what I thought when I've put aside for a week Material Design works (2 years ago)
9:41:40
scymtym
the idea i wanted to discuss is this: the "Algorithm" section is based on having an old pointer sheet and a new pointer sheet. i think we could organize the implementation into two phases as well: 1) for all events, including boundary events, compute the new pointer sheet 2) synthesize boundary events
9:43:34
scymtym
the current code re-implements special cases of the general boundary event synthesis for enter and exit events
9:44:06
scymtym
i'm currently trying that while enforcing the stack properties stated in the "Specification" section
9:47:47
jackdaniel
I don't understand what do you mean by these phases, maybe it will click if you elaborate a little or after a short break on my side
9:49:44
scymtym
sorry, i mean processing all events like this: phase 1: compute new pointer sheet, phase 2: synthesize boundary events. as opposed to handling enter and exit events specially
9:52:53
jackdaniel
synthesize would take then two additional arguments: old-sheet and new-sheet, right?
9:53:16
jackdaniel
sure, I see now issue with that approach, and we'll save ourself setting port-pointer-sheet numerous times
9:53:52
jackdaniel
given it is requirement for the algorithm you've described and we both agree that it is the correct thing to do, then we should do it
9:55:57
jackdaniel
I agree that we could put all these functions as local in distribute-event, but from readibility perspective it makes a reasonably straightforward function which delegates responsibilities into something big (and scary!:)
9:55:58
scymtym
no, i want to put (let ((old-pointer-sheet (port-pointer-sheet )) (new-pointer-sheet old-pointer-sheet)) …) at the top of SYTHESIZE-BOUNDARY-EVENTS. NEW-POINTER-SHEET will then be updated before synthesizing boundary events
9:58:30
jackdaniel
mind you didn't mention in this document how we handle events with regard to pressed sheet, but I gather it is due to "one thing at a time" approach and draft will be expanded when this is working?
9:59:00
scymtym
for non-exit events, NEW-POINTER-SHEET can be set via COMPUTE-POINTER-EVENT-SHEET, for exit events, NEW-POINTER-SHEET is set to an ancestor of the event sheet
10:00:45
jackdaniel
it doesn't, imo it should receive only motion events (in its own native coordinate system) and release event
12:18:25
scymtym
implementing the specification and enforcing the properties works pretty well. i have trouble with border/scroller/viewport panes
12:19:35
scymtym
i don't know exactly, but the stack properties are sometimes violated when a combination of those kinds of panes is involved
12:22:12
jackdaniel
consider this: you have two mirrored sheets: scroller-pane and scroll-bar (positioned on the right)
12:22:57
jackdaniel
when you move pointer from the right to enter the scroll-bar, it might be that pointer is never in the scroller-pane area
12:27:42
scymtym
jackdaniel: i pushed my tool for debugging the sheet stack issue. quickload (:clouseau :clim-examples), load Core/clim-basic/event-log.lisp, load Examples/port-pointer-sheet.lisp to test it
12:45:21
scymtym
ok, border panes are strange. they are part of the sheet hierarchy, they have direct mirrors (i think), but i haven't seen any X-level events for them
12:49:31
jackdaniel
scymtym: regarding border pane behaving "weirdly", please take a tlook at the %realize-mirror method
12:50:11
jackdaniel
;;(rotatef (medium-background (sheet-medium sheet)) (medium-foreground (sheet-medium sheet)))
12:50:33
jackdaniel
so there is no wonder you observe fishy behavior, it accepts only exposure and structure-notify events
12:52:55
jackdaniel
but looking into the history I can tell, that previously that accepted a lot more events
12:53:39
jackdaniel
:exposure :key-press :key-release :button-press :button-release :structure-notify
12:54:33
jackdaniel
one could argue, that for sake of consistency all but top-level sheet mirror should behave exactly the same
12:54:50
jackdaniel
even if you don't really need to make some mirrors sensitive to particular events
12:55:40
jackdaniel
n.b: enter and leave events were not present for border-pane since the initial check-in
12:56:36
scymtym
i don't see why though. somebody could want a border pane that changes color when entered, for example
12:56:38
jackdaniel
working with McCLIM codebase for over three years proven to me, that at various occasions some things were written with some future plan in head which was never executed
12:57:00
jackdaniel
and simplifying it often does not break anything (sometimes it does, as you've noticed with some of my changes)
12:57:53
jackdaniel
and some other code passages are overly strict (like with this border-pane specialization) and other overly lax (like with mirroring everything for convenience and having code not working for unmirrored hierarchies)
12:59:08
scymtym
in a recent change, some code was supposed to signal MISSING-FONT, but the ERROR call uses the wrong MISSING-FONT symbol
12:59:46
jackdaniel
I broke a lot of things and that makes me less certain about my capabilities, but I think that many (if not most) changes were justified and moved the code in good direction (and removed plenty of dead code paths which were never truly working)
13:00:17
scymtym
i think running the font selector demo with the clx-fb backend reproduces the problem. see commit d2b03a701 in the stupid-event-logger branch
13:01:07
scymtym
as i said before: i also think that the last years worth of changes are a clear net positive
13:04:22
jackdaniel
I could have missed that part (or maybe the phrasing was a bit different) either way I think we should at least consider removing this border-pane specialization
13:07:47
jackdaniel
I see the commit and I agree, that is a bug; n.b it is a nice illustration of the type of issues when internals are spread across numerous packages (in this case mcclim-truetype)
13:13:30
scymtym
maybe this is all for performance reasons? if so, the justification should be re-examined
13:14:34
jackdaniel
pointer-motion indeed generates plenty of events, but leaving out enter/exit event does not have valid justification from this angle
13:15:16
jackdaniel
also border-pane has a child so if the child is mirrored, then events go to said child
13:15:32
jackdaniel
if it is not, then we should accepts these events and distribute to unmirrored children
13:18:40
scymtym
i just realized that i should change the sheet stack debugger to maintain on stack for each port
13:27:13
jackdaniel
I have a hypothesis where did this border-pane peculiar behavior come from (no way to verify that): clx allows to set border-width (and even realize-mirror-aux passes such argument to clx's function), so preasumbly border-pane at one point was only declared being a sheet while in fact i was not mapped and only border-width value was passed to clx
13:27:46
jackdaniel
and then it has changed and clx receives always border-width 0 and we draw border ourself
13:29:50
jackdaniel
assuming this hypothesis is correct we should remove the specialization for %realize-mirror and border-width argument from realize-mirror-aux altogether
13:30:31
jackdaniel
(from mcclim perspective removing border-width argument won't change anything, because we ignore the argument anyway)
13:32:31
jackdaniel
what I'm saying is that before the initial code was checked in, border-pane effect was achieved with clx's border-width argument seeded from the border-width in the pane, and (speculatively) it was changed also before the check-in
13:34:43
jackdaniel
n.b I think that the same applies to "border" argument to the realize-mirror-aux
13:41:00
scymtym
i would be glad to get rid of that stuff (after verifying that it is indeed not needed). preferably before merging the event changes
13:42:58
jackdaniel
would you mind if I sneak there a few other small commits I have cleanly commited locally? (text-style-character-width change I've mentioned, removal of draw-glyph protocol and removal of invalid comment)
13:52:09
jackdaniel
if you object having unrelated things in the pr please let me know and I'll make another one and close this one (it will grow because I'm working with basic-medium)
15:42:01
scymtym
ungrab leave events are like returns from abandoned exit points - headache inducing