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

[mcclim-devel] (setf bounding-rectangle-min-x)
by Raymond Toy 16 Dec '06

16 Dec '06

In draw.lisp in scigraph, there are calls to (setf bounding-rectangle-min-x) and friends. These don't seem to exist in mcclim, but there is (setf rectangle-edges*) which seems to be doing essentially the same thing. Here is a little patch that implements that. Not sure it's really right, though. Ray Index: draw.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Apps/Scigraph/scigraph/draw.lisp,v retrieving revision 1.3 diff -u -r1.3 draw.lisp --- draw.lisp 17 Mar 2006 07:12:52 -0000 1.3 +++ draw.lisp 16 Dec 2006 14:58:36 -0000 @@ -134,13 +134,19 @@ (slot-value .x. 'clim-utils::max-y) be) (with-drawing-options (,stream :clipping-region .x.) ,@body))) - (:clim-2 + ((and :clim-2 (not :mcclim)) (let ((.x. *clim-clip-rectangle*)) (setf (bounding-rectangle-min-x .x.) le (bounding-rectangle-min-y .x.) te (bounding-rectangle-max-x .x.) re (bounding-rectangle-max-y .x.) be) (with-drawing-options (,stream :clipping-region .x.) + ,@body))) + ((and :clim-2 :mcclim) + (let ((.x. *clim-clip-rectangle*)) + (setf (rectangle-edges* .x.) + (values le te re be)) + (with-drawing-options (,stream :clipping-region .x.) ,@body)))))) (eval-when (compile load eval)

2 3

[mcclim-devel] redisplay-frame-pane with named panes
by Raymond Toy 16 Dec '06

16 Dec '06

In clasp, there are several calls like (redisplay-frame-pane clasp-frame 'notebook), where 'notebook is the name of a pane. This always gets an error about no method for pane-needs-redisplay with arg (notebook). If I change the call to be (redisplay-frame-pane clasp-frame (find-pane-named clasp-frame 'notebook)), everything works. Assuming that redisplay-frame-pane should convert the pane name to a pane object within the function, here is a possible replacement. I don't really know enough about mcclim to know if this is sensible or not, but it works for clasp. Ray Index: frames.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/frames.lisp,v retrieving revision 1.120 diff -u -r1.120 frames.lisp --- frames.lisp 1 Jul 2006 21:00:31 -0000 1.120 +++ frames.lisp 16 Dec 2006 14:52:38 -0000 @@ -368,22 +368,25 @@ (defmethod redisplay-frame-pane :around ((frame application-frame) pane &key force-p) - (multiple-value-bind (redisplayp clearp) - (pane-needs-redisplay pane) - (when force-p - (setq redisplayp (or redisplayp t) - clearp t)) - (when redisplayp - (let ((hilited (frame-hilited-presentation frame))) - (when hilited - (highlight-presentation-1 (car hilited) (cdr hilited) :unhighlight) - (setf (frame-hilited-presentation frame) nil))) - (with-possible-double-buffering (frame pane) - (when clearp - (window-clear pane)) - (call-next-method)) - (unless (or (eq redisplayp :command-loop) (eq redisplayp :no-clear)) - (setf (pane-needs-redisplay pane) nil))))) + (let ((pane-object (if (typep pane 'pane) + pane + (find-pane-named frame pane)))) + (multiple-value-bind (redisplayp clearp) + (pane-needs-redisplay pane-object) + (when force-p + (setq redisplayp (or redisplayp t) + clearp t)) + (when redisplayp + (let ((hilited (frame-hilited-presentation frame))) + (when hilited + (highlight-presentation-1 (car hilited) (cdr hilited) :unhighlight) + (setf (frame-hilited-presentation frame) nil))) + (with-possible-double-buffering (frame pane-object) + (when clearp + (window-clear pane-object)) + (call-next-method)) + (unless (or (eq redisplayp :command-loop) (eq redisplayp :no-clear)) + (setf (pane-needs-redisplay pane-object) nil)))))) (defmethod run-frame-top-level ((frame application-frame) &key &allow-other-keys)

2 2

[mcclim-devel] (declare (values foo)) in scigraph menu-tools.lisp
by Raymond Toy 16 Dec '06

16 Dec '06

There's an uncommented (declare (values foo)) in the function SEVERAL-CHOOSE in menu-tools.lisp. I guess that should be commented out like the other similar occurrences in scigraph. Ray

1 0

[mcclim-devel] Freetype and CFFI
by Dmitri Hrapof 10 Dec '06

10 Dec '06

(also posted to CFFI list) Hello! I'm trying to use libfreetype.so via CFFI. What I hacked up so far is located here: http://www.common-lisp.ru/cleft.asd http://www.common-lisp.ru/cleft.lisp The code like that works: (with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (docharmap (code face) (format t "~a " (code-char code))))) and prints out all glyphs in a font. However, the following doesn't do what I want: (with-freetype lib (with-face lib (face "/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf") (set-char-size face (* 16 64) (* 16 64) 300 300) (glyph-pixarray face (char-code #\a)))) It returns #2A() Looks like the whole bitmap structure is set to zeros. I think I'm following FreeType and CFFI tutorials closely and I can't explain what's wrong... Thank you for your help, Dmitri

7 9

[mcclim-devel] CLIM 2.0 versus CLIM 2.2
by Troels Henriksen 04 Dec '06

04 Dec '06

Hello, As known, there are two major CLIM references - the annotateable CLIM spec hosted by Gilbert Baumann, and the CLIM User's Guide by Franz. The former covers CLIM 2.0 and the latter CLIM 2.2, but which of these should be considered canonical in McCLIM? As far as I know, CLIM 2.2 is clearer in some areas, and fills holes that are weirdly ambiguous, inconsistent or hopelessly un[der]specified in CLIM 2.0. McCLIM already implements some CLIM 2.2 features (not all, though it should be fairly trivial to add them). As I am easily dazzled by comparatively large numbers, my opinion is that we should try to support CLIM 2.2; but what has been McCLIM's "official" position so far? The first amusing issue is how to handle the :SCROLL-BARS argument to `make-clim-stream-pane' and the `open-window-stream' functions. In CLIM 2.0, `make-clim-stream-pane' takes an argument of type (member T :HORIZONTAL :VERTICAL NIL), while `open-window-stream' takes an argument of type (member :BOTH :HORIZONTAL :VERTICAL NIL). In CLIM 2.2, these functions have been unified to both take an argument of type (member :BOTH :HORIZONTAL :VERTICAL NIL), so I believe that this was mostly an oversight in CLIM 2.0. It would be easy to add code to handle both :BOTH and T (and make them synonyms), or to emit a warning for T. What would be preferable? -- \ Troels "Athas" /\ Henriksen

1 0

[mcclim-devel] Drie crashes on: "`(,@a "
by Robert Strandh 04 Dec '06

04 Dec '06

There is some minor problem in Drei that you can see if you do this : 1. type (setf climi::*use-goatee* nil) 2. then type (clim-listener:run-listener) 3. in the listener, type "`(,@a ", i.e., backquote left-parenthesis comma at-sign a space. Drei crashes with an error message saying that #:A is not of type list. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------

2 1

[mcclim-devel] questions on text graphics
by Jack Unrue 03 Dec '06

03 Dec '06

I've been working on graphics support in my backend code and have a couple questions. What are the intended side effects of the TEXT-STYLE-*** methods, if any? Are they solely intended to answer "what-if" questions, e.g., "what would the ascent be if the font was :fixed and :bold ?" Or are they also meant to update the medium's text style attributes, as I see the gtkairo backend doing? Since one can add :before/:after methods on (SETF MEDIUM-TEXT-STYLE) to synchronize the underlying graphics context -- and presumably such a style attribute update necessitates repainting -- is that sufficient or should I really be planning on synchronizing attributes anywhere that styles are passed as arguments? MEDIUM-DRAW-TEXT* appears to be called for each character in the string to be rendered. I gather that a backend is expected to be able to buffer such operations (see next question). But from looking at backtraces, the cause seems to be CL:WRITE-STRING processing the output stream one char at a time. I'm running on CLISP, so perhaps you lucky SBCL folks have your string output processed in batches. I take it that the use of WRITE-STRING is a consequence of CLIM's stream output model? More generally regarding output buffering, I see the MEDIUM-FINISH-OUTPUT and MEDIUM-FORCE-OUTPUT methods and can easily imagine how my backend code might implement those. I also notice the public WITH-OUTPUT-BUFFERED macro and that it communicates with the backend by way of MEDIUM-OUTPUT-BUFFERING-P. Based on what I'm seeing so far just with text output, I'm sort of inclined to implement double-buffering unconditionally. Is that a bad idea, or am I missing a level of abstraction between McCLIM's idea of buffering and my backend's idea of buffering? Thanks. -- Jack Unrue

2 2

[mcclim-devel] One more gtkairo gotcha
by C Y 03 Dec '06

03 Dec '06

When I use the File menu entry in Gsharp to open a file, I don't get tab completion when entering the file name. I do get it with the clx backend. I've observed this before with gtkairo (I think with beirc). Cheers, CY ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.

1 0

[mcclim-devel] Another gsharp+gtkairo error, plus good news
by C Y 03 Dec '06

03 Dec '06

First, the good news - the notes now display very nicely with gtkairo! Yay! Now, the bug. Dunno what this one is about, but thought I'd report it: debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {B2982A9} >: status NO_MEMORY after call to cairo_select_font_face Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETURN-TO-ESA] ESA::RETURN-TO-ESA 1: [ABORT ] Exit debugger, returning to top level. (CLIM-GTKAIRO::ASSERT-FONT-STATUS #.(SB-SYS:INT-SAP #X080A25A0) "cairo_select_fo nt_face") 0] This came after trying to open 2 files - bach181.gsh (successful) and then bach181-lyrics.gsh (above). A retest confirms it happens when starting with just bach181-lyrics.gsh aborting and trying to re-start gsharp without restarting sbcl triggers the same error immediately on startup. Cheers, and thanks! CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

[mcclim-devel] Gsharp + gtkairo error
by C Y 03 Dec '06

03 Dec '06

This is with latest cvs of both as of 12/2, and sbcl 1.0 on Gentoo Linux. gtk version is 2.10.6: * (gsharp:gsharp) debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {B2982A9}>: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM:GADGET-ACTIVE-P (1)> when called with arguments (#<CLIM-GTKAIRO::GTK-MENU-BAR "(Unnamed Pane)" {C3FDEC9}>). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unused argument> #<unused argument> #<STANDARD-GENERIC-FUNCTION CLIM:GADGET-ACTIVE-P (1)> #<CLIM-GTKAIRO::GTK-MENU-BAR "(Unnamed Pane)" {C3FDEC9}>) ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

2 1