freenode/#clim - IRC Chatlog
Search
7:20:47
jackdaniel
scymtym: looking at the branch you've pointed me to: I'm not certain which changes are cleaned up; if I had to guess that would be two commits 4f125a2e and 0eec2e05; are changes after that also something we need?
7:26:20
jackdaniel
(n.b in your branch I have unbalanced enter events for randomized sheet hierarchy
7:28:26
scymtym
jackdaniel: it is not finished. it's just what i have at the moment. since we agreed you would have a look some time ago
7:29:52
scymtym
i was improving things whack-a-mole-style until you noticed the menu problem. since that may require more changes, i stopped ironing out the enter/exit problems
7:30:33
scymtym
did you figure out how to use the event logging? i used it to debug event synthesis and dispatching
7:35:07
jackdaniel
I'll look around how you add highlight and if I think of something better I'll let you know
7:57:26
scymtym
i missed your question earlier. bbc8ca822 has more fixes. but i didn't clean up or comment those since i expect more changes to get menus working
7:58:30
scymtym
no, missing highlighting doesn't indicate a problem. but the highlighting sometimes catches problems like wrong port pointer sheet or unbalanced events
8:00:05
scymtym
that's highlighting. by logging i mean the inspector that opens when you load event-log.lisp. the forms at the bottom of the file control it
8:01:11
jackdaniel
hilighting works only per the around method you have defined in the hierarchy-tool (i.e patterns from clouseau sheets.lisp does not appear, I'm not sure how to enable this kind of highlightning)
8:02:06
jackdaniel
also, it highlights only panes, but that is understandable, because this protocol is pane-specific
8:02:51
scymtym
yeah, too many kinds of highlighting. moving the pointer over events or sheets in the inspector should also highlight sheets (with yellow stripes). that works best for single-mirror mode, of course
8:03:47
jackdaniel
when I hover the presentation in the inspectorw window I see the pattern on the sheet
8:05:13
jackdaniel
so, could you reiterate what is the problem you've encountered? (sorry for being so slow :)
8:07:30
scymtym
there are at least three: 1) menus are broken (with and without my additional changes afaict) 2) you found unbalanced enter/exit events for the random mirroring case 3) there sometimes are unbalanced enter/exit events for non-leaf sheets
8:09:13
jackdaniel
menus as in the issue I've commented on the PR? regarding enter/exit events in 2) and 3) I think it is somewhat a regression from what is in ieh-1 branch, no?
8:10:30
jackdaniel
the inspector highlight tool does not work perfectly (i.e it sometimes wipes out whole window without repainting it, not all events provide highlight), could it be that I do something wrong?
8:15:59
scymtym
sure, both debugging tools are not perfect, but at least the event log itself should be reliable
8:17:50
jackdaniel
try ieh-2 branch, unless you drag-and-drop between two mirrored sheets (spurious ungrab events I've mentioned), all is balanced at least from perspective of the counter in hierarchy-tool demo
8:18:02
scymtym
if i remember correctly, ieh-1 had a problem with enter/exit events when pressing a button over a sheet, then holding and moving the pointer somewhere else and releasing there
8:18:44
jackdaniel
yes, that's the only fail scenario, while on the branch you've shown even without pressing I have unbalanced events in random hierarchy
8:19:02
scymtym
the counter is only visible for "leaf" sheets. top-level and {h,v}rack panes were never properly balanced, i think
8:19:56
jackdaniel
either way, I'll start from tackling menu issue and then we'll pick it up from there
8:22:18
jackdaniel
I'd prefer to solve it by making menu use click-to-focus, but that is not ready, so I'll probably try something in line with: menu root when ungrabbed determines which menu element was pressed. but this is very vague, I didn't look into the code yet
8:23:17
jackdaniel
arming/disarming seems to work fine what may be a clue for a correct solution to this
8:24:41
scymtym
the problem is that two release events are distributed due to grabbing. the menu root gets its event first, the menu leaf gets the second one
8:25:12
scymtym
but the menu root disarms and tears down everything so the second event has no effect
8:25:50
scymtym
it could be "fixed" by dispatching grabbing related events in the opposite order, but that would be a fragile hack
8:28:27
jackdaniel
extending menu demo shown another regression with sheet-is-not-ancestor event signalled
8:29:08
scymtym
also, yes, in the long run i would also prefer to change how menus work. but for now we should restore the event system to a state where it can support the current menu behavior
8:30:05
scymtym
this is getting overwhelming. after sorting out the event issues, there two probably very deep clx bugs to figure out
8:34:05
jackdaniel
could you merge this if you find no problems in the commit? I don't want to obfuscate changes in the branch
8:39:31
jackdaniel
you have to forgive me poor jokes relating memes and anime (or, given I want to look less silly, relating to movies and japanease language ,)
8:43:09
scymtym
i can tolerate it. i might retaliate with "they set us up the bomb", "for great justice" or even "get in the robot, shinji" jokes, though (i'm old). i have a suspicion that ck_ is sitting on a few of those as well
8:45:10
scymtym
but eastereggs and jokes require delivering something solid first, so we have our work cut out for us
9:12:20
jackdaniel
n.b: it doesn't seem to be related to port-grabbed-sheet handling, when grabbed-sheet hijack is disabled problem still occurs
9:14:40
jackdaniel
event is sent twice from the xserver (because of grabbing), submenus have separate frames
9:16:48
jackdaniel
I'm not sure about the last statment (that they have separate frames) so scratch that
9:26:23
scymtym
did you find evidence that what i said ("the problem is that two release …") was wrong?
9:27:12
jackdaniel
I think that changing order of event dispatch (that pressed sheet receives events after the destination sheet) is the cleanest one after all
9:31:47
jackdaniel
previously pressed sheets in X worked as follows: if there is nothing below the pointer what is sensitive to the particular kind of event (i.e pointer motion)
9:32:51
jackdaniel
that works fairly well until you try to scroll with pressed button and you wander above i.e buttons, then scrolling ceases to work
9:33:35
jackdaniel
it is worth noting, that it is not how gtk, firefox and other toolkits behave, so they either order xserver by some means to change this behavior or they do more or less what we do
9:37:45
scymtym
i was wondering how our menus worked before, but yes, X seems to deliver all events to the "pressed" window. i checked with xev which should reflect vanilla X behavior
9:39:22
jackdaniel
given that the leaf menu button was sensitive to events, then these events were not distributed to the pressed sheet but rather to the leaf button sheet
9:40:34
scymtym
for things like scrolling over one sheet after pressing and holding over a different sheet, i'm not sure what the right behavior is
9:43:46
jackdaniel
I think of it as if I were drawing with a pen on a sheet of paper. underlying desk receives pressure as well
9:44:49
jackdaniel
if I were to pick any of these two behaviors (without replication) I'd definetely choose gtk one
9:45:12
scymtym
for gadgets, it often doesn't matter either way since the exit event caused by pointer motion out of the sheet region disarms them
9:48:17
jackdaniel
when you try to scroll things it is enough to navigate above any other sheet to make it stop scrolling
10:19:27
scymtym
by "without replication" i meant only dispatching to the pressed sheet (except for some or all boundary events, maybe)
10:20:13
scymtym
but i can imaging problems with TRACKING-POINTER over multiple sheets and thus drag&drop in general