freenode/#clim - IRC Chatlog
Search
20:13:00
jackdaniel
loke: I've published clipboard3 branch (with changes which doesn't inlcude switch to synchronous requests)
1:32:14
loke
jackdaniel: First comment: I can't shift-middle-click in the text field anymore (still works in the interactor)
1:34:26
loke
jackdaniel: Second comment: I see you use the names :CLIPBOARD and :PRIMARY. These names come from X11, clearly. I think using :CLIPBOARD and :SELECTION makes more sense.
7:30:55
jackdaniel
loke: that saves me three forms in clx module (I can pass them over as thunk as they are now) ;) also since selection is quite x11 specific anyway I'd keep it called primary
7:42:43
jackdaniel
loke: that saves me three forms in clx module (I can pass them over as thunk as they are now) ;) also since selection is quite x11 specific anyway I'd keep it called primary
7:44:58
loke
jackdaniel: I always saw :BEFORE etc methods as being something you use to add soem additional (often unrelated) behaviour that is not dependent on the precise class (i.e. with :AROUND you can make things happen for parent class A, regardless of the specifics of methods specialised on the subclass). I dom't believe they should be used for primary functionality.
7:46:07
jackdaniel
primary behavior is storing the element in clim-specifc storeage (standard-port slot), we additionally announce to the world, that we are open for business
7:49:54
loke
I understand your artionale. My rationale for avoding :before methods in this case is than a subclass cannot override the behaviour of a before method. So if you want to make a specialisation of the clx-port that has different behaviour for copy and paste, you can't, because the :before method will run no matter what you do.
7:50:35
loke
(sure, you can hack around it with an :AROUND method, and clim does that in a few places. very ugly places if I may say so)
7:51:06
jackdaniel
arguably this is a case when you don't want a mixin which adds said before methdos. but I don't mind changing that
7:56:14
loke
There seems to be very little in the way of actual functional changes. It seems the core functionality remains.
7:57:11
jackdaniel
yes, but we squash new api to three methods and one event (and its two accessors)
7:59:01
jackdaniel
nb: you could have missed this change, but right now it is possible to publish object under many different presentation types
7:59:58
loke
Should we support X11's ability to support many different types (like the old CUT_BUFFER?)
8:00:52
loke
Anyway, synchronous paste has benefits and drawnbacks. I think what those tradeoffs are are very clear to both of us. As you know, in my early experiments I didn't want to use events, but rather a callback function. After discussion with you and beach, I settled on the events.
8:01:57
loke
Technically, X11 doesn't have a set number of types. You can do cut&paste with an atom called FOO_BLAH if you like. :-) Since you're just passing the keyword to the underlying X function, I think this would work with your API?
8:04:06
jackdaniel
loke: as you may see in clx-specific implementation, process-selection-request does this: (presentation-type (car (climb:selection-object-types stored-object))) and except that there is no change in reply
8:04:51
jackdaniel
when you use internal selections though presentation types map directly to presentation types
8:05:28
jackdaniel
so we map over acceptable vs candidate types to find first type which matches them (via presentation-subtypep)
8:06:39
jackdaniel
i.e published object has types (door wood thing) and requested types are (window door chair wood), then it will match door
8:07:50
loke
I was referring to the :CLIPBOARD, :PRIMARY thing. What happens if you try to publish to :SPECIAL_CLIPBOARD
8:08:27
loke
Seems like the X11 backend will fail because there is no method that specialises on :SPECIAL_CLIPBOARD?
8:09:16
loke
And that is probably the right thing to do, because I certainly don't want to publish to, say, :_NET_WM_NAME. If you do, publishing a string to that name would change the window title :-)