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

[mcclim-devel] with-output-as-gadget
by Christophe Rhodes 14 Jul '05

14 Jul '05

Hello, What's the status of with-output-as-gadget? At the listener, (clim:with-output-as-gadget (*standard-output*) (clim:with-look-and-feel-realization ((clim:frame-manager clim:*application-frame*) clim:*application-frame*) (clim:labelling (:label "Hello")))) gets me (interestingly) /half/ a label -- the top half, to be precise. Meanwhile, attempts to do something a bit more interesting, such as (clim:with-output-as-gadget (*standard-output*) (clim:with-look-and-feel-realization ((clim:frame-manager clim:*application-frame*) clim:*application-frame*) (clim:labelling (:label "Hello") (clim:make-pane 'clim:text-field :activate-callback (lambda (g) (princ (clim:gadget-value g))))))) give me NO-APPLICABLE-METHOD on sheet-native-transformation when called with an argument of NIL, so presumably something's not getting initialized properly (whose fault is that? Mine or McCLIM's? :) (This question is motivated by the potential for implementing UI elements of forms in the closure web browser -- see <http://common-lisp.net/project/closure/> -- with clim gadgets; as far as I can tell, this is a theoretical perfect match, but if there's a reason that this is a bad idea, that would be good to know too.) Cheers, Christophe

1 0

[mcclim-devel] mcclim and clx and SBCL 0.9.2.x
by Friedrich Dominicus 10 Jul '05

10 Jul '05

Ok, had my "success" today. I installed the newest portable-clx. And applied some patches Christophe has suggested. I just extended them a bit. and now I'm able to run mcclim again. I was not successful with the debian cl-clx-sbcl package! My system is an AMD64, I'm using SBCL 0.9.2.14 IIRC, and the latest I got from the CVS tree (be it mcclim or portable-clx) Regards Friedrich

1 0

[mcclim-devel] with-system-redefinition-allowed for clisp
by Pascal Bourguignon 09 Jul '05

09 Jul '05

Please, add this to utils.lisp: #+clisp (defmacro with-system-redefinition-allowed (&body body) `(eval-when (:compile-toplevel :load-toplevel :execute) (ext:without-package-lock ("COMMON-LISP") ,@body))) -- __Pascal Bourguignon__ http://www.informatimago.com/ Cats meow out of angst "Thumbs! If only we had thumbs! We could break so much!"

1 0

[mcclim-devel] A fix to fix-clisp.lisp
by Pascal Bourguignon 09 Jul '05

09 Jul '05

By the way, input-stream-p and output-stream-p are not symbols of GRAY, but of the COMMON-LISP package. (defmacro make-generic (funame arguments) (let ((old (gensym (string funame))) (gargs (mapcar (lambda (arg) (if (consp arg) (first arg) arg)) arguments))) `(progn (setf (fdefinition ',old) (function ,funame)) (fmakunbound ',funame) (defgeneric ,funame ,gargs (:method ,arguments (,old ,@gargs)))))) (defpackage #:clim-mop (:use #:clos)) (eval-when (:compile-toplevel :load-toplevel :execute) (loop for sym being the symbols of :clim-mop do (export sym :clim-mop))) (ext:without-package-lock ("COMMON-LISP") ; <--- ;; CLIM expects INPUT-STREAM-P to be a generic function. (unless (typep #'input-stream-p 'generic-function) (make-generic input-stream-p ((stream stream)))) ;; CLIM expects OUTPUT-STREAM-P to be a generic function. (unless (typep #'output-stream-p 'generic-function) (make-generic output-stream-p ((stream stream)))) ) -- __Pascal Bourguignon__ http://www.informatimago.com/ Cats meow out of angst "Thumbs! If only we had thumbs! We could break so much!"

1 0

[mcclim-devel] A fix to fix-clisp.lisp
by Pascal Bourguignon 09 Jul '05

09 Jul '05

Think about this: when is interned gray::original-input-stream-p in: (ext:without-package-lock ("GRAY") (setf (fdefinition 'gray::original-input-stream-p) ...)) ? I'd propose to put these symbols in a user package: a specific gray-user, or they could as well be left in the current package. fix-clisp.lisp: (defpackage #:clim-mop (:use #:clos)) (eval-when (:compile-toplevel :load-toplevel :execute) (loop for sym being the symbols of :clim-mop do (export sym :clim-mop))) (defpackage #:gray-user (:use)) (ext:without-package-lock ("GRAY") ;; CLIM expects INPUT-STREAM-P to be a generic function. (unless (typep #'input-stream-p 'generic-function) (setf (fdefinition 'gray-user::original-input-stream-p) #'input-stream-p) (fmakunbound 'input-stream-p) (defgeneric input-stream-p (stream) (:method ((stream stream)) (gray-user::original-input-stream-p stream)))) ;; CLIM expects OUTPUT-STREAM-P to be a generic function. (unless (typep #'output-stream-p 'generic-function) (setf (fdefinition 'gray-user::original-output-stream-p) #'output-stream-p) (fmakunbound 'output-stream-p) (defgeneric output-stream-p (stream) (:method ((stream stream)) (gray-user::original-output-stream-p stream)))) ) An alternative could be to gensym them. (defmacro make-generic (funame arguments) (let ((old (gensym (string funame))) (gargs (mapcar (lambda (arg) (if (consp arg) (first arg) arg)) arguments))) `(progn (setf (fdefinition ',old) (function ,funame)) (fmakunbound ',funame) (defgeneric ,funame ,gargs (:method ,arguments (,old ,@gargs)))))) (defpackage #:clim-mop (:use #:clos)) (eval-when (:compile-toplevel :load-toplevel :execute) (loop for sym being the symbols of :clim-mop do (export sym :clim-mop))) (ext:without-package-lock ("GRAY") ;; CLIM expects INPUT-STREAM-P to be a generic function. (unless (typep #'input-stream-p 'generic-function) (make-generic input-stream-p ((stream stream)))) ;; CLIM expects OUTPUT-STREAM-P to be a generic function. (unless (typep #'output-stream-p 'generic-function) (make-generic output-stream-p ((stream stream)))) ) -- __Pascal Bourguignon__ http://www.informatimago.com/ Cats meow out of angst "Thumbs! If only we had thumbs! We could break so much!"

1 0

[mcclim-devel] Tablature editor: incremental redisplay performance
by Christophe Rhodes 08 Jul '05

08 Jul '05

Hi, As some people here know, we've been working on a CLIM- and Climacs-based editor for lute tablature. We're at the stage now where the performance characteristics are getting beyond our abilities to manage, so we thought we would try to open up the problem to specialists. The issue seems to be that (with the patch I sent a week or so ago, to use the bounding-rectangle of a region union rather than the precise union itself), essentially all of the time spent in moving around a Tabcode editor buffer is spent in COMPUTE-DIFFERENCE SET. (Without the patch I sent, essentially all the time is spent in computing region unions: and it takes about 100 times as long doing that as it does computing a difference set...). Holding down a cursor key, on one-year-old hardware, leads to perceptible lag and continued cursor motion after the key is released. We'd be happy to provide more details, or to explain other things about our application and our aims for it; any advice or suggestions for improvements to redisplay performance would be greatly appreciated. The code itself is at <http://www.doc.gold.ac.uk/~mas01cr/tabcode-20050708.tar.gz>; papers discussing the application are available from <http://www.doc.gold.ac.uk/~mas01cr/papers/>. Any contributions and observations welcome (though please try not to laugh too much :-) Cheers, Christophe

1 0

[mcclim-devel] No scrolling in interactor pane
by Raymond Toy 02 Jul '05

02 Jul '05

I've been playing around a bit over the last few days and have kind of hooked up maxima with mcclim, basically cargo-culting the listener app. The basic interaction works, and the computed expressions are displayed correctly. (Some random screenshots can be found at http://common-lisp.net/~rtoy. In particular, maxima-repl-boxed.png shows what the subexpressions should be.) In this case, the output is computed as a string by maxima, and that is printed to the mcclim's *standard-output*. However, to be able to present subexpressions (eventually), I changed the way output is done. I use maxima's capabilities of drawing to a terminal with cursor positioning and thus set the stream-cursor-position as needed. This also works. Until I reach the bottom of the interactor pane. The pane never scrolls down and the prompt keeps getting overwritten. I'm obviously missing something, but I don't know what. Anyone have some hints for this clim newbie? Ray P.S. A current very hackish version of the code is available at common-lisp.net/~rtoy/maxima-repl-2005-07-02.lisp.

2 2

[mcclim-devel] incremental redisplay and with-first-quadrant-coordinates
by Christophe Rhodes 02 Jul '05

02 Jul '05

Hi, The attached file defines two application frames which differ essentially only in their use of with-first-quadrant-coordinates. In the one (BAR) without with-first-quadrant-coordinates, incremental redisplay behaves as I expect; in the other (FOO) with, strange things happen. I believe this is connected with output record moving; if I change state-matches-stream-p in incremental-redisplay to query both X and Y coordinates of the stream cursor, the display of both applications is as I expect. Cheers, Christophe

1 0

[mcclim-devel] test
by Raymond Toy 02 Jul '05

02 Jul '05

ignore

1 0

[mcclim-devel] #+unicode makes McCLIM not compile, #-unicode makes gadget-test-kr.lisp not compile.
by Dirk Gerrits 29 Jun '05

29 Jun '05

As the title says, if I don't have :unicode in *features*, then Examples/gadget-test-kr.lisp won't compile. It calls make-text-style with 4 arguments in several places, when make-text-style only takes 3 arguments. Having discovered that make-text-style /does/ take 4 arguments with #+unicode, I tried to recompile McCLIM after (push :unicode *features*). (:sb-unicode was already in *features*) This didn't work either: compilation aborted because of fatal error: READ failure in COMPILE-FILE: READER-ERROR at 43712 (line 1046, column 88) on #<SB-SYS:FD-STREAM for "file \"/home/dirk/lisp/mcclim/Backends/CLX/port.lisp\"" {1000F83EA1}>: package "EXTERNAL-FORMAT" not found Unicode support isn't important for me, but I was trying out the Examples/*.lisp and came across this, so I just thought I'd let you know. Kind regards, Dirk Gerrits

3 5