freenode/#clim - IRC Chatlog
Search
10:05:48
jackdaniel
One way to think about it is that repaint is a separate thing. If you have output recording then replay repaints all output records which need to be repainted. Redisplay removes all records and creates them anew - you need to know what is to be displayed and you must record everything again. At least that's how I understand things at the moment.
14:13:12
jackdaniel
huh, I'm trying to head or tails of sheet transformations and it seems that standard have ingrined support for device-specific sheets (just as I have suggested McCLIM should have) - good, less work for later
14:14:24
jackdaniel
that said I've identified problem, but I'm not sure yet how to solve it without breaking things: we assume that mirrored sheet coordinates are the same as the window (so mirrored-translation and sheet-transformation have the same object)
14:14:43
jackdaniel
but for sheets which have only graft as a parent these are not relative coordinates but absolute
14:17:02
jackdaniel
I've also noticed somewhat superfluous transformations in the object: we have device, native, sheet and mirrored transformations. I bet at least two of these four can be merged so we have three (and in best case we may end with 2 transformations overall)
14:47:55
jackdaniel
more code I read the distinction becomes more clear: there are read-write programmers and write-only programmers
14:48:44
jackdaniel
first ones are careful and write code slowly but usually codebase doesn't get worse (or gets slightly worse in exchange for some other improvement, like a feature or bugfix)
14:49:51
jackdaniel
and there are write-only programmers, who who are fast to implement fixes and features on top of the existing code using things available (that often results in duplicated code and parallel passages doing essantially same thing in a slightly different context)
14:52:39
nyef
jackdaniel: I think that there's read-write code and write-only code, but the programmer thing is a bit more nuanced.
14:53:53
nyef
When faced with time pressure, a good programmer can still end up producing "write-only" code.
14:54:40
jackdaniel
I'm not saying, that write-only coding is a bad, I think it is great for building prototypes and understanding
14:54:45
nyef
But when given the opportunity, the better programmers will tend to consolidate what they've produced.
15:59:25
slyrus
jackdaniel: I see you've been looking at the various CLIM display transformations. You've probably seen it before, but if you haven't check out my zoom-viewer for a use case I'd really like to see supported
16:01:20
jackdaniel
I'm thinking about replacing slot-names for native-transformation and device-transformation slots to #native-transformation and #device-transformation (or if convention is not good - to cached-device-transformation and cached-native-transformation
16:02:27
slyrus
what's the story with these slots? are they cached for mcclim internals to use or for user code?
16:03:07
jackdaniel
user have methods like (sheet-device-transformation sheet) (which are not setfable)
16:03:40
jackdaniel
%foo just means internal to me. I'll use full name then – cached-native-transformation
16:04:24
jackdaniel
(I want to make it obvious, because next person may waste considerable amount of time acting on wrong assumption that these slots hold actual thing - like I did)
17:32:09
jackdaniel
slyrus: did you think about specializing redisplay-output-record on your zooming pane and "stealing" output-recoreds from a "normal" stream to draw them? just a loose thought
17:55:00
scymtym
ACTION is also interested in zooming. for the flamegraph pane in https://techfak.de/~jmoringe/clamegraph2.png (and most of the required SBCL changes have landed now)
22:00:55
fittestbits
presentation-replace-input builds a file name string using directory-namestring and file-namestring so no host name.
22:01:33
fittestbits
However, filename-completer uses namstring which includes a hostname in some cases.