freenode/#clim - IRC Chatlog
Search
2:57:33
loke
jackdaniel: I made the requested changes. However, I don't understand the last comment about incomplete state.
5:21:19
slyrus__
beach: does your clobber library support "time travel" where I can see the state of the world at a given (earlier) point in time?
5:22:42
beach
I don't think I implemented that, but it would be trivial since the log is all there is.
7:22:01
jackdaniel
loke: I mean that these operations are single setf, so there shouldn't be a problem with concurrent access
7:22:42
jackdaniel
counterexample: event queue: fetch queue head and replace it with (cons element last-head), this may lead to events being lost
7:31:39
jackdaniel
loke: could you explain to me how the request-selection-content works? especially for :targets
7:34:02
loke
jackdaniel: The :TARGETS stuff is part of the CLX implementation. It's backend-specific.
7:35:47
loke
OK, when a client wants to request something from the clipboard, it specifies an ATOM which indicates the type of data that the requestor expects.
7:36:38
loke
There is a special atom, :TARGETS, that indicates that the requestor expects a list of the formats that the selection owner can support.
7:37:05
loke
So, when the client receives a :TARGETS, it needs to constrcut a list of all datatypes that are supported, and return that to the requestor.
7:37:35
loke
Conversely, when a CLIM client wants to copy some data, it sends a :TARGETS request to learn what the supported datatypes are, and then pick the most appropriate one once the reply comes back.
7:39:14
loke
As you can see in MAKE_TARGETS-RESPONSE that it calls the conversion function for the clipboard content multiple times to determine the supported types, in order to construct the list of supported targets.
7:42:54
jackdaniel
so let me confirm my understanding: clim wants something of presentation type FOO, it calls request-selection-content which issues :targets request via convert-selection [end of processing]
7:43:16
jackdaniel
some other client responds with available types and clim iterates over these types if they are convertible to ptype
7:43:34
jackdaniel
if they are, the very same request is sent once again, but with appropriate type determined before
8:04:27
jackdaniel
I was thinking about more general "default" protocol for selection when I stumbled on the request-*-content
8:05:36
jackdaniel
by "my general" I mean: implemented for standard-port with a possible specialization for other ports (like clx)
8:05:56
loke
I was originally thinking about that, but I realised that there is always going to be _one_ backend, and they all have wildly different behaviour.
8:06:23
loke
So in CLX case, the actual CLX behaviour implements everything that is needed, so there is actually very little that can be extracted into a generic protocol.
8:07:12
loke
The only case is where there is no backend implementation available at all. For that, sure, there can (and should?) be a default implementation. But that implementation woul;wouldn't be used if the backend implements it.
8:22:04
jackdaniel
I won't interfere with your branch, I'll just put notes in a comment how I see it (you may use the snippets if you want)
8:25:29
jackdaniel
and yes, because it will imply moving some slots to standard-port. also (you probably have missed that), when you have removed text-selection protocols you didn't remove unused slots from standard-port anyway
8:26:14
jackdaniel
I can imagine that it provides complete support on instances where window manager is mcclim (i.e potential mezzano frame manager)
8:31:23
loke
Essentially, there is actually very little that can be put in the standard port. You could, I guess, store the current clipboard and selection objects in there, but I'm not sure I see the benefit in that.
8:32:14
loke
One may also want a backend to support multiple active clipboards (one per window, for example) in which case the selected object wouldn't even be stored in the port anymore.
8:33:29
loke
Yes. I thought of that. It wasn't obvious to me how it should be presented though. Let's say I "cut" an object in CLX-CLIM-Panel-1, then paste in xterm.
8:33:59
loke
At this point, the clipboard needs to be cleared in CLX-CLIM-Panel-1, otherwise there is an inceonsistency.
8:34:31
loke
So when you paste in CLIM, how do you choose whether you want to paste from the global clipbaord (Emacs, in this case), or the CLIM panel that just happens to have a "default" selection.
8:35:55
jackdaniel
clim can "swizzle" the coordinates (be it only for top-level or per-sheet), but this doesn't work perfect
8:38:22
jackdaniel
well, it is pretty dumb and buggy ^_^ mainly because our sheet transformations are suboptimal
8:38:43
loke
You're welcome to look at the code. https://github.com/mcclim/McCLIM/blob/clipboard2/Core/clim-basic/mirrors.lisp#L6
8:40:35
jackdaniel
loke: solution is that when you have integration with "external" window manager you define method which replaces a "default one"
8:42:00
loke
That's what the current API aims to do. Of course, the one place where that fails is if you have multiple frames with different backends, and you copy in one system (say, X11) and try to paste in another (Postscript?)
8:43:24
jackdaniel
(climb:request-selection-content clx-port ps-stream my-type) should do the trick, no?
8:44:45
loke
jackdaniel: sadly, no. The CLX backend assumed the stream has an xmirror (because it needs soemthing to deliver the event to). My previous experiment didn't have this behaviour, since it used an InputOnly window to manage event.
8:46:27
loke
So if you tried to do that, then you'd get an error when the CLX clipboard backend attempts to do sheet-direct-xmirror on the ps-stream
8:46:59
jackdaniel
right, but this is orthogonal to providing default mechanism in the same image for the same port
8:47:56
jdz
I find this a bit awkward is that doing the (with-room-for-graphics (t :height 33500)) itself works, and a new prompt is drawn after the output in the listener, and interacting still works; we only get an error after *entering* a new command.
8:48:43
loke
Either: the CLX backend detects that the stream isn't CLX, which means it needs another window to deliver events to (back to the InputInput window?)
8:48:45
jackdaniel
while problems with swizzling are known this is a good case for testing (and we may be able to fix it)
8:50:44
jdz
jackdaniel: My CLIM-fu is a bit lacking for creating a test-case that's isolated from interacting in clim-listener; I'll let you know if I manage to do that.
8:51:00
jackdaniel
loke: one more question: I say "paste", targets yields nothing compatible, what happens?
8:51:32
loke
jackdaniel: You mean if I request :HTML and the clipboard owner only has, say, :STRING?
8:52:46
loke
It's logical (somehow) since you can't assume that another applciaiton will ever reply to a clipboard request anyway.
8:55:03
jackdaniel
jdz: this could be an example, but it doesn't reproduce the issue for me: http://ix.io/1E6d
8:58:15
jackdaniel
I type (with-room-for-graphics (t :height 335000) (draw-rectangle* *standard-output* 0 0 10 10 :ink +red+))
9:04:09
jackdaniel
OK, if that does not help, please try the code I've sent you, first execute command Blah (which does w-r-f-g) and then the command Mueh which prints HELLO!