mcclim-devel July 2005

mcclim-devel@common-lisp.net

19 participants
28 discussions

[mcclim-devel] question about curves and formatting graphs
by rpgoldman＠real-time.com 10 Apr '06

10 Apr '06

If one wanted to draw curvy lines in McCLIM, is there any way of doing this? I had assumed, foolish me, that this could be done using Bezier curves, but now I see that those were an Allegro extension to the standard, and not part of CLIM 2.0.... I'm not much of a graphics person, and don't understand X very well, so I was wondering --- is there anything about X itself that makes drawing curved lines particularly difficult? Also, has anyone been thinking about the possibility of dynamic graphs? I.e., graphs where one might want to enter leaves? Or the possibility of having a fixed graph where a user might move the nodes around to make the graph more readable. CLIM doesn't have any sort of "smart link" object that would support this, does it? Thanks, Robert

4 11

[mcclim-devel] One char patch to presentation-defs
by David Murray 25 Aug '05

25 Aug '05

[resent to the correct address - I hope...] I was wondering why the :highlight option to :single-box wasn't working as I thought it should. Turns out there was a wee typo. Patch attached. JQS Index: presentation-defs.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/presentation-defs.lisp,v retrieving revision 1.44 diff -u -r1.44 presentation-defs.lisp --- presentation-defs.lisp 22 Jun 2005 09:49:15 -0000 1.44 +++ presentation-defs.lisp 25 Jul 2005 13:05:48 -0000 @@ -993,7 +993,7 @@ (multiple-value-bind (min-x min-y max-x max-y) (output-record-hit-detection-rectangle* record) (if (and (<= min-x x max-x) (<= min-y y max-y)) - (if (or (null single-box) (eq single-box :higlighting)) + (if (or (null single-box) (eq single-box :highlighting)) (funcall-presentation-generic-function presentation-refined-position-test (presentation-type record) record x y)

10 34

[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] 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

[mcclim-devel] drawing a transformed-design using draw-rectangle* says not yet implemented
by Jeremy Rayman 26 Jul '05

26 Jul '05

Hi there. I'm trying to resize an image and show it to the screen. The image loads OK, and before the image is transformed I can use (draw-rectangle* pane 0 0 50 50 :ink image) to show it fine (just clips off the rest). After scaling it, when I try to change the :ink to the new transformed-design, it gives an error "Sorry, not yet implemented". Here's what I'm doing: ;; xpm.lisp is loaded by clim-listener.asd (let* ((image (clim-internals::xpm-parse-file #p"image.xpm")) (transformed-bg (transform-region (make-scaling-transformation 5 5) image))) (draw-rectangle* pane 0 0 50 50 :ink transformed-bg)) ;; if it's :ink image, it shows, just not scaled Sorry, not yet implemented. [Condition of type SIMPLE-ERROR] That error is coming from clim-clx::medium-gcontext (backtrace below). >From mcclim/Backends/CLX/medium.lisp, that func is set up for translation-transformations, but not scaling-transformations. If it's anything but a translation-transformation, it gives an error saying not yet implemented. Here's that function, only the first 5 lines matter: (defmethod medium-gcontext ((medium clx-medium) (ink climi::transformed-design)) (let ((transformation (climi::transformed-design-transformation ink)) (design (climi::transformed-design-design ink))) (unless (translation-transformation-p transformation) (error "Sorry, not yet implemented.")) ;; Bah! (typecase design ((or climi::indexed-pattern climi::rectangular-tile) (multiple-value-bind (tx ty) (transform-position transformation 0 0) (let ((gc-x (round-coordinate tx)) (gc-y (round-coordinate ty)) (gc (design-gcontext medium design))) (setf (xlib:gcontext-ts-x gc) gc-x (xlib:gcontext-ts-y gc) gc-y (xlib:gcontext-clip-x gc) gc-x (xlib:gcontext-clip-y gc) gc-y) gc))) (t (error "You lost, we not yet implemented transforming an ~S." (type-of ink)))))) Since I don't know how to make it handle scaling-transformations, I guess this ends up being a feature request. I asked on irc about it and was told to mail here. If there's a better way to draw my scaled image, I'd love to know. Thanks guys! - Jeremy Rayman jeremy.rayman(a)gmail.com ----------- if anyone needs it: Backtrace: 0: ((SB-PCL::FAST-METHOD CLIM-CLX::MEDIUM-GCONTEXT (CLIM-CLX::CLX-MEDIUM CLIM-INTERNALS::TRANSFORMED-DESIGN)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-MEDIUM {4AB116E9}> #<CLIM-INTERNALS::TRANSFORMED-DESIGN {485EC701}>) 1: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-MEDIUM {4AB116E9}> #<CLIM-INTERNALS::TRANSFORMED-DESIGN {485EC701}>) 2: ((SB-PCL::FAST-METHOD CLIM-CLX::MEDIUM-DRAW-RECTANGLE-USING-INK* (CLIM-CLX::CLX-MEDIUM T T T T T T)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-MEDIUM {4AB116E9}> #<unavailable argument> 0 0 40 40 T) 3: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL (MEDIUM T T)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-MEDIUM {4AB116E9}> #<CLIM-INTERNALS::SPRITE-PUSH-BUTTON-PANE CLIM-DEMO::CE {4AB008A1}> #<CLOSURE (FLET CLIM-INTERNALS::GRAPHICS-OP) {485EC785}> (:INK #<CLIM-INTERNALS::TRANSFORMED-DESIGN {485EC701}>)) 4: ((FLET #:FN21) #<CLIM-INTERNALS::SPRITE-PUSH-BUTTON-PANE CLIM-DEMO::CE {4AB008A1}>) 5: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) #<unavailable argument> #<unavailable argument> #<CLIM-INTERNALS::SPRITE-PUSH-BUTTON-PANE CLIM-DEMO::CE {4AB008A1}> #<CLIM-DEMO::CALCULATOR {4AA7CD19}> #:GADGET10920) 6: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<CLIM-INTERNALS::SPRITE-PUSH-BUTTON-PANE CLIM-DEMO::CE {4AB008A1}> #<POINTER-ENTER-EVENT {485EC211}>) ...

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel July 2005