freenode/#clim - IRC Chatlog
Search
12:56:34
jackdaniel
it is noteworthy that shift seems to stop dragging completely until you release it
12:56:39
scymtym
jackdaniel: it is one of the possible behaviors and certainly better than the previous one
12:58:26
jackdaniel
I thought that your answer to the "addendum" remark was expressing your preference not a possibility, nvm then
12:58:32
scymtym
i consider "initial translator stays despite modifiers pressed later" as well as "translator is changed according to pressed modifiers" valid behaviors. i don't know which one we generally want
12:59:20
jackdaniel
behavior with the same set of translators matching the initial modifier is certainly cheaper
13:00:56
scymtym
could we give the destination-tester access to the required information to make the decision?
13:01:40
jackdaniel
changing that would be more or less: defining external binding last-modifiers and in find-dest-translator querying the window if it didn't change
13:02:33
jackdaniel
regarding passing that information to the destination-tester: then it wouldn't be any different from the previous version - modifier state may be queried from the window argument
13:03:19
jackdaniel
and tester may say: hey, this is not my modifier, I'll return NIL, so we get to the next translator
13:06:01
beach
ralt: I was very surprised to see your question. Did you now know that CLIM is a GUI library?
13:11:38
jackdaniel
n.b recomputing translators would require computing both "all" and "applicable" translators, because we would need "all" translators fro the context-type of the tracking-pointer
13:13:08
scymtym
i'm not sure i understand. i thought we already had a set of applicable translators irregardless of the initial or current modifier state. wasn't that the initial problem?
13:14:26
jackdaniel
that is we bind to a symbol translators only translators which are applicable (with the modifier state etc)
13:16:41
scymtym
so the alternative would be initially computing the full set (disregarding modifiers) and then filtering based on /current/ modifiers
13:20:09
jackdaniel
we take only translators for which test returns T (with the current modifier supplied) - basically what we have in a branch. if someone wants to switch modifiers during dnd, then the translator test should return T disregarding the modifier (or for some set of modifiers), and the decision to accept may be "filtered" in the destination-tester based on the modifier (i.e queried from the window, but we may
13:21:00
jackdaniel
that's a flexibility which destination-tester gives us thanks to having a separate definition
13:28:05
jackdaniel
regarding matching gestures and modifiers, please see test-presentation-translator
13:30:32
jackdaniel
notice, that modifiers are not passed to the tester function defined by the programmer
13:31:19
jackdaniel
also, look at the loop part: with modifiers = (if event (event-modifer event) modifier-state)
13:31:20
scymtym
but the window is? i tried :pointer-documentation ((… window) (when (plusp (window-modifier-state window)) …))
13:40:05
jackdaniel
modifier-state is put in an event, I don't see anywhere where update-pointer-state is called
13:40:41
jackdaniel
look in example at frame-compute-pointer-documentation-state, where the context is found with the modifier taken from the event
13:41:51
jackdaniel
another handful number of interfaces which were planned to do something but were never plugged in :(
13:45:54
jackdaniel
imo we should remove unused interfaces and if we want them reintroduce them cleanly. I don't like playing whack and mole with unused/not fully implemented functions when I can't talk with the author what they had in mind
13:47:15
scymtym
the callbacks are not invoked for key presses so the translator cannot change its feedback or documentation based on the modifier
13:47:22
jackdaniel
that's what I mean by whack and mole: repairing unfinished interface when you do not have an insight into the original idea is very frustrating (however very much possible)
13:48:04
scymtym
sure, but i would say that removing and repairing lead to problems when done without understanding
13:49:06
jackdaniel
often mere removal of things which you can prove are unusued (or mechanical code translation into something more intelligible without changing actual behavior) greatly can improve readibility and understanding
13:49:27
scymtym
the feedback function doesn't get the event, so that can't adapt based on the current modifier either
13:50:13
jackdaniel
regarding calling feedback/documentation on key press, it is but one :keyboard clause in tracking-pointer away
13:52:58
jackdaniel
I think that we shouldn't check for modifiers in the feedback but rather reject the whole translator in destination-tester (so we move to the translator which is applicable and has the right feedback)
13:57:23
scymtym
jackdaniel: but looking at modifiers in the destination-tester requires undoing your changes
13:58:25
jackdaniel
you pass "everything" in the tester, but you are more picky in the destination-tester
13:59:30
jackdaniel
or, to be more correct, all testers accept the union of all valid modifiers while destination testers accept whatever is semantically desired
14:00:37
scymtym
hm, not sure now because your change filters based on :gesture vs. initial modifiers
14:01:01
scymtym
so you can't start dragging with modifiers, even if the tester permits it later, i think
14:05:24
jackdaniel
probably it will be worth documenting how to work with d&d translators this way; otoh commented example in demos should suffice
16:51:32
jackdaniel
scymtym: if you want to play with a keyboard handler please mind that unless multiple-window is T, the clause in tracking-pointer won't be trigger if the sheet is not keyboard-focused
19:34:14
jackdaniel
if anyone feels like debugging why commands are disabled in a definition which looks fine at the first glance please take a look at https://mailman.common-lisp.net/pipermail/mcclim-devel/2019-October/002129.html
20:25:43
scymtym
jackdaniel: the commands don't seem to be defined within any command table. adding e.g. :command-table cb-file enables the menu entries
20:28:13
scymtym
the spec says without :command-table, the command will not be added to any command table. i would assume that makes the command not accessible in the menu command table
21:01:02
scymtym
this example programs assumes CLASS is a builtin presentation type and CLASS-NAME can be applied to slots