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

[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

[mcclim-devel] broken
by Thomas Persson 29 Nov '06

29 Nov '06

Hi I noticed that the commands and menus in the listener are broken. I don't exactly understand the listener code but trial and error narrowed it down to what ahefner committed on November 21. Reversing some of those changes seems to fix it.

2 1

[mcclim-devel] Using common-lisp-controller with the Listener
by Martin Raspaud 24 Nov '06

24 Nov '06

Hi all, here is a small patch in order to fix the listener when used with the common-lisp-controller. The patch was suggested by Athas. Martin (aka zorgzorg2) --- mcclim/Apps/Listener/package.lisp 2005-09-29 18:42:36.000000000 +0200 +++ mcclim/Apps/Listener/package.lisp 2006-11-24 14:32:16.000000000 +0100 @@ -9,4 +9,4 @@ (eval-when (:load-toplevel) ; (format t "~&~%!@#%^!@#!@ ... ~A~%~%" *load-truename*) - (defparameter *icon-path* (merge-pathnames #P"icons/" *load-truename*))) + (defparameter *icon-path* (merge-pathnames #P"icons/" (load-time-value (or #.*compile-file-pathname* *load-pathname*)))))

1 0