freenode/#clim - IRC Chatlog
Search
2:43:39
|3b|
how do i make a backend use simple-event-queue? (or otherwise force it to check events on same thread that created windows)
3:25:05
|3b|
yeah, better with that... now have a single window i can click on that maybe makes other windows pop up
6:15:06
TMA
jackdaniel: microsoft windows do the "most of the window" trick |3b| mentioned. moreover they do not render for each dpi, the other part of the window is interpolated
9:55:50
scymtym
many of our applications have a NEW-PROCESS keyword parameter in their entry point function. should the new thread use the same server-path/port configuration as the calling thread?
10:01:13
jackdaniel
they use defaults right now. but it is not a standard keyword. I don't think it will be controversial to add *default-server-path* to the thread initial bindings
10:02:16
jackdaniel
n.b: i.e in hierarchy-tool test I'm rebinding default-server-path for tests, I think that drawing-tests do the same for new windows
10:09:48
jackdaniel
if anyone feels like reviewing further drag-and-drop fixes here goes: https://github.com/McCLIM/McCLIM/pull/820
10:11:40
jackdaniel
I've decided on a separate function for the destination defined with a :destination-translator keyword
13:03:39
scymtym
jackdaniel: could you verify something for me? if you (clouseau:inspect (make-list 1000)), then click-and-drag where is says "0 ... 30 shown", is only the interactor pane but not the inspector pane responding to pointer-motion?
13:11:17
jackdaniel
if you add :multiple-window t to the tracking-pointer it should "catch" all panes
13:12:23
jackdaniel
so you could either bind stream to (find-pane-named frame 'inspector) instead of *standard-output* or use multiple-window variant (probably the former suits you more)
13:15:46
scymtym
but wouldn't it be better to use the correct sheet, i.e. the one containing the presentation, in TRACKING-POINTER?
13:17:57
jackdaniel
your call to tracking pointer "doesn't know" anything about the command it is invoked in, so it can't tell where was the object clicked
13:18:43
scymtym
yes, for the other version, i made a presentation-to-command-translator, that looked up the presentation's sheet and passed it to the command
13:21:10
jackdaniel
there could be downsides, if the action is limited only to the sheet, then you don't want possibly trigger same action on another sheet
13:21:37
jackdaniel
scymtym: how about (clim:pointer-sheet (clim:port-pointer (port *standard-output*))) ;?
13:23:02
scymtym
for the clouseau thing, i would just use a scrollbar, but that doesn't work at the moment, right?
13:25:20
scymtym
the BOX-ADJUSTER-GADGET problem may be more complicated. could it require pointer grabbing?
13:29:34
jackdaniel
which use is implied by either: dragging-output, drag-output-record and frame-drag-and-drop (aka presentation dnd translators)
13:31:49
scymtym
i use grabbing in the wider sense here, i.e. also meaning delivering events to a sheet other than the one under the pointer
13:36:18
scymtym
this seems to emulate the X behavior and would also explain why BOX-ADJUSTER-GADGET previously worked without explicit grabbing or TRACKING-POINTER use
13:37:28
jackdaniel
is there a reason why we couldn't do that for "grabbed-sheet"? that is, set grabbing when it is pressed?
13:39:05
jackdaniel
looking at the diff there is some kind of business with sheet ancestors and unmanaged toplevel sheets
13:39:05
scymtym
maybe so that user code could use pointer grabbing freely and not interfere with the port's pressed-sheet tracking?
13:42:26
jackdaniel
no need to be sorry. I still do not understand most of clim, I don't think this strategy would take us nowhere; there are plenty of obsolete passages which someone forgot to remove after one on another change
13:43:42
scymtym
now that i'm aware of the issue, i think scrollbars are also affected. they stop responding when the pointer moves off the scrollbar while dragging
13:44:33
jackdaniel
I will bring back the pressed sheet abstraction tomorrow, or late today, I agree that it was a mistake on my part
13:44:51
scymtym
i had this impression in the back of my head that things had become more finicky. i attributed it to my mouse which has unreliable button, but now i understand what that was
13:45:47
jackdaniel
all I'm saying is that I can't foresee all consequences of changes I make even when I was sure it is harmless (i.e I was convinced that it was a leftover bloat), if that were to prevent me from commiting I wouldn't change McCLIM codebase at all
13:49:03
scymtym
there is principle (i can't remember the name or where i read about it) that you should assume things are there for a reason before you remove them. similar to how you should assume a misunderstanding rather than malevolence when communicating with people. i think both are good guidelines when working on (open source) software
13:51:51
jackdaniel
I tend to agree in general case, in practice though McCLIM is a one big spaghetti pulp (maybe a little more now), so each change may potentially impact something seemingly unrelated and if someone had taken this advice to heart then they would not change anything, only add new stuff (what would only enlarge this pulp)
13:52:25
scymtym
to be fair, i wasn't talking about foreseeing all consequences. i'm also not bothered by churn (i.e. regressions here and there as an unavoidable consequence of making changes) in general. but that's all i had to say. i would put the topic to rest to now
13:52:31
jackdaniel
sure, I've introduced plenty of gross bugs into the codebase and then hurried to fix them, based on a shallow understanding, but I don't see a practical alternative here without someone who would know the code by heart