From o.finnendahl at inm.mh-freiburg.de Thu Jan 6 18:05:25 2011 From: o.finnendahl at inm.mh-freiburg.de (Orm Finnendahl) Date: Thu, 6 Jan 2011 19:05:25 +0100 Subject: [mcclim-devel] presentations insensitive after window-clear and redisplay Message-ID: <20110106180525.GE24025@varese> 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 From o.finnendahl at inm.mh-freiburg.de Thu Jan 6 21:51:50 2011 From: o.finnendahl at inm.mh-freiburg.de (Orm Finnendahl) Date: Thu, 6 Jan 2011 22:51:50 +0100 Subject: [mcclim-devel] map-over-output-records-overlapping-region Message-ID: <20110106215150.GG24025@varese> 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 From james.ashley at gmail.com Fri Jan 7 01:03:52 2011 From: james.ashley at gmail.com (James Ashley) Date: Thu, 6 Jan 2011 19:03:52 -0600 Subject: [mcclim-devel] map-over-output-records-overlapping-region In-Reply-To: <20110106215150.GG24025@varese> References: <20110106215150.GG24025@varese> Message-ID: On Thu, Jan 6, 2011 at 3:51 PM, Orm Finnendahl wrote: > 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... I'm far from an expert here (really a total newb just trying to get my feet wet), and this may be totally unrelated, but, FWIW, I ran across something about this function/macro (?) in the past couple of days while digging back through the mailing list archives (I think it was around Oct 2003). >From what I remember, that discussion had something to do with creating a custom kind of output record. I think it revolved around protocols and which kind of rectangle a pane really is. It definitely involved intersection testing (I think the issue there was that the current implementation was requiring the custom output record to implement a protocol defined in clim-internals). That's probably no help whatsoever, and completely unrelated. But I figured I'd post this on the off chance that it might ring a bell for someone who has a clue, or maybe offer a hint that might be at least vaguely helpful. > -- > Orm Good luck, James From o.finnendahl at inm.mh-freiburg.de Sat Jan 8 16:47:55 2011 From: o.finnendahl at inm.mh-freiburg.de (Orm Finnendahl) Date: Sat, 8 Jan 2011 17:47:55 +0100 Subject: [mcclim-devel] change cursor Message-ID: <20110108164754.GB21384@varese> 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 From james.ashley at gmail.com Sun Jan 23 17:59:43 2011 From: james.ashley at gmail.com (James Ashley) Date: Sun, 23 Jan 2011 11:59:43 -0600 Subject: [mcclim-devel] Compiler warnings Message-ID: 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 From rpgoldman at sift.info Sun Jan 23 20:35:43 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Sun, 23 Jan 2011 14:35:43 -0600 Subject: [mcclim-devel] Compiler warnings In-Reply-To: References: Message-ID: <4D3C911F.8070209@sift.info> On 1/23/11 Jan 23 -11:59 AM, James Ashley wrote: > 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)) > ? These are really dependency errors, not declaration errors, and we don't really want these defined as specials. Instead, the system definition (presumably in mcclim.asd) should be modified to force the file that defines +nowhere+, +everywhere+, etc. to be loaded before design.lisp. If, for some reason, that is difficult, one could break out a separate file with the constant definitions, and no dependencies beyond the package-defining file, and load that early. best, r