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

Re: [mcclim-devel] mcclim-devel Digest, Vol 39, Issue 6
by Irene DURAND 27 Mar '13

27 Mar '13

Hello, As my paste on irc lisp, did not have any answer, I turning again to this more specialized mailing list. I have this MClim problem. The application runs fine on Linux with SBCL 1.0.13, xorg-x11-server 1.3.0.0-9.fc7, a recent version of MClim. But doesn't on my Mac (Darwin PowerPC) with MacOS 10.5 (leopard), SBCL 1.0.16, cvs version of MClim, Xquartz 2.1.5 - (xorg-server 1.3.0-apple22)(2.1.5). I have tried to create the smallest as possible application where the problems occurs (attached). Just compile the file and launch mini::(start) On Linux, I have the desired behaviour: a circle blinks (red/green/red/...) on the display pane and at the bottom of the window application, the "quit" button is displayed and works. On the Mac, the circle blinks correctly but the "Quit" button never shows up. For a while the application is killable with C-c C-c (under Slime), but after a while there is no way to kill it than to stop Lisp and restart everything (even /the/ <http://www.lispworks.com/reference/HyperSpec/Body/s_the.htm> X server). Note that this application used to work on Mac OS 10.3 (Panther) with older versions of everything. I suspect the X server to behave differently from before. But now I don't see how to make the application work. This is too bad, as I usually use a similar application for my Lisp undergraduate course. If anyone has an idea, it will be welcomed. Irène (defpackage :mini (:use :clim :clim-extensions :clim-lisp)) (in-package :mini) (let ((colors (list +red+ +green+))) (setf colors (nconc colors colors)) (defun display-function (frame pane) (draw-circle* pane 10 10 10 :ink (pop colors)) (sleep 0.5) (redisplay-frame-panes frame))) (defun quit () (frame-exit *application-frame*)) (define-application-frame mini () () (:panes (display :application :display-function 'display-function :incremental-redisplay t) (quit :push-button :label "Quit" :activate-callback (lambda (x) (declare (ignore x)) (quit)))) (:layouts (defaults (vertically () display quit)))) (defun run-test (name) (loop for port in climi::*all-ports* do (destroy-port port)) (setq climi::*all-ports* nil) (let ((frame (make-application-frame name))) (run-frame-top-level frame))) (defun start () (run-test 'mini) 0) (defmethod run-frame-top-level :before ((mini mini) &key) (let* ((frame-manager (frame-manager *application-frame*)) (port (climi::frame-manager-port frame-manager)) (display (clim-clx::clx-port-display port))) (setf (xlib:display-after-function display) g#'xlib:display-force-output)))

4 4

[mcclim-devel] map-over-output-records-overlapping-region
by Orm Finnendahl 02 Apr '11

02 Apr '11

Hi, reading the specs, map-over-output-records-overlapping-region should map over *all* childs of the supplied output-record which overlap the supplied region. In my application, the output-records are hierarchical with the topmost output-record covering the whole drawing area and its childs occupying parts of that and their childs again parts of the parts and so forth. When calling the function on a part of the drawing area, the macro only maps the function over the topmost output record and ignores all of its childs which also overlap the region in question. I could write a similar macro which traverses the tree and checks for overlap but I ask myself, whether the behaviour of mcclim's built-in macro is correct with regards to the specs or whether I'm doing something wrong here... -- Orm

3 2

[mcclim-devel] Compiler warnings
by James Ashley 23 Jan '11

23 Jan '11

I'm trying to learn McCLIM using ccl, and I just noticed several compiler warnings during the load process. I remember that, way back when, these were a big concern. One set looks silly/simple enough that I think I'm qualified to submit a patch. To deal with some variables that get defvar'd in a different file (and a really minor typo): --- design.lisp.original 2011-01-23 10:13:13.000000000 -0600 +++ design.lisp 2011-01-23 11:50:01.000000000 -0600 @@ -21,7 +21,7 @@ ;;;; Some Notes -;; The design design has a pitfall: +;; The design has a pitfall: ;; ;; As drawing is specified, a design of class opacity carries no color ;; and thus borrows its color from +foreground-ink+. So that @@ -344,6 +344,7 @@ 0.0) (defun make-opacity (value) + (declare (special +everywhere+)) ; squash a compiler warning (setf value (clamp value 0 1)) ;defensive programming (cond ((= value 0) +transparent-ink+) ((= value 1) +everywhere+) ; used to say +foreground-ink+ @@ -669,7 +670,8 @@ design) (defmethod compose-in ((design design) (mask nowhere-mixin)) - (declare (ignore design mask)) + (declare (ignore design mask) + (special +nowhere+)) +nowhere+) ;;; IN-COMPOSITUM @@ -782,7 +784,8 @@ ;;;; (defmethod compose-out ((design design) (mask everywhere-mixin)) - (declare (ignore design mask)) + (declare (ignore design mask) + (special +nowhere+)) +nowhere+) (defmethod compose-out ((design design) (mask nowhere-mixin)) @@ -790,7 +793,8 @@ design) (defmethod compose-out ((design design) (mask color)) - (declare (ignore design mask)) + (declare (ignore design mask) + (special +nowhere+)) +nowhere+) (defmethod compose-out ((design design) (mask uniform-compositum)) =============================================================================== Well, AFAICT that didn't break anything...undertested newb code warning. I don't know how to handle the rest. Both graphics.lisp and design.lisp seem to have a very subtly different definition of (defmethod draw-design (medium (design rgb-image-design) &rest options &key (x 0) (y 0) &allow-other-keys) ... (They seem to have different return values). This is the first time I've knuckled down and started looking at the source code, so I don't have the foggiest notion which definition is correct. The defclass for standard-text-displayed-output-record in recording.lisp has many of its slots using :start-x and :start-y for :initarg's. This had to have been done on purpose, and it seems to make sense in that particular situation. But how to eliminate the compiler warnings? (I'm just going with the assumption that this is conforming in the first place). stream-input.lisp -- line 134, (defmethod stream-read-gesture :around specifies *input-wait-test* as one of the default arguments. It looks like (proclaim (special *input-wait-test*)) at some point is the right way to fix this one. But that seems pretty heavy-handed. *input-wait-handler* and *pointer-button-press-handler* have the same issue, in the same lambda list. (Then again, maybe just rearranging the load order in the ASD is the "correct" way to fix it). bezier.lisp and regions.lisp have conflicting definitions for (region-equal ((? point) (? point)) ... And it looks like line 782 in bezier.lisp where climi:with-medium-options is used before it was defined. When I exited and restarted emacs and re-ran (require :clim) (which very well may be the wrong way to load it), most of the warnings went away. I don't think there was any reason for it to rebuild things the first time, but I could be mistaken there. I'm using the 20101006 CVS snapshot distributed via quicklisp. Respectfully, James

2 1

[mcclim-devel] change cursor
by Orm Finnendahl 08 Jan '11

08 Jan '11

Hi, is it possible to change the default cursor in a pane from the standard arrow to a horizontal and vertical line spanning the height and width of the pane and intersecting at the cursor position (like in some CAD applications)? I defined a command to invoke a tracking-pointer routine, but I'd rather have the cursor in the top-level loop of the application frame, changing to the cross whenever the mouse enters the visible portion of the pane (preferably showing the current cursor position in sheet coordinates in a corner of the pane). -- Orm

1 0

[mcclim-devel] presentations insensitive after window-clear and redisplay
by Orm Finnendahl 06 Jan '11

06 Jan '11

Hello, issuing a window-clear on a pane and redisplaying its presentations with redisplay-frame-pane (using incremental redisplay) makes the presentations insensitive to mouse gestures. Is that intended behaviour or a bug? The clim spec for window-clear states that the ouput-history is cleared, but the display routine of the pane is explicitely redrawing the contents as presentations (and they appear on the display). I'm using mcclim 0.9.6 with sbcl 1.0.29.11.debian on 64-bit linux. -- Orm

1 0