mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[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

[mcclim-devel] FONT-ERROR in puzzle demo.
by Dirk Gerrits 28 Jun '05

28 Jun '05

When I try to start the puzzle demo through the Demodemo application, I'm dropped in the debugger with the following error: FONT-ERROR in current request Code 47.0 [QueryFont] ID #x2C00188 [Condition of type XLIB:FONT-ERROR] Is this a problem on my end? I'm using McCLIM CVS with SBCL 0.9.1 on an AMD64. Kind regards, Dirk Gerrits

3 4

[mcclim-devel] opacity / translucency
by nik gaffney 27 Jun '05

27 Jun '05

hello, after some basic experimentation with setting the 'opacity' of various inks, and attempting to compose-in/compose-over, im unable to find an obvious way to blend freshly drawn pixels (eg. using draw-line*) over previously drawn pixels. is it at all possible using the x11 (or potentially the beagle) backend to draw transparent/translucent objects in mcclim panes? the clim reference suggests it should be, . .. if such blending is not currently supported, could anyone suggest a method to simulate it? (a partially flipping +flipping-ink+ ??) thanks, nik

2 1

[mcclim-devel] Non-ASCII character input in McCLIM using SBCL
by Milan Zamazal 20 Jun '05

20 Jun '05

Finally I've found a way how to force McCLIM to partially accept non-ASCII input when used with SBCL. For each of the non-ASCII CHARACTERs to be input by the key CODE the following actions must be done: (xlib:define-keysym CHARACTER (xlib:keysym CODE)) (in-package :goatee) (add-gesture-command-to-table CHARACTER 'insert-character *simple-area-gesture-table*) It is not a perfect solution, because dead keys are ignored. Milan Zamazal -- It's amazing how much better you feel once you've given up hope. (unknown source)

1 0

← Newer
1
...
62
63
64
65
66
67
68
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel