freenode/#clim - IRC Chatlog
Search
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
20:36:41
|3b|
i just translated clx/clx-fb backend up use glop stuff, but haven't gotten the -fb part to actually copy to window yet
20:37:32
|3b|
now i need to decide if i want to write some "framebuffer" abstraction it can copy to, or just go straight to GL/GLES
20:38:24
|3b|
it opens windows when i click on the blank demodemo though, so seems to be at last partially working
20:39:20
|3b|
does mcclim have any provisions for running things on specific threads, aside from just turning off threads completely?
20:40:26
|3b|
on windows, i need to handle events on same thread that created the windows, but can have multiple such threads at once, and osx will presumably need to do all window/event stuff on main thread even if running multiple applications
20:41:00
scymtym
as far as i am aware, the backend/port usually has a thread which either does things directly or submits events to be processed in one of the command loops
20:41:58
scymtym
for broadway, i have one thread that talks to the browser, manipulates backend objects and submits events to sheets
20:43:22
scymtym
i was going to say, if that's the requirement, the backend thread should be able to create the window
20:44:35
scymtym
but you are right. you probably have to transmit some kind of window operation requests from other threads to the backend thread
20:47:21
|3b|
though if it is, it could keep a lisp-side copy of contents (which i think -fb backend does already) and event loop could respond to paint messages by blitting whatever is dirty
20:50:11
scymtym
i didn't what the constraints for on-screen or off-screen drawing are if you use, say, GL on windows
20:50:14
jackdaniel
it would be hard to send "window creation" requests to the loop which processes events through the event queue, because it has nothing to do with it. this process's responsibilities end with calling distribute-event
20:50:57
scymtym
doesn't that depend on the backend. i mean, DISTRIBUTE-EVENT is a given, but shouldn't it do other things?
20:51:30
|3b|
jackdaniel: well, on windows/osx, either it gains new responsibilities, or it doesn't exist at all
20:53:07
jackdaniel
there is nothing wrong with having other communication means with the event processing loop (or, lets call it, port-thread loop)
20:53:23
scymtym
yeah, we are (at least i am) talking about a separate event queue and separate events
20:54:39
jackdaniel
if it is possible I'd rather avoid calling them that (and especially not sharing protocol classes) to avoid confusion, otoh naming is a hard problem as some claim
20:54:56
|3b|
then on windows it could have multiple ports each with their own threads, and on osx, there would be 1 port
20:55:40
|3b|
yeah, this would probably go through some glop abstraction, and not even really show up in names
20:55:44
scymtym
in the broadway backend, the port-thread basically runs a bidirectional event pipe to the client and sends a compressed video stream in addition that the usual responsibilities
20:59:37
|3b|
right, saw something like that a few places, which is why i turned it off rather than trying to do something more precise
20:59:37
jackdaniel
and port should honour that (i.e it should not create a concurrent process in its initializaiton)
21:00:27
jackdaniel
keep in mind that it is rather not tested (I've simply disabled multiprocessing to see if the simple queue works), but if that doesn't work it should be considered a bug
21:01:24
|3b|
ACTION will probably try moving window creation to the port thread though, to try to keep it more responsive
21:02:08
scymtym
jackdaniel: but how would you wait for multiple things? in my case an event sent by the browser and, say, a REPAINT-EVENT submitted by user code? there is no WaitForMultipleObjects for our sockets, streams and queues
21:30:20
jackdaniel
scymtym: if process-next-event is called from the clim loop, then repaint-event is send from the very same loop, it is the same process
21:32:14
jackdaniel
if there is some display list caching on the backend side, I'd postpone actual sending to be implemented in medium-finish-output method, but I don't think you are asking about that