freenode/#clim - IRC Chatlog
Search
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 :-)
8:11:19
jackdaniel
I was referring to the fact, that where you have presentation-type in publish-selection, it may be a list of presentation types
8:13:47
jackdaniel
selection protocol is orthogonal to presentations, so I don't see much controversy with it
8:15:18
loke
I'm just trying to think of cases where you could have more than one possible presentation type for a given object.
8:18:02
jackdaniel
I have given an example with abstract door/wood types. more practical one: you publish a rectangle which is a "documentation figure", "output-record" and "polygon"
8:20:36
jackdaniel
but objects and presentation types are very disjoint, you may say: (with-output-as-presentation (stream 3 :type 'string) (draw-rectangle …))
8:21:16
jackdaniel
note that 3 is not a string, but you will be able to select this rectangle if input context looks for a string (and it will blow later if you really expect string in there)
8:27:10
loke
But would you pass all of those types to the publish function? Wouldn't you want to publish as a given type, only?
8:27:10
loke
But then again, I'm pragmatic, and since it doesn't _remove_ functionality, I have no real issue with it.
8:50:47
jackdaniel
no for three reasons: 1. it needs to be remade to have clean commit history (right now I've just slapped a few commits on top to show what I have in mind), 2. I'm still thinking about synchronous api, 3. documentation is incomplete
8:51:28
jackdaniel
also, nomen omen, nobody has reviewed my code so far and I'm sure I've planted numerous issues in there
8:59:47
jackdaniel
also could anyone try to reason with me about process-next-event? (http://bauhh.dyndns.org:8000/clim-spec/8-1.html#_303)
9:27:02
jackdaniel
beach: maybe you will be interested in this non-unix operating system comparison to unix: https://bzdww.com/article/163937/ (fuchsia os)
9:28:02
jackdaniel
of course there is a lot of FUD in there, but some interesting insights and ideas too