freenode/#clim - IRC Chatlog
Search
10:30:50
scymtym
loke: do you think your friend who made the McCLIM SVG icon would be happy with this commit: https://github.com/scymtym/McCLIM/commit/483c49af273832b269a455a526eafa9beba1bbca
10:37:01
jackdaniel
I'm confused, svg file in the commit is different from the logo in the commit message
10:56:30
scymtym
jackdaniel: do you mean the filename? the content seems (or at least looks) identical
11:18:37
scymtym
the left image is probably mcclim-logo-quadratic.png which is derived (that is modified) from the original SVG and rasterized. i did not rasterize the original image. maybe i should explain that more clearly
11:42:25
scymtym
in the proposed protocol, an icon is a CLIM-EXTENSIONS:IMAGE-PATTERN. the spec entry for DEFINE-APPLICATION-FRAME says ":icon pixmap specifies a pixmap to be displayed by the host's window manager when the frame is iconified." so i will have to look into that
12:54:46
scymtym
i guess i did that because the route from image files to pixmaps is much less direct than for image patterns
13:06:18
jackdaniel
pixmap is (as far as I understand) the abstraction meant as something backend-specific, something to pass images in "native" format
13:23:44
scymtym
yes, pixmap would need allocate, deallocate and an extra conversion step involving a medium, so that doesn't make too much sense
13:24:45
scymtym
btw, the rest of the changes is also in that branch: https://github.com/scymtym/McCLIM/commits/frame-icons . i'm tying up a few lose ends
13:37:07
jackdaniel
that would be great, I have another batch with changes (which also fix number of issues) for menus
14:42:02
scymtym
jackdaniel: is :inherit-menu {:menu,:keystrokes} completely new or is there evidence for it in other parts of the spec?
14:45:27
jackdaniel
it is not anywhere in the spec (I've modified appropriate entries) although it was part of McCLIM implementation and it is part of clim-tos (and specified in clim-ug by franz)
14:47:46
jackdaniel
also the spec was contradicting itself regarding whether keystrokes are inherited or not, that is fixed too
14:51:53
scymtym
yes, i'm currently reading the spec changes. i'm not against them, but maybe :INHERIT-MENU should continue to accept true values besides T, :MENU and :KEYSTROKES
14:52:52
jackdaniel
I think that because we differentiate between different true values, accepting /anything/ would be bad
14:58:51
scymtym
if a user can put any form i would argue strongly in favor of keeping the generalized boolean
15:00:07
scymtym
somebody could have :inherit-menu (find :super-menus features) or whatever in their code and it would break
15:01:25
scymtym
to be clear, i wouldn't mind if we writing a new specification, but we are talking about an incompatible change to the specification if i understand correctly
15:07:59
jackdaniel
third is that if we differentiate between generalized-boolean values, then it is not generalized-boolean anymore, so semantically that would be incorrect
15:14:28
scymtym
after the specification change, MAP-OVER-COMMAND-TABLE-KEYSTROKES has the require signature but does not (yet?) implement the full specified behavior, right?
15:17:27
jackdaniel
yes, first I've added expected behavior tests (I've agonised over them for a few days), then then specification and finally I've fixed the tested behavior
15:19:23
jackdaniel
it is basically part of the implementation for the keystroke combos (and I'm surprised I've commited it)
17:46:10
jackdaniel
scymtym: I've addressed most comments, I had some objections in a few -- I'll attend to them if you disagree tomorrow