freenode/#clim - IRC Chatlog
Search
4:57:08
loke
I've come to realise that my anguish about where to store the current selection/clipboard (in the port, in the frame, or the pane, global variable?) was because it probably shouldn't be in any of those places... I now believe that the responsibility of storing the selection belongs to the backend.
5:00:29
loke
The reason I wasn't thinking along those lines initially was that I was discussing with JD the bpossibility of implmenting things like kill-rings, which extends what the normal copy&paste features of the operating system has. My updated view on this is that what I am doing right now is simply to create a reasonable interface to the low-level operating system features, and any extended functionality should probably be built on top of
5:01:09
loke
Since in X11, the clipboard/selection is associated with a window, I could probably store it in the window-plist of that same window.
5:01:48
beach
I believe you. I am usually totally incapable of thinking through things like that. Only after I see the consequences of some decision am I able to determine whether it looks right or not.
5:02:37
loke
If anyone wanted to do some historical research, they could probably look through my commits on my cut&paste branch and see all the failed approaches :-)
5:02:46
beach
You probably need to keep the objects in the client as opposed to the server. Otherwise you would have to serialize/unserialize them.
5:03:12
loke
Yes. Not just becasue of that. That's actually the way X11 works (and also, if I understand things correctly, Windows)
5:04:44
loke
In X11, you have a call that allows you to take ownership of the selection. After that, when a program wants to paste, an event is sent to the owner asking it what datatypes it can provide. THat gets returned back as an event to the caller, and then the caller can make _another_ call that causes another event to be sent to the owner, this time asking the owner to package up the data in the requested format.
5:05:25
loke
I have notices that some programs don't do it in the proper way (i'm looking you, Firefox) and instead just keeps asking the owner for the data in various formats until it receives a reply.
5:08:19
loke
Now, after describing that, you now have the appropriate background to provide insight into this design dilemma I'm facing:
5:09:23
loke
As you might see, it's impossible to provide a simple API to retrieve the selection (for the purpose of pasting). In an ideal world, the call would be simply: (GET-CONTENT-OF-CLIPBOARD :HTML). This would then return the current content in HTML form.
5:09:42
loke
However, since such a request involves multiple calls and event replies, it cannot be done that way.,
5:10:12
loke
I was thinking of having this call accept a callback function as argument, which will eventually be called with the result once it arrives.
5:12:40
beach
If not, you can limit yourself you Common Lisp objects, and not bother about the type of the representation.
5:12:49
loke
beach: You mean being able to paste a "live" link to a different application? (like Windows "smart copy")?
5:14:00
beach
I always look at things like this in a CLOSOS (Lisp OS) perspective, so I never think inter-process communication is important.
5:14:14
loke
beach: Ah, I see what you mean now. Well, I do need to concern myself with the object types. Most copy&paste happens between CLIM and applications which are not Lisp. For example, you probably want to copy some text from Climaxima and paste into an Email. Or you want to copy text from a web page and paste into Second Climacs.
5:14:29
beach
And, in this case, I think it is important to cover the case where several Common Lisp applications in the same process want to exchange Common Lisp objects.
5:15:34
beach
To me, the email client should be another CLIM application running in the same process.
5:15:36
loke
beach: Yes, right now I have only three object datatypes: :STRING, :HTML and :IMAGE. These are the core ones needed for interoperability with external programs. I will also add a few CLIM-specific ones, like :LISP (being a serialised Sexp)
5:17:00
loke
beach: For CLIM→CLIM copying, I intend to introduce yet another datatype, like :LIVE-LINK or something like that, and the content of this would only contain the necessari information how to connect to the other component using a non-braindead protocol.
5:18:10
loke
beach: But, I'm still on the lowest level. The higher level stuff will be much easier, since there will hopefully be no need to deal with operating system shenanigans.
5:19:30
loke
beach: but you are capable of providing advice with regards to what a reasnable API call can look like, given the specific limitation that the rsponse to a request can come in up to a second later.
5:20:16
beach
Oh, and I am going to be very distracted for the next week or so. In a few hours, drmeister and his family will come for a week long visit.
5:20:55
loke
So the question buils doen to: Is it reasonable to present an API that accepts a callback function that will be called with the result once it arrives? I note that there are no other CLIM API's that do this. Traditionally CLIM API's have just been blocking, waiting for something to happen.
6:35:35
jackdaniel
slyrus: claim a bounty :) https://github.com/McCLIM/McCLIM/issues/380#issuecomment-423719732
7:11:32
jackdaniel
I can understand that they are unwilling to have a virtual bank accoutns for users
7:12:04
jackdaniel
otoh this rushes people to either withdraw or donate money to the project withing 3m
7:40:00
jackdaniel
it seems I'll bite the bullet and implement clx-render-medium since I have these parts of code in my head [unenthusiastic yay]