freenode/#clim - IRC Chatlog
Search
8:55:38
scymtym
jackdaniel: we didn't finish the discussion about drag and drop translators. i would like ask about one particular thing if you have time
8:57:47
scymtym
the pointer is over a presentation and two drag and drop translators ca translate from this presentation. one is associated with the :select gesture and the other one with a button press gesture that includes a modifier
8:58:35
scymtym
when i press the modifier and start dragging, the appropriate translator is selected and used when running the :test, generating feedback, etc.
9:00:20
scymtym
but when i drag the pointer over a presentation that is valid as the "to" presentation type of both translator, it appears to be unclear the translation function of which translator is run in the end
9:01:19
scymtym
from a user perspective, this feels like explicitly initiating one command (by pressing the modifier) but then having a different command run
9:02:41
jackdaniel
I don't think that this behavior is new (but I've worked on it too long ago to claim that with certainity)
9:02:46
scymtym
this is easy to mitigate by preferring the already "active" translator when choosing the translator whose translation function should be run, but now i'm curious what the rules are
9:03:43
scymtym
i.e. why can the target presentation effectively cancel the current translator and replace it with a different one?
9:04:59
jackdaniel
when you look for translator matching the context type, then they are sorted by priority
9:05:59
jackdaniel
another is to return NIL from the test-drag-and-drop-translator, then search continues
9:07:03
jackdaniel
if no destination translator is found (or all fail on a test), the "original translator's which got us here" feedback/highlight etc are used
9:07:30
jackdaniel
(also, when there is no applicable translator we do not highlight the presentation)
9:11:38
scymtym
say all presentations are of the same type FILE. and all commands (move, copy, symlink) can be initiated by dragging a FILE onto another FILE
9:13:30
scymtym
we can use different gestures to select the initial translator, but since "from" and "to" presentation types are the same in all cases, we get a random destination translator (the static priority doesn't help either)
9:27:05
jackdaniel
I think that code is mostly fine, but we should compute translators in invoke-drag-and-drop external let*; my first thought is that we should map-applicable-translators
9:29:15
jackdaniel
as an addendum: maybe we should use *current* modifier state in find-dest-translator; but I'm not sure how that would behave. I start dragging file with a shift, then I release shift.
9:30:35
scymtym
in the example i gave, the current modifier would dictate the final translator choice
9:31:08
scymtym
i.e. while hovering over the destination you could press modifiers to select the action
9:32:08
scymtym
that sounds reasonable to me but don't understand this subsystem deeply enough to really have an opinion
9:32:41
jackdaniel
but this seems to be orthogonal with the destination-tester you mentioned you had problems with(?)
9:33:36
scymtym
only related in that it stopped me from investigating the destination-tester issue further
9:47:44
scymtym
jackdaniel: thanks. i'm making the file manager example, so i will be able to test it soon
9:47:47
jackdaniel
I may drop any minute now (and will be back around 2pm), if you could elaborate on the destination-translator issue in a meantime then I could think about it
9:48:43
scymtym
i can probably integrate that into the example - disallowing dropping file onto another (non-directory) file or something
9:49:09
jackdaniel
do you think you'll find time to look into refactor regions PR? I'm almost finished with a next batch of changes (region-intersects-region-p)
9:49:28
jackdaniel
you could make a file named "lizard.lisp" and that file can't be dropped over a trash icon ;-)
9:50:55
jackdaniel
unfortunately region refactor is an ungrateful work because there are no visible effects to it at the first glance, many places for misstep and plenty to do
9:52:23
jackdaniel
right now we *almost always* do a roundtrip to region-difference for most of things
9:53:11
jackdaniel
I got to go now, please write here in a meantime if you can recall problems with a destination-translator
11:27:58
scymtym
in this example, using the current modifier state would give the usual behavior, i.e. you would be able to choose between copy and move while already dragging
12:21:04
ralt
Hi. I'm sorry if that's a bit rude of myself to ask this, but I've been following this channel (and development of clim) for a while, and I can't bring myself to understand what I'd use McCLIM for. Could anyone shed some light on the usages you have of it?
12:42:20
scymtym
ralt: i mostly use McCLIM for making tools. https://techfak.de/~jmoringe/?C=M;O=D has many examples
12:43:24
scymtym
basically everything graphical you find there uses CLIM (and probably graphviz in a few cases)
12:50:51
jackdaniel
ralt: CLIM to CL is what GTK+ is to C (and like CL is very different from C CLIM is very differnt from GTK+)
12:51:08
jackdaniel
scymtym: do you mean that it does "the right thing" or that it fails to do the right thing?
12:51:50
scymtym
jackdaniel: i don't know. i mean in this particular case, it maybe doesn't do the best thing (that would be changing the translator as i press modifiers)
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