- mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] StudlyCaps directories
by Christophe Rhodes 05 Aug '05

05 Aug '05

Um, how come no-one's noticed this before? With a case-insensitive filesystem (such as is found, I believe, on at least some PowerPCs that seem absurdly popular these days), odd things happen to the CVS repository. I see, in the McCLIM directory, lisp-dep/ and Lisp-Dep/ looks/ and Looks/ examples/ and Examples/ Backends/postscript and Backends/PostScript and this has just caused real problems over here, as we attempted to extract diffs for Backends/PostScript/ whereas we had the CVS/Entries file for Backends/postscript... Is it possible to remove these duplicatedly-named directories? Cheers, Christophe

4 3

[mcclim-devel] Would McCLIM benefit from this pretty printer patch for CMUCL/SBCL?
by Matthias Koeppe 04 Aug '05

04 Aug '05

Dear McCLIM list, I have worked on a patch for the pretty printer of CMUCL and SBCL that helps support the new presentation-like features of SLIME in conjunction with the pretty printer. I'd like to ask if someone of you could comment on whether this patch would be useful for McCLIM as well. If so, this would be another reason for including it at as a core extension into SBCL and CMUCL. The patch implements a feature of the Allegro CL pretty printer, which is called SCHEDULE-ANNOTATION there. This function queues arbitrary functions ("annotations") in the pretty-printing stream in sequence with the characters that are printed to the stream, until the stream has decided on the concrete layout. When the characters are forwarded to the target stream, the annotations are invoked at the right position. In my changes to SLIME, I use the function as follows. I believe (without knowing much about CLIM) that it should be possible to use similar code to send CLIM presentation data (output records?), font changes, etc. cleanly through pretty-printing streams. ;; If we are printing to an XP (pretty printing) stream, printing the ;; escape sequences directly would mess up the layout because column ;; counting is disturbed. Use "annotations" instead. #+allegro (defun write-annotation (stream function arg) (if (typep stream 'excl:xp-simple-stream) (excl::schedule-annotation stream function arg) (funcall function arg stream nil))) #+cmu (defun write-annotation (stream function arg) (if (typep stream 'pp:pretty-stream) (pp::enqueue-annotation stream function arg) (funcall function arg stream nil))) #+sbcl (defun write-annotation (stream function arg) (if (typep stream 'sb-pretty::pretty-stream) (sb-pretty::enqueue-annotation stream function arg) (funcall function arg stream nil))) #-(or allegro cmu sbcl) (defun write-annotation (stream function arg) (funcall function arg stream nil)) (defstruct presentation-record (id) (printed-p)) (defun presentation-start (record stream truncatep) (unless truncatep ;; Don't start new presentations when nothing is going to be ;; printed due to *print-lines*. (let ((pid (presentation-record-id record))) (cond (*use-dedicated-output-stream* (write-string "<" stream) (prin1 pid stream) (write-string "" stream)) (t (force-output stream) (send-to-emacs `(:presentation-start ,pid))))) (setf (presentation-record-printed-p record) t))) (defun presentation-end (record stream truncatep) (declare (ignore truncatep)) ;; Always end old presentations that were started. (when (presentation-record-printed-p record) (let ((pid (presentation-record-id record))) (cond (*use-dedicated-output-stream* (write-string ">" stream) (prin1 pid stream) (write-string "" stream)) (t (force-output stream) (send-to-emacs `(:presentation-end ,pid))))))) (defun presenting-object-1 (object stream continue) "Uses the bridge mechanism with two messages >id and <id. The first one says that I am starting to print an object with this id. The second says I am finished" (if (and *record-repl-results* *can-print-presentation* (slime-stream-p stream)) (let* ((pid (swank::save-presented-object object)) (record (make-presentation-record :id pid :printed-p nil))) (write-annotation stream #'presentation-start record) (multiple-value-prog1 (funcall continue) (write-annotation stream #'presentation-end record))) (funcall continue))) I am including the pretty-printer patch (for SBCL) at the end of this message. Cheers, -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe diff -u /home/mkoeppe/s/slime/sbcl/pprint.lisp.orig /home/mkoeppe/s/slime/sbcl/pprint.lisp --- /home/mkoeppe/s/slime/sbcl/pprint.lisp.orig 2005-07-19 22:56:54.000000000 +0200 +++ /home/mkoeppe/s/slime/sbcl/pprint.lisp 2005-07-24 19:27:29.000000000 +0200 @@ -89,7 +89,12 @@ (queue-tail nil :type list) (queue-head nil :type list) ;; Block-start queue entries in effect at the queue head. - (pending-blocks nil :type list)) + (pending-blocks nil :type list) + ;; Queue of annotations to the buffer. + ;; Annotations are first put into the queue of pending operations. + ;; Just before output they are put into the queue of annotations. + (annotations-tail nil :type list) + (annotations-head nil :type list)) (def!method print-object ((pstream pretty-stream) stream) ;; FIXME: CMU CL had #+NIL'ed out this code and done a hand-written ;; FORMAT hack instead. Make sure that this code actually works instead @@ -360,6 +365,11 @@ (:section-relative (values t t))) (enqueue stream tab :sectionp sectionp :relativep relativep :colnum colnum :colinc colinc))) + +(defstruct (annotation (:include queued-op)) + (handler (constantly nil) :type function) + (record)) + ;;;; tab support @@ -452,6 +462,101 @@ (unless (eq new-buffer buffer) (replace new-buffer buffer :end1 end :end2 end)))))) +;;;; Annotation support + +(defun enqueue-annotation (stream handler record) + #!+sb-doc + "Insert an annotation into the pretty-printing stream STREAM. +HANDLER is a function, and RECORD is an arbitrary datum. The +pretty-printing stream conceptionally queues annotations in sequence +with the characters that are printed to the stream, until the stream +has decided on the concrete layout. When the characters are forwarded +to the target stream, annotations are invoked at the right position. +An annotation is invoked by calling the function HANDLER with the +three arguments RECORD, TARGET-STREAM, and TRUNCATEP. The argument +TRUNCATEP is true if the text surrounding the annotation is suppressed +due to line abbreviation (see *PRINT-LINES*). +If STREAM is not a pretty-printing stream, simply call HANDLER +with the arguments RECORD, STREAM and nil." + (if (pretty-stream-p stream) + (enqueue stream annotation :handler handler + :record record) + (funcall handler record stream nil))) + +(defun re-enqueue-annotation (stream annotation) + #!+sb-doc + "Insert ANNOTATION into the queue of annotations in STREAM." + (let* ((annotation-cons (list annotation)) + (head (pretty-stream-annotations-head stream))) + (if head + (setf (cdr head) annotation-cons) + (setf (pretty-stream-annotations-tail stream) annotation-cons)) + (setf (pretty-stream-annotations-head stream) annotation-cons))) + +(defun re-enqueue-annotations (stream end) + #!+sb-doc + "Insert all annotations in STREAM from the queue of pending +operations into the queue of annotations. When END is non-nil, +stop before reaching the queued-op END." + (loop for tail = (pretty-stream-queue-tail stream) then (cdr tail) + while (and tail (not (eql tail end))) + when (annotation-p (car tail)) + do (re-enqueue-annotation stream (car tail)))) + +(defun dequeue-annotation (stream &key end-posn) + #!+sb-doc + "Dequeue the next annotation from the queue of annotations of STREAM +and return it. Return nil if there are no more annotations. When +:END-POSN is given and the next annotation has a posn greater than +this, also return nil." + (let ((next-annotation (car (pretty-stream-annotations-tail stream)))) + (when next-annotation + (when (or (not end-posn) + (<= (annotation-posn next-annotation) end-posn)) + (pop (pretty-stream-annotations-tail stream)) + (unless (pretty-stream-annotations-tail stream) + (setf (pretty-stream-annotations-head stream) nil)) + next-annotation)))) + +(defun invoke-annotation (stream annotation truncatep) + (let ((target (pretty-stream-target stream))) + (funcall (annotation-handler annotation) + (annotation-record annotation) + target + truncatep))) + +(defun output-buffer-with-annotations (stream end) + #!+sb-doc + "Output the buffer of STREAM up to (excluding) the buffer index END. +When annotations are present, invoke them at the right positions." + (let ((target (pretty-stream-target stream)) + (buffer (pretty-stream-buffer stream)) + (end-posn (index-posn end stream)) + (start 0)) + (loop + for annotation = (dequeue-annotation stream :end-posn end-posn) + while annotation + do + (let ((annotation-index (posn-index (annotation-posn annotation) + stream))) + (when (> annotation-index start) + (write-string buffer target :start start + :end annotation-index) + (setf start annotation-index)) + (invoke-annotation stream annotation nil))) + (when (> end start) + (write-string buffer target :start start :end end)))) + +(defun flush-annotations (stream end truncatep) + #+sb-doc + "Invoke all annotations in STREAM up to (including) the buffer index END." + (let ((end-posn (index-posn end stream))) + (loop + for annotation = (dequeue-annotation stream :end-posn end-posn) + while annotation + do (invoke-annotation stream annotation truncatep)))) + + ;;;; stuff to do the actual outputting (defun ensure-space-in-buffer (stream want) @@ -520,10 +625,11 @@ (ecase (fits-on-line-p stream (block-start-section-end next) force-newlines-p) ((t) - ;; Just nuke the whole logical block and make it look - ;; like one nice long literal. + ;; Just nuke the whole logical block and make it look like one + ;; nice long literal. (But don't nuke annotations.) (let ((end (block-start-block-end next))) (expand-tabs stream end) + (re-enqueue-annotations stream end) (setf tail (cdr (member end tail))))) ((nil) (really-start-logical-block @@ -536,7 +642,9 @@ (block-end (really-end-logical-block stream)) (tab - (expand-tabs stream next)))) + (expand-tabs stream next)) + (annotation + (re-enqueue-annotation stream next)))) (setf (pretty-stream-queue-tail stream) tail)) output-anything)) @@ -582,13 +690,17 @@ (if last-non-blank (1+ last-non-blank) 0))))) - (write-string buffer target :end amount-to-print) + (output-buffer-with-annotations stream amount-to-print) + (flush-annotations stream amount-to-consume nil) (let ((line-number (pretty-stream-line-number stream))) (incf line-number) (when (and (not *print-readably*) (pretty-stream-print-lines stream) (>= line-number (pretty-stream-print-lines stream))) (write-string " .." target) + (flush-annotations stream + (pretty-stream-buffer-fill-pointer stream) + t) (let ((suffix-length (logical-block-suffix-length (car (pretty-stream-blocks stream))))) (unless (zerop suffix-length) @@ -640,8 +752,7 @@ (buffer (pretty-stream-buffer stream))) (when (zerop count) (error "Output-partial-line called when nothing can be output.")) - (write-string buffer (pretty-stream-target stream) - :start 0 :end count) + (output-buffer-with-annotations stream count) (incf (pretty-stream-buffer-start-column stream) count) (replace buffer buffer :end1 new-fill-ptr :start2 count :end2 fill-ptr) (setf (pretty-stream-buffer-fill-pointer stream) new-fill-ptr) @@ -650,9 +761,10 @@ (defun force-pretty-output (stream) (maybe-output stream nil) (expand-tabs stream nil) - (write-string (pretty-stream-buffer stream) - (pretty-stream-target stream) - :end (pretty-stream-buffer-fill-pointer stream))) + (re-enqueue-annotations stream nil) + (output-buffer-with-annotations stream + (pretty-stream-buffer-fill-pointer stream))) + ;;;; user interface to the pretty printer

4 6

[mcclim-devel] McCLIM's dialog.lisp and ACL 7.0
by Robert P. Goldman 03 Aug '05

03 Aug '05

When I tried to recompile McCLIM on ACL 7.0 it crashed because there were some ignorable declarations applied to functions. These are specifically permitted by the ANSI spec. I was a little surprised by this --- I haven't before seen a case where ACL's conformance has degraded with a new version. Any one else seen this? Thanks, R

1 0

[mcclim-devel] Re: international text-style support
by Christophe Rhodes 02 Aug '05

02 Aug '05

[ a very long time ago, in the context of supporting complicated international scripts ] Gilbert Baumann <unk6(a)rz.uni-karlsruhe.de> writes: > Brian Spilsbury writes: > > I have implement (somewhat primitive) international text-style support. > > [...] > > This sounds like a somewhat reasonable design to me, although I would > very much prefer if we could move the fontset logic into the frontend > by coming up with a sort of font protocol. So, now, we (at Goldsmiths) have a need for a specific font. At the moment, we have hacked in support to our application using MAKE-DEVICE-FONT-TEXT-STYLE and some extreme hackiness in CLIM-CLX::TEXT-STYLE-TO-X-FONT; the device-font-text-style support in current CVS is ... not extensive, which is not really surprising given that the spec is approximately equally non-extensive. It tickled my memory, though, and I dug up this proposal: > Something like this: > > A font is a mapping from glyph names (indicies) to glyphs. Fonts > have additional attributes like name, weight, an encoding, a > language and so on. Glyphs have metrics and are drawable to > individual media. > > FONT protocol class > > FONT-NAME font method > FONT-WEIGHT font method > FONT-SLANT font method > FONT-... font method > > The individual typographical properties of the font. > > SCALE-FONT font size -> font method > > Scales the font to a new size. > [Q1: Unit for size?] > [Q2: Should this affect metrics?] > > FONT-SIZE font method > > Returns the size of the font. > > TRANSFORM-FONT font transformation -> font method > > Applies a affine transformation to the font. Each glyph drawn with > the returned font are then drawn under the transformation. This > does not affect the individual glyph metrics. > > FONT-TRANSFORMATION font -> transformation method > > Returns the transformation of the font font. > > FONT-GLYPH-METRICS font glyph method > -> width ascent descent left-bearing right-bearing > > Returns the fonts glyph metrics. To calculate the metrics of > glyphs as drawn my draw-glyph the transformation of the font has > to be applied to the returned values. > > [This is to keep the glyph-metrics as scalars instead of making > each metric into a vector]. > > width should not be negative in case of RTL script, since > typesetting from right to left is consided to be a property of a > text-style; likewise left-bearing bearing on the left hand side > as right bearing is bearing on the right hand size. > > Q4: Is there something like top-bearing, bottom-bearing for fonts > designed towards top-to-bottom scripts? > > > FONT-KERNING font glyph-1 glyph-2 method > > Returns the kerning to be applied when typesetting glyph-1 left of > glyph-2. > > DRAW-GLYPH medium font glyph x y method > > [Q3: Interaction with general designs? Ideally we would make glyphs > into designs itself]. > > A text-style is a mapping of chracter sequences to font, glyph, > position triples for drawing. A text-style then might refer to > multiple fonts thus forming a fontset. > > Each medium then knows its available fonts. These can be queried by > the frontend and combined into a text style. > > As you can see there are some questions and I am not entirely sure how > things should really look like. Nor am I. I don't suppose anyone else has had thoughts in the last three years? We need: a way of specifying that we want to draw text using a specific font (in our case, a FreeType font for tablature) at a specific size. If that's not a DEVICE-FONT-TEXT-STYLE, I don't know where else it should go, but it does imply that a DEVICE-FONT has size. I'm away from my workstation, but tomorrow I'll send patches showing what we're currently doing. Cheers, Christophe

1 1

[mcclim-devel] question about presentation method for pathnames
by rpgoldman＠real-time.com 29 Jul '05

29 Jul '05

The presentation method for pathnames is defined this way: (define-presentation-method present (object (type pathname) stream (view textual-view) &key acceptably for-context-type) (declare (ignore acceptably for-context-type)) (princ object stream)) At least in one app I've been working on, when I make the default for accepting be a LISP pathname, the system displays the s-expression form, rather than a more intuitive "real" Unix pathname. So I was wondering if it mightn't be better to use namestring than princ. But this won't work in some situations, because the pathname might not be complete (e.g., it's a default, so it has only a directory and a type and no filename). I'm afraid I don't understand pathnames (I only know enough to know that they almost never do what I want!) well enough to understand what would be a good substitute for princ... Thanks, r

1 0

[mcclim-devel] Postscript partial ellipses
by Christophe Rhodes 29 Jul '05

29 Jul '05

Hi, I believe the Postscript backend needs this patch. Is anyone other than us using it at the moment who could check my reasoning? Cheers, Christophe Index: Backends/PostScript/graphics.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/PostScript/graphics.lisp,v retrieving revision 1.12 diff -u -r1.12 graphics.lisp --- Backends/PostScript/graphics.lisp 3 Dec 2004 11:42:43 -0000 1.12 +++ Backends/PostScript/graphics.lisp 29 Jul 2005 15:20:39 -0000 @@ -147,8 +147,11 @@ (cy (point-y center)) (tr (make-transformation ndx2 ndx1 ndy2 ndy1 cx cy)) (circle (untransform-region tr ellipse)) - (start-angle (or (ellipse-start-angle circle) 0)) - (end-angle (or (ellipse-end-angle circle) (* 2 pi)))) + ;; we need an extra minus sign because the rotation + ;; convention for Postscript differs in chirality from the + ;; abstract CLIM convention. -- CSR, 2005-07-29 + (start-angle (or (- (ellipse-end-angle circle)) 0)) + (end-angle (or (- (ellipse-start-angle circle)) (* 2 pi)))) (write-string (if filled "true " "false ") stream) (write-angle stream (if (< end-angle start-angle) (+ end-angle (* 2 pi))

1 0

[mcclim-devel] Re: [Sbcl-devel] Would McCLIM benefit from this pretty printer patch for CMUCL/SBCL?
by Matthias Koeppe 29 Jul '05

29 Jul '05

Raymond Toy <raymond.toy(a)ericsson.com> writes: >>>>>> "Matthias" == Matthias Koeppe <mkoeppe(a)merkur.math.uni-magdeburg.de> writes: > Matthias> Dear McCLIM list, > Matthias> I have worked on a patch for the pretty printer of CMUCL and SBCL that > Matthias> helps support the new presentation-like features of SLIME in > Matthias> conjunction with the pretty printer. > > I'm not familiar with slime's presentations, but I was going to look > into incorporating your patch. > > However, in light of Paolo's comments, I'm holding off until this is > resolved. I have now taken a look at Gilbert Baumann's pretty printer patch (http://bauhh.dyndns.org:8000/mcclim/pprint/) that Paolo pointed out. As far as I can see, the changes there could be easily re-implemented in terms of the more general "annotations" feature implemented in my patch. The only thing that is not covered by my patch is the hooks into START-LOGICAL-BLOCK, END-LOGICAL-BLOCK, PPRINT-LOGICAL-BLOCK. These changes are independent of my patch. (I am including below a new version of the patch for CMUCL that includes docstrings.) Cheers, -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe diff -u /home/mkoeppe/s/slime/cmucl/pprint.lisp.orig /home/mkoeppe/s/slime/cmucl/pprint.lisp --- /home/mkoeppe/s/slime/cmucl/pprint.lisp.orig 2005-07-21 22:30:50.000000000 +0200 +++ /home/mkoeppe/s/slime/cmucl/pprint.lisp 2005-07-29 00:11:19.000000000 +0200 @@ -109,6 +109,10 @@ ;; ;; Block-start queue entries in effect at the queue head. (pending-blocks nil :type list) + ;; + ;; Queue of annotations to the buffer + (annotations-tail nil :type list) + (annotations-head nil :type list) ) (defun %print-pretty-stream (pstream stream depth) @@ -381,6 +385,10 @@ (enqueue stream tab :sectionp sectionp :relativep relativep :colnum colnum :colinc colinc))) +(defstruct (annotation (:include queued-op)) + (handler (constantly nil) :type function) + (record)) + ;;;; Tab support. @@ -472,6 +480,91 @@ (replace new-buffer buffer :end1 end :end2 end)))))) +;;;; Annotations support. + +(defun enqueue-annotation (stream handler record) + "Insert an annotation into the pretty-printing stream STREAM. +HANDLER is a function, and RECORD is an arbitrary datum. The +pretty-printing stream conceptionally queues annotations in sequence +with the characters that are printed to the stream, until the stream +has decided on the concrete layout. When the characters are forwarded +to the target stream, annotations are invoked at the right position. +An annotation is invoked by calling the function HANDLER with the +three arguments RECORD, TARGET-STREAM, and TRUNCATEP. The argument +TRUNCATEP is true if the text surrounding the annotation is suppressed +due to line abbreviation (see *PRINT-LINES*). +If STREAM is not a pretty-printing stream, simply call HANDLER +with the arguments RECORD, STREAM and nil." + (enqueue stream annotation :handler handler + :record record)) + +(defun re-enqueue-annotation (stream annotation) + "Insert ANNOTATION into the queue of annotations in STREAM." + (let* ((annotation-cons (list annotation)) + (head (pretty-stream-annotations-head stream))) + (if head + (setf (cdr head) annotation-cons) + (setf (pretty-stream-annotations-tail stream) annotation-cons)) + (setf (pretty-stream-annotations-head stream) annotation-cons))) + +(defun re-enqueue-annotations (stream end) + "Insert all annotations in STREAM from the queue of pending +operations into the queue of annotations. When END is non-nil, +stop before reaching the queued-op END." + (loop for tail = (pretty-stream-queue-tail stream) then (cdr tail) + while (and tail (not (eql (car tail) end))) + when (annotation-p (car tail)) + do (re-enqueue-annotation stream (car tail)))) + +(defun dequeue-annotation (stream &key end-posn) + "Dequeue the next annotation from the queue of annotations of STREAM +and return it. Return nil if there are no more annotations. When +:END-POSN is given and the next annotation has a posn greater than +this, also return nil." + (let ((next-annotation (car (pretty-stream-annotations-tail stream)))) + (when next-annotation + (when (or (not end-posn) + (<= (annotation-posn next-annotation) end-posn)) + (pop (pretty-stream-annotations-tail stream)) + (unless (pretty-stream-annotations-tail stream) + (setf (pretty-stream-annotations-head stream) nil)) + next-annotation)))) + +(defun invoke-annotation (stream annotation truncatep) + (let ((target (pretty-stream-target stream))) + (funcall (annotation-handler annotation) + (annotation-record annotation) + target + truncatep))) + +(defun output-buffer-with-annotations (stream end) + "Output the buffer of STREAM up to (excluding) the buffer index END. +When annotations are present, invoke them at the right positions." + (let ((target (pretty-stream-target stream)) + (buffer (pretty-stream-buffer stream)) + (end-posn (index-posn end stream)) + (start 0)) + (loop + for annotation = (dequeue-annotation stream :end-posn end-posn) + while annotation + do + (let ((annotation-index (posn-index (annotation-posn annotation) + stream))) + (write-string buffer target :start start + :end annotation-index) + (invoke-annotation stream annotation nil) + (setf start annotation-index))) + (write-string buffer target :start start :end end))) + +(defun flush-annotations (stream end truncatep) + "Invoke all annotations in STREAM up to (including) the buffer index END." + (let ((end-posn (index-posn end stream))) + (loop + for annotation = (dequeue-annotation stream :end-posn end-posn) + while annotation + do (invoke-annotation stream annotation truncatep)))) + + ;;;; Stuff to do the actual outputting. (defun assure-space-in-buffer (stream want) @@ -541,9 +634,10 @@ force-newlines-p) ((t) ;; Just nuke the whole logical block and make it look like one - ;; nice long literal. + ;; nice long literal. (But don't nuke annotations.) (let ((end (block-start-block-end next))) (expand-tabs stream end) + (re-enqueue-annotations stream end) (setf tail (cdr (member end tail))))) ((nil) (really-start-logical-block @@ -556,7 +650,9 @@ (block-end (really-end-logical-block stream)) (tab - (expand-tabs stream next)))) + (expand-tabs stream next)) + (annotation + (re-enqueue-annotation stream next)))) (setf (pretty-stream-queue-tail stream) tail)) output-anything)) @@ -600,12 +696,16 @@ (if last-non-blank (1+ last-non-blank) 0))))) - (write-string buffer target :end amount-to-print) + (output-buffer-with-annotations stream amount-to-print) + (flush-annotations stream amount-to-consume nil) (let ((line-number (pretty-stream-line-number stream))) (incf line-number) (when (and (not *print-readably*) *print-lines* (>= line-number *print-lines*)) (write-string " .." target) + (flush-annotations stream + (pretty-stream-buffer-fill-pointer stream) + t) (let ((suffix-length (logical-block-suffix-length (car (pretty-stream-blocks stream))))) (unless (zerop suffix-length) @@ -657,8 +757,7 @@ (buffer (pretty-stream-buffer stream))) (when (zerop count) (error "Output-partial-line called when nothing can be output.")) - (write-string buffer (pretty-stream-target stream) - :start 0 :end count) + (output-buffer-with-annotations stream count) (incf (pretty-stream-buffer-start-column stream) count) (replace buffer buffer :end1 new-fill-ptr :start2 count :end2 fill-ptr) (setf (pretty-stream-buffer-fill-pointer stream) new-fill-ptr) @@ -667,9 +766,9 @@ (defun force-pretty-output (stream) (maybe-output stream nil) (expand-tabs stream nil) - (write-string (pretty-stream-buffer stream) - (pretty-stream-target stream) - :end (pretty-stream-buffer-fill-pointer stream))) + (re-enqueue-annotations stream nil) + (output-buffer-with-annotations stream + (pretty-stream-buffer-fill-pointer stream))) ;;;; Utilities.

1 0

[mcclim-devel] Changing items list in list-pane/option-pane
by Paolo Amoroso 28 Jul '05

28 Jul '05

Is there a portable way of changing the list of items in a list-pane or option-pane after it has been created? I mean after it has given an initial value via the :items initarg. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

4 5

[mcclim-devel] postscript streams
by Christophe Rhodes 28 Jul '05

28 Jul '05

Hi, Does it make sense to consider a request to include updating-output-stream-mixin in the superclasses of postscript-stream (in Backends/Postscript/class.lisp)? We have an application which uses updating-output for incremental redisplay, but we would also like to be able to use the same drawing functions (and the same drawing logic, more importantly) without having to implement it twice, once for updating-output streams and once for postscript streams. The below makes sense in our use case. (The alternative of creating a graphical output record and then replaying it on the postscript stream is unattractive because we have a use case with no graphical output at all) Cheers, Christophe Index: Backends/PostScript/class.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/PostScript/class.lisp,v retrieving revision 1.6 diff -u -r1.6 class.lisp --- Backends/PostScript/class.lisp 4 Jul 2002 06:57:43 -0000 1.6 +++ Backends/PostScript/class.lisp 28 Jul 2005 11:31:01 -0000 @@ -60,6 +60,7 @@ permanent-medium-sheet-output-mixin sheet-mute-repainting-mixin mirrored-sheet-mixin ; ? + climi::updating-output-stream-mixin ; ?? standard-extended-output-stream standard-output-recording-stream) ((file-stream :initarg :file-stream :reader postscript-stream-file-stream)

1 1

[mcclim-devel] questions about CLIM interface paradigm
by rpgoldman＠real-time.com 26 Jul '05

26 Jul '05

1. This is a question about using the CLIM interface paradigm that I know should have an obvious answer, but I just don't understand where to find it. Consider that I have a command with some number of arguments > 1. Now, I specify a command with argument types. OK. Now where do I put the procedural information about the mechanics of choosing the arguments? I have done this in an existing application by the somewhat unpleasant expedient of having a command just have a single argument, for the "major" parameter, and then having procedural code that supplies the modifier arguments. E.g., there might be some boolean modifiers, and I provide code that tells CLIM to use a particular way of reading those modifiers. At the end of this UI code, we dispatch to the stuff that does the real work. But this seems wrong. Shouldn't I be able to specify the arguments and their types and have McCLIM Do the Right Thing about reading the additional arguments? E.g., know that a set of radiobuttons might be the right way to collect a multiple-choice modifier argument? 1.a) To get this behavior, should I be writing a bunch of accept methods? 1.b) If so, in an app that has an graphical application-pane and an interactor-pane, should I have one accept method that lets people click on the corresponding presentations (if any) and a separate one that will handle textual input? E.g., if I have objects with names, then the default accept method would allow users to supply an object of the right type by just clicking on it; could I add a second method, specialized for interactor panes, that would allow users to type the name and which would cause CLIM to somehow lookup the corresponding data strucure? And will a simple call to accept allow either form of input? Seems like it would, based on my experience, but I wasn't sure... Does CLIM just invoke ACCEPT on the application frame, and have that call to accept simply invoke ACCEPT on the associated panes? [P.S. shouldn't there be a default method for reading yes or no and returning T or NIL, as with y-or-n-p?] 2. Is it good style to use the Enabled method? Is there a standard for how CLIM should graphically present disablement? My understanding of the current UI dogma is that users should be presented with *all* the alternatives, both enabled and disabled, and that the disabled ones should be presented in some form that makes it clear they are disabled (e.g., pulldown menus with greyed-out alternatives). Not showing the disabled ones leaves the user confused about the facilities offered by the application, and showing the disabled ones w/o cues, leaves the user frustrated. Previously I had a lot of code that would handle inappropriate methods and produce a helpful string or two, but this is repetitive, a blemish on the design, and can be very large if there is a relatively complex condition for enablement.... 3. Is there any reasonable way to handle CERROR in code running inside a CLIM UI? Seems like there should be, but I don't really know how one would go about doing it.... Many thanks, Robert

4 5