freenode/#clim - IRC Chatlog
Search
5:13:16
loke
What would be a good way to transfer the selected text to the clipboard? (i.e. what in Windows/GNOME is achieved by pressing Control-C, orin OSX by pressing ⌘-C)
5:15:42
loke
Or something with the mouse? We already steal Shift-Click on the text... So perhaps Shift RIght-Click?
5:16:49
loke
It's something that until now simply hasn't been supported, so except for the interactor command, it's something that doesn't have an analogue in older CLIM applications, I think?
5:18:50
slyrus
I'm a big fan of selecting text and then using the middle button to "paste" said text. Not sure what the magic under the covers is but that sequence just worked for me on thunderbird (to select text from my IRC window) and emacs (to "paste" the text using the middle mouse button).
5:19:50
loke
slyrus: The new stuff is support for the clipboard. C-c (or ⌘-c) copies the content of the selection to the clipboard.
5:22:08
loke
I mean, for anything that supports plain slections (i.e. middle-click) that still works of course.
10:42:14
loke
jackdaniel: Rememebr how the suggestion was to send an event containing the content of the clipboard after it's requested?
10:43:46
loke
The problem is that events are sent to panes, but the requestor may not be a pane. In most cases it's a DREI instance. (there can be many DREI's in a single pane)
10:46:49
loke
Now... The existing implementation does send an event, but it has an event-handler that picks that event up, and rainses a singnal, the condition that is raised contains a slot that holds a reference to the event. Then, inside DREI::READ-GESTURES-AND-ACT, it catches this signal and inserts the text. I tried the same, but it turns out that's not the only place the events are processed.
10:47:34
jackdaniel
that's why I want to get rid of drei, it does not fit well in clim infrastructure with all emacsusms it has
10:47:42
loke
It just so happens that it works in the existing implementation because you're in the middle of clicking the mouse when pasting. When typing, the condition is raised inside a completely different function.
10:48:51
loke
The issue here is that I need to be able to deliver the notification that the clipboard data has been returned to an arbitrary receiver.
10:50:11
loke
The callback mechanism that I proposed earlier will work. Another idea is to add an argument to REQUEST-CLIPBOARD-CONTENT which is an object, and then a generic function is called with that object as argument. So you could, for example, have a method (DELIVER-CLIPBOARD-CONTENT receiver content), where reciver may be the buffer or whatnot
10:50:34
loke
jackdaniel: Yes. The existing implementation hooks into there. Which is why a plain drei pane can't handle copy&paste
10:51:50
jackdaniel
I can' t help you much with drei, I don't know it well and as you see general clim knowlege cant be applied
10:52:21
loke
jackdaniel: Right, let's forget about drei and focus on the issue itself (which is not related to drei actually)
10:54:26
loke
(Just for completeness sake: Pasting into interactors sometimes work. It does use the same text-editor-thingy)
10:54:29
jackdaniel
and it doesn't work, because it is drei? then it really is related to drei /actually/
10:54:54
loke
jackdaniel: No. It doesn't work, because an event is delivered to a pane. And you can have many different receivers of events inside a pane.
10:55:22
jackdaniel
and it is up to a sheet/pane how it deals with the content ,but in principle input-editing-stream should be one of the pane superclasses
10:56:03
loke
I guess there going be some logic in the sheet that would know what to do with the data...
10:56:07
jackdaniel
not some internal object, and if it is not, then it is sheet responsibility to "know" where to pass th econtent (not via event)
10:56:46
jackdaniel
and from this opint on (where sheet handles the event) CLIM considers the event handled
10:58:11
loke
When you shift-drag in a stream pane, I note that all the drawing and processing of the highlighting is done in the CLIM event loop itself. That's... Not ideal, given the fact that CLIM is not thread-safe
11:00:06
jackdaniel
to put it simply: McCLIM is thread-safe internally, it is not thread-safe against asynchronous operations from outside its own loops
11:00:28
loke
Yes. But the drag processing happens in the main event loop, that handler then calls methods on the pane itself to look at the output records with text and stuff... That menas that those records are being read while at the same time the application thread may be running doing its own things.
11:01:18
loke
If you write a program that updates the content of a stream pane, and you shift-drag at the same time, you'll end up having two threads manipualting the output records at the same time, no?