libera/#clim - IRC Chatlog
Search
7:40:37
lukego
Just now it seems like the next strategy for me to try is (1) Draw each part into a CLIM output record to know how big it is and the locations of relevant constituent parts (2) describe layout problem in SMT-LIB syntax and solve with Z3 (3) Place the parts by setting the positions of their output records according to the model from the solver.
7:41:26
lukego
Have done the basic "pack these boxes into this area such that they don't overlap" layout this way now and have to take a dog walk to think about how to express more useful layout constraints in this way
10:12:35
splittist
setf-ing the position of an output record alters the coordinates of that output record - except for draw-text-output-records, where it alters the graphics-state-transformation of the record. When replaying an output record, the medium-native-transformation (which is the sheet-native-transformation of +identity...+ if none) is used - except for text, which uses the medium-DEVICE-transformation (which, I think, eventually gets back to
10:13:21
splittist
Is there a reason for this difference in behaviour? Is it do with the extendable nature of text output records? (i.e that you can stuff more chars/strings into them)
10:17:06
jackdaniel
splittist: the spec has somewhat funny notion that by default only the text position is transformed
10:18:24
Inline
jackdaniel: do you know by chance why the visible space (editing space) in climacs is not obeying window maximizing/minimizing ?
10:18:52
jackdaniel
re graphics-state-* mixins - they represent different parts that may be recorded
10:19:32
jackdaniel
all graphics-state mixins are also mixed into medium to represent whole state in an uniform manner between records and mediums
10:20:49
jackdaniel
most output records doesn't mix in graphics-state-transformation, because the transformation is pre-applied
10:21:18
jackdaniel
that's not the case for the text, because it is the renderer who applies the transformation (you can't "pre-apply" the transformation to the text, only its starting position)
13:19:06
splittist
In my attempt to understand the full path from (format stream "thing") to "thing" appearing on a display device.
13:20:19
splittist
And towards-x and towards-y, and right to left and top to bottom etc. Now I'll turn my attention to the other end and try to understand how a key press turns into a command invocation.
13:20:22
jackdaniel
format -> stream-write-string -> seos-write-string -> draw-string -> medium-draw-string (:around for recording) -> medium-draw-string -> feed-string-to-the-renderer
13:21:25
jackdaniel
I think. re towards-x and towards-y - the specification of these is very unclear to me