From csr21 at cantab.net  Mon Jul  9 08:26:04 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 09 Jul 2007 09:26:04 +0100
Subject: [mcclim-devel] Yet another half-baked half-finished backend
Message-ID: <877ipa9e5f.fsf@cantab.net>

Hi,

I'm aware that we're accumulating broken backends faster than we are
fixing them, but I'd still like to make a case for including another.
Over the course of yesterday, I built enough of a backend based on the
WHATWG (HTML 5) group's <canvas> widget that code which is essentially
  (with-output-to-canvas (s file)
    (gsharp:draw-buffer s buffer))
produces
  <http://doc.gold.ac.uk/~mas01cr/tmp/rapsoden-mostly-correct.html>
(best viewed with something that's not IE; also, please don't tell me
that it tells you about not supporting <canvas> even though it does).

I should warn that I'm one Web Coder short of a project; I don't
really have a feeling for how to take this backend much further:
specifically, missing features that are moderately essential are text
(<canvas> doesn't support text; apparently styled <div>s are the way
forward) -- which would get the backend about up to Postscript levels
of functionality -- and interactivity, which would be utterly cool but
clearly won't work currently given that that html file is about 1MB
big.  So, any ideas?

The backend itself is about 400 lines of code; should I just go ahead
and check it in, or does anyone have any reservations?

Cheers,

Christophe


From david at lichteblau.com  Mon Jul  9 09:49:56 2007
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 9 Jul 2007 11:49:56 +0200
Subject: [mcclim-devel] Yet another half-baked half-finished backend
In-Reply-To: <877ipa9e5f.fsf@cantab.net>
References: <877ipa9e5f.fsf@cantab.net>
Message-ID: <20070709094956.GA8474@ununoctium>

Quoting Christophe Rhodes (csr21 at cantab.net):
> I should warn that I'm one Web Coder short of a project; I don't
> really have a feeling for how to take this backend much further:
> specifically, missing features that are moderately essential are text
> (<canvas> doesn't support text; apparently styled <div>s are the way
> forward) -- which would get the backend about up to Postscript levels
> of functionality -- and interactivity, which would be utterly cool but
> clearly won't work currently given that that html file is about 1MB
> big.  So, any ideas?

Hand-written JavaScript code could fetch a description of the shapes to
render using XMLHttpReqest, which has "XML" in its name, but can
actually also fetch arbitrary text/plain documents.  At least on Firefox
this approach also works for documents in the local file system, so a
web server is not necessary initially.

Interactive use is then just a matter of repeating these requests to
wait for more events from the server or to send keyboard events back
(but will obviously require a web server at that point).

(Since you mentioned lack of a web coder, see
http://www.lichteblau.com/blubba/responsetext/test.html for a trivial
XMLHttpRequest example that renders a text file from the same
directory.)

So the next step could be to define a textual format that describes the
shapes to render which is as compact as possible.

Made-up example for a syntax that might or might not be more compact:
  M42R0,0,100,100
could mean "medium operation", "the medium with ID 42", "draw a
rectangle", "here are the coordinates".

If that is still not compact enough, (ab)use the full range of Unicode
characters for a binary format.


From csr21 at cantab.net  Mon Jul  9 10:13:23 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 09 Jul 2007 11:13:23 +0100
Subject: [mcclim-devel] Yet another half-baked half-finished backend
In-Reply-To: <20070709094956.GA8474@ununoctium> (David Lichteblau's message of
	"Mon, 9 Jul 2007 11:49:56 +0200")
References: <877ipa9e5f.fsf@cantab.net> <20070709094956.GA8474@ununoctium>
Message-ID: <873azxanr0.fsf@cantab.net>

David Lichteblau <david at lichteblau.com> writes:

> Hand-written JavaScript code could fetch a description of the shapes to
> render using XMLHttpReqest, which has "XML" in its name, but can
> actually also fetch arbitrary text/plain documents.  At least on Firefox
> this approach also works for documents in the local file system, so a
> web server is not necessary initially.
>
> Interactive use is then just a matter of repeating these requests to
> wait for more events from the server or to send keyboard events back
> (but will obviously require a web server at that point).

I suppose another question is whether people think that this is
worthwhile -- I think it's fair to say that we're fairly stretched as
is; at least, I am.  (I can't in all fairness make any promises at all
about time I have to polish this at the moment, for instance.)

> (Since you mentioned lack of a web coder, see
> http://www.lichteblau.com/blubba/responsetext/test.html for a trivial
> XMLHttpRequest example that renders a text file from the same
> directory.)

My epiphany says

  Javascript error in  on line 0:
  uncaught exception: [Exception... "Not enough arguments
  [nsIXMLHttpRequest.send]" nsresult: "0x80570001
  (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame ::
  http://www.lichteblau.com/blubba/responsetext/test.js :: <TOP_LEVEL>
  :: line 29" data: no]

I'm afraid.  (But I get the idea, I think.)

> So the next step could be to define a textual format that describes the
> shapes to render which is as compact as possible.
>
> Made-up example for a syntax that might or might not be more compact:
>   M42R0,0,100,100
> could mean "medium operation", "the medium with ID 42", "draw a
> rectangle", "here are the coordinates".

Right.  

I suppose another way is to compile enough of the various applicable
methods that much of the responses to user interaction can be executed
on the client -- it would be insane to round-trip for stuff like
highlight-presentation, for instance.  Again, I don't have a feel for
how possible this is.

Thanks,

Christophe


From jdunrue at gmail.com  Mon Jul  9 17:27:21 2007
From: jdunrue at gmail.com (Jack Unrue)
Date: Mon, 9 Jul 2007 11:27:21 -0600
Subject: [mcclim-devel] Yet another half-baked half-finished backend
In-Reply-To: <873azxanr0.fsf@cantab.net>
References: <877ipa9e5f.fsf@cantab.net> <20070709094956.GA8474@ununoctium>
	<873azxanr0.fsf@cantab.net>
Message-ID: <d3df77800707091027r35cd737cs9af4f2f30fa9e3aa@mail.gmail.com>

On 7/9/07, Christophe Rhodes <csr21 at cantab.net> wrote:
>
> I suppose another question is whether people think that this is
> worthwhile -- I think it's fair to say that we're fairly stretched as
> is; at least, I am.  (I can't in all fairness make any promises at all
> about time I have to polish this at the moment, for instance.)

I think it's worthwhile. You are showing how McCLIM can be applied
in a context that maybe some people didn't realize was possible, and
maybe somebody new will hop on board as a result of seeing this.

Would it help relieve the concerns about broken backends if the
non-functional ones (such as clim-graphic-forms) were left out
of "official" releases until such time as they meet some (to be
determined) functionality level? Or is that policy already in place?

-- 
Jack Unrue


From jm at mak.com  Tue Jul 10 14:58:54 2007
From: jm at mak.com (John Morrison)
Date: Tue, 10 Jul 2007 10:58:54 -0400
Subject: [mcclim-devel] Yet another half-baked half-finished backend
In-Reply-To: <877ipa9e5f.fsf@cantab.net>
References: <877ipa9e5f.fsf@cantab.net>
Message-ID: <200707101058.56311.jm@mak.com>

I apologize if this is either old news to you all or not directly
relevant, but FWIW SRI had some "web" type CLIM backend:

http://www.ai.sri.com/~pkarp/clim-www/tool.html

The source code is available via a URL on that page.  I made some
half-hearted attempts to build it under SBCL+McCLIM, but did not get
too far.

It definitely fell into the "yak-shaving" category for me, but it
might have some relevance for you guys (if I understand correctly what
you are attempting).

-jm


-- 
==== John Morrison
==== MAK Technologies Inc.
==== 68 Moulton Street, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm at mak.com




From gilham at csl.sri.com  Tue Jul 10 20:50:42 2007
From: gilham at csl.sri.com (Fred Gilham)
Date: Tue, 10 Jul 2007 13:50:42 -0700
Subject: [mcclim-devel] Tooltip stuff
Message-ID: <1809.1184100642@snapdragon.csl.sri.com>


A few weeks ago I posted some code to do tooltips.  I now have a new
version that is more intelligent about placing the tooltip.

Nobody responded to my previous message so I'm wondering if anyone is
interested in this.  It's not particularly "CLIM-y" I suppose.

Anyway here it is.  It does show up some issues with McCLIM's erasing
and drawing stuff.  For example, if you compile this code and the three
test functions, then run (clim-demo::demodemo) and run the border styles
test, you'll see that the drawing locations are all screwed up.
However, if you run the address book you'll see that it looks OK there,
but if you enlarge the address book window so that you can see the whole
tool tip and move your mouse around, you'll see that it leaves turds.

This doesn't happen with Allegro Clim.

I've noticed issues with McCLIM's erasing stuff before.  Running
Abigail, for example, and running the test function from the menu, it
leaves all kinds of cruft on the screen that it doesn't in Allegro.

I bring this up just to inform people who might (or might not) want to
fix it.

Tooltip code:


;;; -*- Mode: Common-Lisp -*-

;;;    Use tooltips with CLIM presentations
;;;    Copyright (C) 2007 SRI International.
;;;
;;;    This library is free software; you can redistribute it and/or
;;;    modify it under the terms of the GNU Library General Public
;;;    License as published by the Free Software Foundation; either
;;;    version 2 of the License, or (at your option) any later version.

;;;    This library is distributed in the hope that it will be useful,
;;;    but WITHOUT ANY WARRANTY; without even the implied warranty of
;;;    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;;;    Library General Public License for more details.

;;;    You should have received a copy of the GNU Library General Public
;;;    License along with this library; if not, write to the
;;;    Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;;;    Boston, MA  02111-1307  USA.


;;============================= CLIM Tooltips ===============================
;; Written by Suzanne Paley.
;; To use tooltips w/ clim presentations, define after methods for the clim
;; presentation-method clim:highlight-presentation.  When the state argument
;; is :highlight, the method should call draw-tooltip.  When the state
;; argument is :unhighlight, the method should call erase-tooltip.  Here's
;; a sample call (which assumes the fn get-tooltip-text returns a string 
;; or NIL):
;;
;;;(clim:define-presentation-method clim:highlight-presentation :after
;;;  ((type t) record stream (state (eql :highlight)))
;;;  (draw-tooltip stream (get-tooltip-text record)
;;;                :region (orec-relative->absolute-region record stream)))
;;;
;;;(clim:define-presentation-method clim:highlight-presentation :after
;;;  ((type t) record stream (state (eql :unhighlight)))
;;;  (declare (ignore record))
;;;  (erase-tooltip stream)
;;;  )
;;
;; At some point, we may want to extend the tooltip functionality to allow
;; for arbitrary output w/in a tooltip (i.e. not just a string, maybe
;; graphics too).

(defvar *tooltip-textstyle* 
    (clim:make-text-style :sans-serif :roman :very-small))

;; Once an application frame has been initialized, an application will 
;; probably want to change this color to something more appealing!
(defvar *tooltip-color* clim:+yellow+)

(defvar *tooltip-orec* nil)


;; ============================================================= draw-tooltip 
;; [API]
;; Description : Draw a box containing text, to be used as a tooltip.  
;;  Either a region or x- and y-coordinates should be supplied.  
;;  If coordinates are supplied, the box will have its upper left
;;  corner at that position.  If  no coordinates are supplied but a clim
;;  region is, the box will be positioned close to that region, but not
;;  overlapping it.  Currently it is displayed immediately below the region,
;;  but this should be changed to ensure that the entire box is positioned
;;  within the viewport.  If no position and no region are supplied, the box
;;  is drawn at (0,0).  We actually output the text twice, once
;;  to compute its size and the second time to actually render it -- we
;;  may be able to make this more efficient.
;; 
;;      Arguments : stream: the clim stream to output to
;;                  text: a string or NIL
;;                  region: a clim region (optional) -- the tooltip should be
;;                   positioned near this region.
;;                  x,y: integers (optional) -- if supplied, the tooltip will
;;                   have its upper left corner at this position.
;;                  text-render-fn: A function, defaulting to clim:draw-text*,
;;                   used to render the text.  Must the same arguments 
;;                   as clim:draw-text*.
;;        Returns : nothing
;;   Side Effects : sets *tooltip-orec*
;; Update History : gilham:Jul-10-2007 More intelligent positioning of tooltip.

(defun draw-tooltip (stream text
		     &key region x y
			  (text-render-fn #'clim:draw-text*))
  (erase-tooltip stream) ;; clear previous tooltip, if there is one
  (when (and text (not (equal text "")))
    (clim:with-drawing-options (stream :text-style *tooltip-textstyle*
				       :ink clim:+black+)
      (let ((margin 2))
	(multiple-value-bind (wd ht)
	    (clim:bounding-rectangle-size 
	     (clim:with-output-to-output-record (stream)
	       (funcall text-render-fn stream text 0 0)))
	  (setf *tooltip-orec*
	    (clim:with-output-recording-options (stream :draw nil :record t)
	      (clim:with-new-output-record (stream)
		(clim:draw-rectangle* stream (- margin) (- margin)
				      (+ wd margin) (+ ht margin)
				      :ink *tooltip-color*)
		(clim:draw-rectangle* stream (- margin) (- margin)
				      (+ wd margin) (+ ht margin)
				      :filled nil)
		(funcall text-render-fn stream text 0 0
				      :align-x :left :align-y :top)
		)))
	  (when (and region (not (and x y)))
	    ;; We may want to get smarter about positioning of the tooltip
	    (multiple-value-setq (x y) (clim:stream-pointer-position stream))
	    (if (and x y)
		(let* ((viewport-br (clim:window-viewport stream))
		       (viewport-max-x (clim:bounding-rectangle-max-x viewport-br))
		       (viewport-min-x (clim:bounding-rectangle-min-x viewport-br))
		       (viewport-max-y (clim:bounding-rectangle-max-y viewport-br))
		       (viewport-min-y (clim:bounding-rectangle-min-y viewport-br))
		       (tooltip-max-x (clim:bounding-rectangle-max-x *tooltip-orec*))
		       (tooltip-max-y (clim:bounding-rectangle-max-y *tooltip-orec*))
		       )
		  ;; Get the tool tip clear of the pointer.
		  (setf x (+ x 10)
			y (- y 10 tooltip-max-y))
		  ;; Try to keep the tool tip in the viewport.
		  (when (> (+ x tooltip-max-x) viewport-max-x)
		    (decf x (+ (- (+ x tooltip-max-x) viewport-max-x) margin))
		    (when (< x viewport-min-x) (setf x viewport-min-x)))
		  (when (< y viewport-min-y)
		    (incf y 40)
		    (when (> y viewport-max-y) (setf y (- viewport-max-y tooltip-max-y)))
		  ))
	      (setq x (or x 0)
		    y (or y 0))))
	  ))
      (setf (clim:output-record-position *tooltip-orec*) (values x y))
      (clim:tree-recompute-extent *tooltip-orec*)
      (clim:replay *tooltip-orec* stream)
      )))

;; Erase a tooltip drawn by draw-tooltip
;;   Side Effects : sets *tooltip-orec* to nil
(defun erase-tooltip (stream)
  (when *tooltip-orec*
    (clim:erase-output-record *tooltip-orec* stream nil)
    (setf *tooltip-orec* nil)
    ))


;; ============================================ orec-relative->absolute-region
;; [API]
;;    Description : Given an output record, return a clim
;;                   region that reflects its actual position in the window.
;;      Arguments : orec: an output-record
;;          stream: the stream on which orec was displayed
;;        Returns : a clim region
;;   Side Effects : none
;; Update History :

(defun orec-relative->absolute-region (orec stream)
  (multiple-value-bind (xoff yoff)
      #+mcclim
      (climi::convert-from-relative-to-absolute-coordinates stream orec)
      #-mcclim
      (clim:convert-from-relative-to-absolute-coordinates stream orec)
    (clim:transform-region (clim:make-translation-transformation xoff yoff)
			   orec)))


;;;
;;; Test code
;;;
#||
(clim:define-presentation-method clim:highlight-presentation :after
  ((type t) record stream (state (eql :highlight)))
  (unless (eq type 'clim:blank-area)
    (draw-tooltip stream (get-tooltip-text record)
		  :region (orec-relative->absolute-region record stream))))

(clim:define-presentation-method clim:highlight-presentation :after 
  ((type t) record stream (state (eql :unhighlight)))
  (declare (ignore record))
  (unless (eq type 'clim:blank-area)
    (erase-tooltip stream)
  ))

(defun get-tooltip-text (record)
;;  (declare (ignore record))
;;  "This is a tooltip!"
  (format nil "~A" record)
)
||#


From david at lichteblau.com  Sun Jul 15 12:44:03 2007
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 15 Jul 2007 14:44:03 +0200
Subject: [mcclim-devel] Tooltip stuff
In-Reply-To: <1809.1184100642@snapdragon.csl.sri.com>
References: <1809.1184100642@snapdragon.csl.sri.com>
Message-ID: <20070715124403.GA23042@ununoctium>

Quoting Fred Gilham (gilham at csl.sri.com):
> A few weeks ago I posted some code to do tooltips.  I now have a new
> version that is more intelligent about placing the tooltip.

In a CLIM listener pane that is scrolled down, the tooltips appear at
weird positions (output record at the bottom, tooltip at the top).
Without scrolling it works fine.

> Nobody responded to my previous message so I'm wondering if anyone is
> interested in this.  It's not particularly "CLIM-y" I suppose.

Looks like a useful example.  Perhaps something that should be available
through demodemo as port of a complete application?

> I've noticed issues with McCLIM's erasing stuff before.  Running
> Abigail, for example, and running the test function from the menu, it
> leaves all kinds of cruft on the screen that it doesn't in Allegro.

Fix checked in, please test!


d.


From csr21 at cantab.net  Sun Jul 15 19:42:25 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Sun, 15 Jul 2007 20:42:25 +0100
Subject: [mcclim-devel] Tooltip stuff
In-Reply-To: <20070715124403.GA23042@ununoctium> (David Lichteblau's message
	of "Sun, 15 Jul 2007 14:44:03 +0200")
References: <1809.1184100642@snapdragon.csl.sri.com>
	<20070715124403.GA23042@ununoctium>
Message-ID: <877ip1ihcu.fsf@cantab.net>

David Lichteblau <david at lichteblau.com> writes:

>> I've noticed issues with McCLIM's erasing stuff before.  Running
>> Abigail, for example, and running the test function from the menu, it
>> leaves all kinds of cruft on the screen that it doesn't in Allegro.
>
> Fix checked in, please test!

I only skimmed the fix, but: are you (um, "we") now erasing a slightly
larger rectangle than the bounding rectangle of the output record?  If
so, is that not capable of erasing something that the rest of the
machinery will think doesn't need to be redrawn?

Cheers,

Christophe


From david at lichteblau.com  Sun Jul 15 20:07:21 2007
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 15 Jul 2007 22:07:21 +0200
Subject: [mcclim-devel] Tooltip stuff
In-Reply-To: <877ip1ihcu.fsf@cantab.net>
References: <1809.1184100642@snapdragon.csl.sri.com>
	<20070715124403.GA23042@ununoctium> <877ip1ihcu.fsf@cantab.net>
Message-ID: <20070715200721.GA23648@ununoctium>

Quoting Christophe Rhodes (csr21 at cantab.net):
> I only skimmed the fix, but: are you (um, "we") now erasing a slightly
> larger rectangle than the bounding rectangle of the output record?  If
> so, is that not capable of erasing something that the rest of the
> machinery will think doesn't need to be redrawn?

STREAM-REPLAY is called in the same function with the enlarged rectangle
as an argument, so it should redraw exactly the parts that have been
cleared.


d.

PS In the address book, I notice that in one of the panes the tooltips
still leave fragments, but that is because the text is being drawn at a
bogus position, hanging out of the rectangle.  That is an unrelated bug
and remains to be fixed.


From csr21 at cantab.net  Mon Jul 16 20:46:28 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 16 Jul 2007 21:46:28 +0100
Subject: [mcclim-devel] bezier simplification
Message-ID: <877ip0ulej.fsf@cantab.net>

Hi,

I think the attached patch implements a slight simplification of
convolution of areas with regions: since segments within bezier curves
are by construction connected (p3 of one segment is p0 of the next),
the convolution was including duplicates from the region at successive
endpoints.

The gsharp :quarter-rest becomes a union of 32 bezier areas with this
patch (down from 47), and doesn't look noticeably different to me,
either with the X or the html canvas output methods; the canvas output
is overall smaller by 20%, just from this change.

I believe that there are still duplicate regions in the quarter rest,
but if this change could be reviewed I'd be happy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bezier.diff
Type: text/x-diff
Size: 2813 bytes
Desc: fewer duplicate regions
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070716/adcdb539/attachment.diff>
-------------- next part --------------

Cheers,

Christophe

From csr21 at cantab.net  Mon Jul 16 21:26:42 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 16 Jul 2007 22:26:42 +0100
Subject: [mcclim-devel] bezier simplification
In-Reply-To: <877ip0ulej.fsf@cantab.net> (Christophe Rhodes's message of "Mon, 
	16 Jul 2007 21:46:28 +0100")
References: <877ip0ulej.fsf@cantab.net>
Message-ID: <873azoujjh.fsf@cantab.net>

Christophe Rhodes <csr21 at cantab.net> writes:

> the canvas output is overall smaller by 20%, just from this change.

(that is measured using gsharp's rapsoden-sjunger.gsh score)

> I believe that there are still duplicate regions in the quarter rest,
> but if this change could be reviewed I'd be happy.

There are indeed some more duplicates, arising from split points
returned from FIND-SPLIT-POINTS differing by one part in 10^8 or so:

    1: CLIM-INTERNALS::FIND-SPLIT-POINTS returned
         (0.03709000980332888d0 0.16700945980421777d0 0.167009459804218d0
          0.3339371876264945d0 0.6123851602108852d0 0.8777177045678732d0
          0.8777177045678737d0)

    1: CLIM-INTERNALS::FIND-SPLIT-POINTS returned
         (0.20963359401083448d0 0.2096335983836628d0 0.6517729758960513d0
          0.6517729766787337d0)

maybe these should be tested for equality in the remove-duplicates
call in find-split-points using an epsilon of some magnitude?
Removing these four effective duplicates would reduce the quarter rest
design to a union of 24 areas.

Cheers,

Christophe


From strandh at labri.fr  Tue Jul 17 04:23:05 2007
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 17 Jul 2007 06:23:05 +0200
Subject: [mcclim-devel] bezier simplification
In-Reply-To: <877ip0ulej.fsf@cantab.net>
References: <877ip0ulej.fsf@cantab.net>
Message-ID: <18076.17449.999256.230756@serveur5.labri.fr>

Christophe Rhodes writes:
 >
 > but if this change could be reviewed I'd be happy.

Looks good to me. 
-- 
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.
---------------------------------------------------------------------


From jeremy.rayman at gmail.com  Tue Jul 17 05:05:47 2007
From: jeremy.rayman at gmail.com (Jeremy Rayman)
Date: Mon, 16 Jul 2007 22:05:47 -0700
Subject: [mcclim-devel] Gtkairo backspace issue
Message-ID: <2fc9a7750707162205rf8baf2ap2a2c35ca328cf5a6@mail.gmail.com>

It's great to see the additional keylayout support from this gtkairo commit:
http://common-lisp.net/pipermail/mcclim-cvs/2007-July/001019.html

But the following line appears to have broken my backspace key:
+(DEFINE-KEY 65288 ((4 8 0) :BACKSPACE #\Backspace) (T :TERMINATE-SERVER
NIL))

Now whenever I hit backspace in a McCLIM app I get the message
"TERMINATE-SERVER is unbound", and nothing gets deleted.

Commenting the aforementioned line makes the backspace key work fine.


If it helps, here's the Xev readout for my backspace key.

KeyPress event, serial 25, synthetic NO, window 0x1800001,
    root 0xa6, subw 0x0, time 3530064260, (289,239), root:(1826,1282),
    state 0x10, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "
    XmbLookupString gives 1 bytes: (08) "
    XFilterEvent returns: False

KeyRelease event, serial 25, synthetic NO, window 0x1800001,
    root 0xa6, subw 0x0, time 3530064392, (289,239), root:(1826,1282),
    state 0x10, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "

It could also be worth noting that I use the dvorak keyboard layout.


Hope this is useful. Thanks a bunch!

- Jeremy Rayman
jeremy.rayman.public at gmail.com

p.s. I couldn't for the life of me see where to submit a new ticket on Trac.
Do you need a login?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070716/9b8bf3be/attachment.html>