freenode/#clim - IRC Chatlog
Search
9:30:52
jackdaniel
what is "the right thing" when we cahnge the frame-current-layout wrt calling LAYOUT-FRAME? should we call it with the previous width/height or should we allow it to recompute and resize the window?
9:34:14
loke
Hello... I need a suggestion: Since cut-and-paste-mixin is now only about selecting text in stream panes (which is not cutting) and pasting has been completely removed from it, the name of this class is very inappropriate.
9:36:25
loke
at the very least, I'm considering adding support for highlighting text with different fonts and such, and generating HTML from it
9:36:44
loke
Actually, now that I think about it, there is nothing stopping us from supporting selection of images either.
9:37:16
loke
One thing that is very specific to it, is that it supports highliting text (shift-drag) via the mouse.
9:37:37
loke
So selection-mixin is good. The alternative would be something like draggable-selection-mixin
9:37:50
beach
jackdaniel: Yes, I think the desired window size should be recomputed. The window manager still has the right to refuse to change the size, of course.
9:38:23
jackdaniel
also, layout-frame should take into consideration if the frame size is fixed on its own (even without width/height arguments)
9:45:19
loke
Another question: The current text selection code inverts the colours of the selected text, with the exception of the single case when the text is black on white background. In that case, the highlight is darg-red on ;oght-yellow background.
9:52:19
jackdaniel
can you suggest a viable, good looking alternative without full theming support for careful color palette?
9:54:16
loke
jackdaniel: I've experimented a bit. Just plain inversion looks better (imho) most of the time. (not perfect though, since it only affects text with default colours, so if you have, say, dark blue text it won't invert correctly)
9:54:59
loke
I have some ideas how to deal with that. I just wnated to know if there was some particular reason why it's the way it is, or if you'r eopen to conaging it
9:55:40
loke
Perhaps it can wait until we have some global configuration system in place, so that theming becomes viable.
9:55:47
jackdaniel
I can provide some historical background: former behavior was to change background, so for text with custom ink you couldn't see anything
9:56:39
loke
jackdaniel: Ah right. That makes sense. It's bacailly what I oberved too. I'm playing around with overriding text colours when drawing the highlight. It's questionable if it's worth the effort though.
9:57:25
jackdaniel
as I envision it for the future reference is to have half-transparent rectangle drawn on the selection
10:25:02
loke
jackdaniel: Another question: I'm building a basic HTML renderer (only handles stuff like bold/italics, etc). I want to use it in the clipboard demo when pasting rich text.
10:31:15
jackdaniel
I don't think it is, but I have no strong arguments against that, only the dependency complexity concern
10:33:23
jackdaniel
nb: we should think about stripping some dependencies putting some extensions out of direct mcclim dependency list (so they can be added separately)
10:46:07
loke
jackdaniel: Fair enough. It's not overly important. I'll just display the html in, well, html form :-)
11:24:33
loke
Can anyone take a look at this form? I sometimes get booleal logic wrong, and I just want to ake sure I read this right./
11:24:51
loke
https://github.com/mcclim/McCLIM/blob/clipboard-experiments/Core/clim-basic/stream-input.lisp#L220
11:25:31
loke
Am I right is asserting that the (and (gadgetp...) (gadget-active-p ...)) part is a noop?
11:26:04
loke
because whenever that one is true, the second half of the OR will also be true, correct?