freenode/#clim - IRC Chatlog
Search
11:20:47
jackdaniel
scymtym: I think that using default '* is more consistent with other standard types (and with deftype of course)
11:25:21
jackdaniel
I had a brief idea to have region parameter instead of xy, but that feels like overengineering
12:51:47
scymtym
a region parameter would allow an input context (blank-area :sheet SHEET :region REGION) and subtyping could make sure that only clicks within that region would be acceptable. but yeah, maybe leave that for later
12:53:05
jackdaniel
I think that if we decide on x/y vs region once, we need to commit to it for sake of compatibility (assuming we document it or examplify in demos)
13:58:00
jackdaniel
that's only if we want to implement it -- I've rejected the idea (when I was thinking about it) because I've concluded that if someone wants a region on a sheet, then it should be properly presented with a distinct presentation type
13:58:33
jackdaniel
it is possible to construct artificial use cases - I didn't come up with a practical one though
14:34:02
scymtym
did you have a look at the documentation? if it seems ok to you, i will test a little and then update the pull request or push to master, depending on whether you want to review again
14:40:36
jackdaniel
I did not, I'll take a look. in the meantime you may update the pull request and I'll take another look
14:43:56
jackdaniel
I think that the last paragraph is not necessary because of how presentation types are defined (the part about more parameters being subtype of fewer)
14:44:50
scymtym
do you think it is obvious enough what blank-area and (blank-area :sheet sheet) mean in terms of subtyping?
14:46:35
jackdaniel
because it is not obvious (with-presentation-parameters … ) won't cut it, because x is not exported from the clim package
14:48:10
scymtym
i wish i could at least do (destructuring-bind (&key sheet x y) (get-parameters (presentation-type presentation)))
14:49:01
scymtym
i think presentation type parameters are fine, just that you can't get them without binding things is strange
14:49:58
scymtym
yes, as i said, i like presentation type parameters. but the standard should have something like CLIM-INTERNALS::DECODE-PARAMETERS
14:51:23
scymtym
i thought, maybe we could allow a destructuring lambda list in WITH-PRESENTATION-TYPE-DECODED
14:56:06
scymtym
but that already the case with WITH-PRESENTATION-TYPE-DECODED if you use the parameter binding for anything
14:57:23
jackdaniel
generally decoding presentation types is mostly meant for presentation generic functions, users should be mostly concerned with objects
14:59:18
jackdaniel
from the documentation part you wrote, that *null-presentation* is a singleton object, however that's not what the spec says -- it says that "null presentation" is a singleton object associated with the type
15:00:09
jackdaniel
and you've mentioned something about other part of the spec that suggests, that the presentation may be eq-compared with *null-presentation*, so that's probably a braino in the spec too
15:01:31
scymtym
maybe this: "If \cl{frame-input-context-button-press-handler} is called when the pointer is not over any applicable presentation, \cl{throw-highlighted-presentation} must be called with a presentation of \cl{*null-presentation*}."
15:02:39
jackdaniel
to play devils advocate, that could be here to allow dynamically binding *null-presentation* to a desired presentation :)
15:03:14
scymtym
they don't say you can't bind *NULL-PRESENTATION* to a different instance of the correct type, for example
15:03:50
jackdaniel
to be honest I've better liked a design where blank-area was a standard-class, and the only presentation parameter was a sheet (and to query the object for the sheet and position)
15:04:34
jackdaniel
(alternatively parameters could be sheet and region, while the object has the exact x/y position)
15:05:08
scymtym
how would you provide access to the position? i think POINTER-EVENT-* is not suitable
15:06:04
jackdaniel
throwing the null presentation is a result of a pointer event (we could store as the object an event - possibly synthesized if necessity demands)
15:06:06
scymtym
oh, and same for the sheet. if the object is not the sheet, it would be necessary to extract the sheet from the object as well
15:07:24
scymtym
so your proposal is object = pointer-event instance, parameters = (&optional sheet)?
15:08:34
jackdaniel
sure, or (&key sheet region) or (&optional sheet region) etc, or object = blank-area with a slot with a reader (event object)
15:09:41
jackdaniel
having blank-area to by of type blank-area leads to consing some more, but class-based presentations seem to be easier to reason about (and there is no reason to not have it of a certain class)
15:10:44
jackdaniel
and while presentation-types derived from t are really cool for some use cases - this is not one of them
15:37:17
scymtym
after thinking some more on the way, my preferred variant would be object = event-object (original or synthesized), presentation type = (blank-area &key sheet region) such that (subtypep (blank-area :region r₁) (blank-area :region r₂) iff (region-contains-region-p r₂ r₁). the presentation instance resulting from an blank area click with event e would have the object e and the type `(blank-area
15:40:38
jackdaniel
that works for me too, then probing position/sheet would be (pointer-event-sheet destination-object) etc
15:41:26
jackdaniel
so fairly similar to the original code, but with the blank-area /not/ being a standard class
15:43:00
scymtym
yes, i think (good) new idea is having the region so the input context can restrict sensitivity to particular areas. and of course, sheets would work as before, i omitted that because it wasn't a contested point
15:45:04
scymtym
you could even argue that the sheet, conceptually, has a pointer event presented with type BLANK-AREA in its output history for every point and you can click any of them :)
16:07:41
scymtym
passing :x1 etc to STANDARD-PRESENTATION apparently did nothing. probably because it is a sequence output record without children
16:10:40
jackdaniel
right, that is a leftover of my initial attempt of passing the position of the presentation type. that said, it does one thing: it binds the slot
16:15:52
scymtym
i haven't looked yet, but at least the bounding rectangle of the presentation is 0:0 0:0 instead of the pass :x1 etc, so /something/ doesn't work
16:32:18
scymtym
seems to work. for example, accepting `(blank-area :sheet ,SHEET :region ,(make-rectangle 0 50 100 100)) only makes the bottom half of the sheet sensitive
16:32:33
jackdaniel
if I had to guess, that would be because the standard-presentation inherits from the compound-output-record (accepting :x-position and :y-position)
16:32:56
jackdaniel
basic-output-record is a superclass of compound-output-record, and it uses x-position/y-position to initialize the bounding rectangle
16:33:35
jackdaniel
and regarding the bounding-rectangle of a compound-output-record, it is / should be (did not check) computed based on its children and fallback to its position if none
16:36:34
scymtym
we could add a rectangle output record as a child to specify the bounding rectangle. but that would be more consing
17:00:06
jackdaniel
I think that this would require more thought (and is not that much relevant to blank-area neverless)
18:32:32
scymtym
jackdaniel: would you mind turning the demo explanation into a label pane? the stream pane causes layout issues that i would prefer not to debug right now