From smustudent1 at yahoo.com  Sun Dec  3 02:43:40 2006
From: smustudent1 at yahoo.com (C Y)
Date: Sat, 2 Dec 2006 18:43:40 -0800 (PST)
Subject: [mcclim-devel] Gsharp + gtkairo error
Message-ID: <20061203024341.18009.qmail@web56714.mail.re3.yahoo.com>

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


From jdunrue at gmail.com  Sun Dec  3 04:23:04 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Sat, 2 Dec 2006 21:23:04 -0700
Subject: [mcclim-devel] questions on text graphics
Message-ID: <d3df77800612022023o42193595o4655cd62aa024fe4@mail.gmail.com>

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


From david at lichteblau.com  Sun Dec  3 08:13:38 2006
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 3 Dec 2006 09:13:38 +0100
Subject: [mcclim-devel] Gsharp + gtkairo error
In-Reply-To: <20061203024341.18009.qmail@web56714.mail.re3.yahoo.com>
References: <20061203024341.18009.qmail@web56714.mail.re3.yahoo.com>
Message-ID: <20061203081338.GA29075@gargravarr.knowledgetools.de>

Quoting C Y (smustudent1 at yahoo.com):
...
> * (gsharp:gsharp)
> 
>   There is no applicable method for the generic function
>     #<STANDARD-GENERIC-FUNCTION CLIM:GADGET-ACTIVE-P (1)>

Thanks, fix checked in.


David


From david at lichteblau.com  Sun Dec  3 08:47:20 2006
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 3 Dec 2006 09:47:20 +0100
Subject: [mcclim-devel] questions on text graphics
In-Reply-To: <d3df77800612022023o42193595o4655cd62aa024fe4@mail.gmail.com>
References: <d3df77800612022023o42193595o4655cd62aa024fe4@mail.gmail.com>
Message-ID: <20061203084720.GA29175@gargravarr.knowledgetools.de>

Quoting Jack Unrue (jdunrue at gmail.com):
> 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

Those are "what-if" functions.  All the SYNC-* operations in Gtkairo
update the cairo context state for the current medium state before using
cairo only as a matter of principle.  (In this case, it is not even the
current medium's cairo context, these operations get directed to an
extra cairo context.)

The medium is probably just an argument to this function because it
serves as the class to dispatch on.  The existing backends do not even
take the medium's transformation into account.

> 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?

Well, the font metric functions are the only special case where there is
such an argument.

But for all other functions, synchronizing the graphics context should
be possible in the way you are suggesting.  Gilbert tried to explain to
me why the cairo medium does not do that, and I have to admit that I did
not understand his explanation.  It had something to do with
DO-GRAPHICS-WITH-OPTIONS-INTERNAL.

> 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?

Your backend would be in good company.  ;-)  Gtkairo also assumes that
any sort of buffering is always okay and completely ignores
MEDIUM-OUTPUT-BUFFERING-P.  Since MEDIUM-FORCE-OUTPUT and
PORT-FORCE-OUTPUT get called by the frontend, things tend to work
anyway.  Gtkairo keeps track of the mediums that have been touched and
processes them all in PORT-FORCE-OUTPUT.

The current double buffering implementation in Gtkairo (enabled only on
Windows because it creates those huge pixmaps and ends up being rather
slow for large panes) never draws to windows directly at all.  It always
draws to the pixmaps, then bitblts the pixmap to the window in the event
loop.  That was necessary because GTK+ didn't seem to like all that
drawing happening outside of the event loop.


David


From smustudent1 at yahoo.com  Sun Dec  3 11:24:05 2006
From: smustudent1 at yahoo.com (C Y)
Date: Sun, 3 Dec 2006 03:24:05 -0800 (PST)
Subject: [mcclim-devel] Another gsharp+gtkairo error, plus good news
Message-ID: <20061203112406.81821.qmail@web56713.mail.re3.yahoo.com>

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 


From thomas at spacecentre.se  Sun Dec  3 13:25:41 2006
From: thomas at spacecentre.se (Thomas Persson)
Date: Sun, 03 Dec 2006 14:25:41 +0100
Subject: [mcclim-devel] Re: Another gsharp+gtkairo error, plus good news
References: <20061203112406.81821.qmail@web56713.mail.re3.yahoo.com>
Message-ID: <87d5716rhm.fsf@opinion.spacecentre.se>

C Y <smustudent1 at yahoo.com> writes:

> 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

I notice the same error with gtkairo when trying to output a non ascii
character to a pane so that's probably what gsharp is trying to
do. The following code should trigger it:

(define-application-frame test ()
  ()
  (:panes
   (app :application
        :display-function (lambda (frame pane)
                            (write-char #\LATIN_SMALL_LETTER_O_WITH_DIAERESIS
                                        pane))))
  (:layouts
   (default (vertically ()
              app))))

(run-frame-top-level (make-application-frame 'test))



From david at lichteblau.com  Sun Dec  3 15:37:06 2006
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 3 Dec 2006 16:37:06 +0100
Subject: [mcclim-devel] Re: Another gsharp+gtkairo error, plus good news
In-Reply-To: <87d5716rhm.fsf@opinion.spacecentre.se>
References: <20061203112406.81821.qmail@web56713.mail.re3.yahoo.com>
	<87d5716rhm.fsf@opinion.spacecentre.se>
Message-ID: <20061203153706.GA30178@gargravarr.knowledgetools.de>

Quoting Thomas Persson (thomas at spacecentre.se):
> I notice the same error with gtkairo when trying to output a non ascii
> character to a pane so that's probably what gsharp is trying to
> do. The following code should trigger it:

Yes, right.
I'm still waiting for cffi to support UTF-8 out of the box...


d.


From smustudent1 at yahoo.com  Sun Dec  3 16:49:53 2006
From: smustudent1 at yahoo.com (C Y)
Date: Sun, 3 Dec 2006 08:49:53 -0800 (PST)
Subject: [mcclim-devel] One more gtkairo gotcha
Message-ID: <20061203164953.99496.qmail@web56708.mail.re3.yahoo.com>

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.


From jdunrue at gmail.com  Sun Dec  3 21:12:45 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 3 Dec 2006 14:12:45 -0700
Subject: [mcclim-devel] questions on text graphics
In-Reply-To: <20061203084720.GA29175@gargravarr.knowledgetools.de>
References: <d3df77800612022023o42193595o4655cd62aa024fe4@mail.gmail.com>
	<20061203084720.GA29175@gargravarr.knowledgetools.de>
Message-ID: <d3df77800612031312o7508305gffdd844050ecb150@mail.gmail.com>

Thanks David!

-- 
Jack Unrue


From strandh at labri.fr  Mon Dec  4 11:10:17 2006
From: strandh at labri.fr (Robert Strandh)
Date: Mon, 4 Dec 2006 12:10:17 +0100
Subject: [mcclim-devel] Drie crashes on: "`(,@a "
Message-ID: <17780.537.229706.873875@serveur5.labri.fr>

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 "`(, at 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.
---------------------------------------------------------------------


From athas at sigkill.dk  Mon Dec  4 18:39:13 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 04 Dec 2006 19:39:13 +0100
Subject: [mcclim-devel] Drie crashes on: "`(,@a "
In-Reply-To: <17780.537.229706.873875@serveur5.labri.fr> (Robert Strandh's
	message of "Mon, 4 Dec 2006 12:10:17 +0100")
References: <17780.537.229706.873875@serveur5.labri.fr>
Message-ID: <87wt57ld4e.fsf@sigkill.dk>

Robert Strandh <strandh at labri.fr> writes:

> Drei crashes with an error message saying that #:A is not of type
> list. 

Hm. Nasty. Fixed in CVS, but I see I have to rewrite the whole
`token-to-object' idea. I'm not terribly surprised, I don't think I
originally imagined it would become as critical as it is.

-- 
\  Troels "Athas"
/\ Henriksen


From athas at sigkill.dk  Mon Dec  4 21:58:15 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 04 Dec 2006 22:58:15 +0100
Subject: [mcclim-devel] CLIM 2.0 versus CLIM 2.2
Message-ID: <87mz63l3wo.fsf@sigkill.dk>

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


From hrapof at common-lisp.ru  Thu Dec  7 08:40:31 2006
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Thu, 7 Dec 2006 08:40:31 +0000 (UTC)
Subject: [mcclim-devel] Freetype and CFFI
Message-ID: <loom.20061207T093924-493@post.gmane.org>

(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



From rpgoldman at sift.info  Thu Dec  7 13:40:47 2006
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Thu, 07 Dec 2006 07:40:47 -0600
Subject: [mcclim-devel] Freetype and CFFI
In-Reply-To: <loom.20061207T093924-493@post.gmane.org>
References: <loom.20061207T093924-493@post.gmane.org>
Message-ID: <457819DF.2070204@sift.info>

Dmitri Hrapof wrote:
> (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
> 
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> 
Dmitri,
I cargo-culted a mcclim-freetype-cffi out of mcclim-freetype (because 
the latter was SBCL specific and I use ACL).
Have a look in the McCLIM CVS repository.  You should find it there.

I'm afraid that I can't help you much beyond that --- I didn't actually 
*understand* freetype, I just removed the SBCL dependencies from 
mcclim-freetype (which is really mcclim-freetype-sbcl, AFAICT).

I've been hoping that the CFFI version would become more official, but 
it doesn't seem to have gotten any traction.  I'm not actually sure that 
freetype in general has, for that matter.

HTH,
Robert

-- 
Robert P. Goldman
Senior Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

211 N. First St., Suite 300
Minneapolis, MN 55401

Voice:	(612) 384-3454
Email:    rpgoldman at SIFT.info


From hrapof at common-lisp.ru  Thu Dec  7 13:53:12 2006
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Thu, 7 Dec 2006 13:53:12 +0000 (UTC)
Subject: [mcclim-devel] Re: Freetype and CFFI
References: <loom.20061207T093924-493@post.gmane.org>
	<457819DF.2070204@sift.info>
Message-ID: <loom.20061207T144927-884@post.gmane.org>

Robert P. Goldman <rpgoldman <at> sift.info> writes:

> I cargo-culted a mcclim-freetype-cffi out of mcclim-freetype (because 
> the latter was SBCL specific and I use ACL).

And I took much of my small code from your mcclim-freetype-cffi. Thank you very
much!



From rydis at cd.chalmers.se  Thu Dec  7 14:04:30 2006
From: rydis at cd.chalmers.se (Martin Rydstr|m)
Date: Thu, 7 Dec 2006 15:04:30 +0100
Subject: [mcclim-devel] Freetype and CFFI
In-Reply-To: <457819DF.2070204@sift.info>
References: <loom.20061207T093924-493@post.gmane.org>
	<457819DF.2070204@sift.info>
Message-ID: <20061207140430.GP3757@haddock.cd.chalmers.se>

On Thu, Dec 07, 2006 at 07:40:47AM -0600, Robert P. Goldman wrote:
> I'm afraid that I can't help you much beyond that --- I didn't actually 
> *understand* freetype, I just removed the SBCL dependencies from 
> mcclim-freetype (which is really mcclim-freetype-sbcl, AFAICT).

mcclim-freetype works fine with CMUCL, too. (Although you might need to
be running telent-clx, rather than the CLX that comes with CMUCL.)

',mr

-- 
rydis (Martin Rydstr?m) @CD.Chalmers.SE             http://www.rydis.se

[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_


From smustudent1 at yahoo.com  Thu Dec  7 16:12:13 2006
From: smustudent1 at yahoo.com (C Y)
Date: Thu, 7 Dec 2006 08:12:13 -0800 (PST)
Subject: [mcclim-devel] Freetype and CFFI
In-Reply-To: <457819DF.2070204@sift.info>
Message-ID: <20061207161214.57056.qmail@web56705.mail.re3.yahoo.com>

--- "Robert P. Goldman" <rpgoldman at sift.info> wrote:
> I've been hoping that the CFFI version would become more official,
> but it doesn't seem to have gotten any traction.  I'm not actually
> sure that freetype in general has, for that matter.

>From the "I should know better than to ask this" department...

What would it take to do a native lisp implementation of something like
Freetype?  Could the MetaFont type work being done in Gsharp forme the
basis for such an effort?

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From rpgoldman at real-time.com  Thu Dec  7 16:26:01 2006
From: rpgoldman at real-time.com (Robert Goldman)
Date: Thu, 07 Dec 2006 10:26:01 -0600
Subject: [mcclim-devel] Freetype and CFFI
In-Reply-To: <20061207140430.GP3757@haddock.cd.chalmers.se>
References: <loom.20061207T093924-493@post.gmane.org>
	<457819DF.2070204@sift.info>
	<20061207140430.GP3757@haddock.cd.chalmers.se>
Message-ID: <45784099.2080104@real-time.com>

Martin Rydstr|m wrote:
> On Thu, Dec 07, 2006 at 07:40:47AM -0600, Robert P. Goldman wrote:
>> I'm afraid that I can't help you much beyond that --- I didn't actually 
>> *understand* freetype, I just removed the SBCL dependencies from 
>> mcclim-freetype (which is really mcclim-freetype-sbcl, AFAICT).
> 
> mcclim-freetype works fine with CMUCL, too. (Although you might need to
> be running telent-clx, rather than the CLX that comes with CMUCL.)
> 
> ',mr
> 
OK.  I stand corrected.  Nevertheless, I argue that a freetype approach 
based on CFFI, which is portable over non-CMU-derived lisps as well as 
CMU-derived lisps is preferable, prima facie.
Now, there may be some additional considerations that would make the 
CMU-derived-specific approach better, but I don't know of any.  If you 
do, please let me know.

Note I'm not trying to brag about my code and denigrate others.  All I 
did was tweak the CMU-derived-specific approach to backend to CFFI 
instead, a pretty minor change (and one that I did with virtually no 
understanding of the code.

Cheers,
R


From brian at mastenbrook.net  Fri Dec  8 03:05:07 2006
From: brian at mastenbrook.net (Brian Mastenbrook)
Date: Thu, 07 Dec 2006 21:05:07 -0600
Subject: [mcclim-devel] Freetype and CFFI
In-Reply-To: <45784099.2080104@real-time.com>
References: <loom.20061207T093924-493@post.gmane.org>	<457819DF.2070204@sift.info>	<20061207140430.GP3757@haddock.cd.chalmers.se>
	<45784099.2080104@real-time.com>
Message-ID: <4578D663.3020307@mastenbrook.net>

Robert Goldman wrote:
> OK.  I stand corrected.  Nevertheless, I argue that a freetype approach 
> based on CFFI, which is portable over non-CMU-derived lisps as well as 
> CMU-derived lisps is preferable, prima facie.
> Now, there may be some additional considerations that would make the 
> CMU-derived-specific approach better, but I don't know of any.  If you 
> do, please let me know.
> 
> Note I'm not trying to brag about my code and denigrate others.  All I 
> did was tweak the CMU-derived-specific approach to backend to CFFI 
> instead, a pretty minor change (and one that I did with virtually no 
> understanding of the code.

To add some historical perspective to the issue:

The mcclim-freetype code was created by Gilbert Baumann. I did the 
initial conversion to SBCL. This involved more than just changing 
package names; in order to make it usable, the code had to be changed 
such that SBCL no longer warned about runtime calls to %SAP-ALIEN. Not 
only did it worn at compile time about this; it actually generated 
warnings at runtime initially too. Along the way, I added a few caches 
to speed up glyph rendering, which finally resulted in something I could 
bear to use daily in climacs and the listener.

Making the compiler happy wrt %SAP-ALIEN was not trivial, and if there's 
anything I would be worried about in the CFFI version, it's that 
somewhere one of those optimizations is not implemented. If it's usably 
fast, I guess everything is OK. Not having used CFFI, I don't know if 
SBCL will still warn about these as profusely as it does when using good 
ol' SB-ALIEN.

-- 
Brian Mastenbrook
brian at mastenbrook.net
http://brian.mastenbrook.net/


From nikodemus at random-state.net  Fri Dec  8 10:59:20 2006
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Fri, 08 Dec 2006 12:59:20 +0200
Subject: [mcclim-devel] Re: Freetype and CFFI
References: <loom.20061207T093924-493@post.gmane.org>
	<457819DF.2070204@sift.info>
	<20061207140430.GP3757@haddock.cd.chalmers.se>
	<45784099.2080104@real-time.com> <4578D663.3020307@mastenbrook.net>
Message-ID: <87r6vaejqv.fsf@logxor.random-state.net>

Brian Mastenbrook <brian at mastenbrook.net> writes:

> Making the compiler happy wrt %SAP-ALIEN was not trivial, and if
> there's anything I would be worried about in the CFFI version, it's
> that somewhere one of those optimizations is not implemented. If it's
> usably fast, I guess everything is OK. Not having used CFFI, I don't
> know if SBCL will still warn about these as profusely as it does when
> using good ol' SB-ALIEN.

I don't think that should be a worry: AFAIK CFFI uses plain SAPs all the
time, making it oftentimes faster then SB-ALIEN. (The downside of this
approach is losing the type-safety SB-ALIEN provides).

...or that is my impression, but I'm not awfully familiar with CFFI.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."



From rpgoldman at sift.info  Fri Dec  8 14:09:43 2006
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Fri, 08 Dec 2006 08:09:43 -0600
Subject: [mcclim-devel] Freetype and CFFI
In-Reply-To: <4578D663.3020307@mastenbrook.net>
References: <loom.20061207T093924-493@post.gmane.org>	<457819DF.2070204@sift.info>	<20061207140430.GP3757@haddock.cd.chalmers.se>
	<45784099.2080104@real-time.com> <4578D663.3020307@mastenbrook.net>
Message-ID: <45797227.7080202@sift.info>

Brian Mastenbrook wrote:
> Robert Goldman wrote:
>> OK.  I stand corrected.  Nevertheless, I argue that a freetype
>> approach based on CFFI, which is portable over non-CMU-derived lisps
>> as well as CMU-derived lisps is preferable, prima facie.
>> Now, there may be some additional considerations that would make the
>> CMU-derived-specific approach better, but I don't know of any.  If you
>> do, please let me know.
>>
>> Note I'm not trying to brag about my code and denigrate others.  All I
>> did was tweak the CMU-derived-specific approach to backend to CFFI
>> instead, a pretty minor change (and one that I did with virtually no
>> understanding of the code.
> 
> To add some historical perspective to the issue:
> 
> The mcclim-freetype code was created by Gilbert Baumann. I did the
> initial conversion to SBCL. This involved more than just changing
> package names; in order to make it usable, the code had to be changed
> such that SBCL no longer warned about runtime calls to %SAP-ALIEN. Not
> only did it worn at compile time about this; it actually generated
> warnings at runtime initially too. Along the way, I added a few caches
> to speed up glyph rendering, which finally resulted in something I could
> bear to use daily in climacs and the listener.
> 
> Making the compiler happy wrt %SAP-ALIEN was not trivial, and if there's
> anything I would be worried about in the CFFI version, it's that
> somewhere one of those optimizations is not implemented. If it's usably
> fast, I guess everything is OK. Not having used CFFI, I don't know if
> SBCL will still warn about these as profusely as it does when using good
> ol' SB-ALIEN.
> 
It's not that easy for me to test with SBCL (at least it's un-easy
enough that I won't be able to get to it until after the start of the
new year).  I'd encourage you to have a whirl at the CFFI version of
Freetype.  I tried not to do anything that would make it not work on
SBCL, but I can't swear that I did it all right...

BTW, I did initially try to make a version of freetype that would use a
bunch of #+ and #- to add ACL support.  It was just too hard for me,
simple differences b/w the two models of foreign function calls foiled
me.  And, of course, even if I had managed it, that still would have
left clisp and lispworks (at least) out in the cold.  I hope that CFFI
will be A Good Thing.  It is for me, anyway, since beirc is now much
prettier!

-- 
Robert P. Goldman
Senior Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

211 N. First St., Suite 300
Minneapolis, MN 55401

Voice:	(612) 384-3454
Email:    rpgoldman at SIFT.info


From hrapof at common-lisp.ru  Sun Dec 10 15:26:47 2006
From: hrapof at common-lisp.ru (Dmitri Hrapof)
Date: Sun, 10 Dec 2006 15:26:47 +0000 (UTC)
Subject: [mcclim-devel] Re: Freetype and CFFI
References: <loom.20061207T093924-493@post.gmane.org>
Message-ID: <loom.20061210T162234-48@post.gmane.org>

Thanks to everybody who spent their time on this issue.

It seems that call 

(load-char face char :ft-load-monochrome)

was not sufficient, contrary to my (under)undestanding of FreeType docs.
Instead, two calls

(load-char face char :ft-load-default)
...
(render-glyph glyph :ft-render-mode-mono)

made what I wanted.

If anyone knows FreeType expert, please ask him about this.

Sincerely yours,
Dmitri



From jdunrue at gmail.com  Mon Dec 11 03:58:14 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 10 Dec 2006 20:58:14 -0700
Subject: [mcclim-devel] snapshot of clim-graphic-forms backend
Message-ID: <d3df77800612101958p67ee7a1avf86941ea16b0bc00@mail.gmail.com>

I've uploaded a snapshot of my work on a McCLIM backend for
Windows:

http://home.earthlink.net/~jdunrue/clim-graphic-forms.zip

The README in that zip file explains:

This directory contains the start of a McCLIM backend implementation
for Win32 using the Graphic-Forms library. I am making this snapshot
available in the hopes that someone else possessing sufficient time,
motivation, and McCLIM knowledge can pick up where I've left off.

Files in this archive:

  mcclim.asd               -- a patched version of mcclim.asd (rev 1.39)
                              defining a new system called
                              :clim-graphic-forms

  ports.lisp               -- a patched version of ports.lisp (rev 1.53)
                              that adds the symbol :graphic-forms to
                              *server-path-search-order*

  Backends/
    Graphic-Forms/

      README.txt           -- this file

      frame-manager.lisp   -- backend code
      gadgets.lisp
      graft.lisp
      medium.lisp
      package.lisp
      port.lisp
      utils.lisp

      loader.lisp          -- a utility to load the system; you can
                              either modify this to suit your local
                              environment or just consult it as a
                              reference


My overall plan was to use existing abstractions provided by
Graphic-Forms on top of the Win32 API rather than re-implement that
infrastructure. Package nicknames GFG: GFS: and GFW: identify symbols
exported from that library.

Many thanks to David L., Troels, and Robert S. for their replies to my
earlier queries. And thanks to Christophe for creating the null
backend, without which getting started would have been much more
difficult. I will be happy to answer questions or provide fixes
for Graphic-Forms to facilitate further development of this backend.

-- 
Jack Unrue
http://common-lisp.net/project/graphic-forms


From toy.raymond at gmail.com  Sat Dec 16 00:55:36 2006
From: toy.raymond at gmail.com (Raymond Toy)
Date: Fri, 15 Dec 2006 19:55:36 -0500
Subject: [mcclim-devel] (declare (values foo)) in scigraph menu-tools.lisp
Message-ID: <elvg68$2i1$2@sea.gmane.org>

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



From toy.raymond at gmail.com  Sat Dec 16 14:52:55 2006
From: toy.raymond at gmail.com (Raymond Toy)
Date: Sat, 16 Dec 2006 09:52:55 -0500
Subject: [mcclim-devel] redisplay-frame-pane with named panes
Message-ID: <em1187$h3u$1@sea.gmane.org>

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)



From toy.raymond at gmail.com  Sat Dec 16 15:01:29 2006
From: toy.raymond at gmail.com (Raymond Toy)
Date: Sat, 16 Dec 2006 10:01:29 -0500
Subject: [mcclim-devel] (setf bounding-rectangle-min-x)
Message-ID: <em11o9$i40$1@sea.gmane.org>

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.)
 	   , at 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.)
+	   , at 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.)
 	   , at body))))))

 (eval-when (compile load eval)



From athas at sigkill.dk  Sat Dec 16 17:29:58 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 16 Dec 2006 18:29:58 +0100
Subject: [mcclim-devel] redisplay-frame-pane with named panes
In-Reply-To: <em1187$h3u$1@sea.gmane.org> (Raymond Toy's message of "Sat, 16
	Dec 2006 09:52:55 -0500")
References: <em1187$h3u$1@sea.gmane.org>
Message-ID: <87r6uzu4tl.fsf@sigkill.dk>

Raymond Toy <toy.raymond at gmail.com> writes:

> 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.

>From the 2.0 spec on `redisplay-frame-pane':

  "Causes the pane pane within the frame frame to be redisplayed
   immediately. pane is either a pane or the name of a named pane."

So this fix looks kosher. Do you have McCLIM commit rights? If not,
I'll test and commit this as soon as I can.

-- 
\  Troels "Athas"
/\ Henriksen


From athas at sigkill.dk  Sat Dec 16 17:33:10 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 16 Dec 2006 18:33:10 +0100
Subject: [mcclim-devel] (setf bounding-rectangle-min-x)
In-Reply-To: <em11o9$i40$1@sea.gmane.org> (Raymond Toy's message of "Sat, 16
	Dec 2006 10:01:29 -0500")
References: <em11o9$i40$1@sea.gmane.org>
Message-ID: <87mz5nu4o9.fsf@sigkill.dk>

Raymond Toy <toy.raymond at gmail.com> writes:

> 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.

These functions should exist according to the CLIM 2.2 spec (page
52). Since you already figured out an equivalent fix for Scigraph,
couldn't you write some definitions for
`bounding-rectangle-{min|max}-{x|y}'? That would probably be better in
the long run.

-- 
\  Troels "Athas"
/\ Henriksen


From toy.raymond at gmail.com  Sat Dec 16 18:35:35 2006
From: toy.raymond at gmail.com (Raymond Toy)
Date: Sat, 16 Dec 2006 13:35:35 -0500
Subject: [mcclim-devel] Re: redisplay-frame-pane with named panes
In-Reply-To: <87r6uzu4tl.fsf@sigkill.dk>
References: <em1187$h3u$1@sea.gmane.org> <87r6uzu4tl.fsf@sigkill.dk>
Message-ID: <45843C77.3080803@gmail.com>

Troels Henriksen wrote:
> Raymond Toy <toy.raymond at gmail.com> writes:
> 
>> 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.
> 
>>From the 2.0 spec on `redisplay-frame-pane':
> 
>   "Causes the pane pane within the frame frame to be redisplayed
>    immediately. pane is either a pane or the name of a named pane."
> 
> So this fix looks kosher. Do you have McCLIM commit rights? If not,
> I'll test and commit this as soon as I can.

I don't have commit rights and would rather keep it that way. :-)

Thanks for testing and committing.  No rush, though.
(And thanks for your help on #lisp as well!)

Ray



From toy.raymond at gmail.com  Sat Dec 16 18:36:49 2006
From: toy.raymond at gmail.com (Raymond Toy)
Date: Sat, 16 Dec 2006 13:36:49 -0500
Subject: [mcclim-devel] Re: (setf bounding-rectangle-min-x)
In-Reply-To: <87mz5nu4o9.fsf@sigkill.dk>
References: <em11o9$i40$1@sea.gmane.org> <87mz5nu4o9.fsf@sigkill.dk>
Message-ID: <45843CC1.9020006@gmail.com>

Troels Henriksen wrote:
> Raymond Toy <toy.raymond at gmail.com> writes:
> 
>> 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.
> 
> These functions should exist according to the CLIM 2.2 spec (page
> 52). Since you already figured out an equivalent fix for Scigraph,
> couldn't you write some definitions for
> `bounding-rectangle-{min|max}-{x|y}'? That would probably be better in
> the long run.
> 

Oh.  I must have been looking at the clim 2.0 spec which didn't seem to
have the setf versions of these.  I'll try and implement them.

Ray



From athas at sigkill.dk  Sat Dec 16 21:57:00 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 16 Dec 2006 22:57:00 +0100
Subject: [mcclim-devel] Re: (setf bounding-rectangle-min-x)
In-Reply-To: <45843CC1.9020006@gmail.com> (Raymond Toy's message of "Sat, 16
	Dec 2006 13:36:49 -0500")
References: <em11o9$i40$1@sea.gmane.org> <87mz5nu4o9.fsf@sigkill.dk>
	<45843CC1.9020006@gmail.com>
Message-ID: <87ejqztsgj.fsf@sigkill.dk>

Raymond Toy <toy.raymond at gmail.com> writes:

> Oh.  I must have been looking at the clim 2.0 spec which didn't seem
> to have the setf versions of these.  I'll try and implement them.

Oh, I just see that the CLIM 2.2 spec doesn't explicitly state the
existence of the `setf' functions, but the actual implementation seems
to have them. Su ein Ding muss ich auch haben! Also, it would be swell
if the synonyms `bounding-rectangle-top', `bounding-rectangle-bottom',
`bounding-rectangle-left' and `bounding-rectangle-right' (and their
`setf' variants) were also implemented.

-- 
\  Troels "Athas"
/\ Henriksen


From david at lichteblau.com  Sun Dec 17 12:29:57 2006
From: david at lichteblau.com (David Lichteblau)
Date: Sun, 17 Dec 2006 13:29:57 +0100
Subject: [mcclim-devel] snapshot of clim-graphic-forms backend
In-Reply-To: <d3df77800612101958p67ee7a1avf86941ea16b0bc00@mail.gmail.com>
References: <d3df77800612101958p67ee7a1avf86941ea16b0bc00@mail.gmail.com>
Message-ID: <20061217122957.GA13304@gargravarr.knowledgetools.de>

Quoting Jack Unrue (jdunrue at gmail.com):
> I've uploaded a snapshot of my work on a McCLIM backend for
> Windows:

Thanks for writing this!

Which Lisp implementation are you using for development?

I just tried SBCL 1.0 on Windows 2000.  Demodemo appears as a window,
but window contents do not get drawn, so the buttons are not visible.
and the address book just says:
  fatal error encountered in SBCL pid 832:
  GC invariant lost, file "gencgc.c", line 833

> My overall plan was to use existing abstractions provided by
> Graphic-Forms on top of the Win32 API rather than re-implement that
> infrastructure. Package nicknames GFG: GFS: and GFW: identify symbols
> exported from that library.

Sure, using Graphic-Forms seems like a good plan.


I would like to suggest this patch for mcclim.asd and ports.lisp instead
of the file replacements from your zip file:

http://www.lichteblau.com/blubba/clim-gf.diff

Diffs are easier to apply than complete copies of the files, and if you
are using CVS, line endings should be handled automatically for you.

My diff also cleans up *server-path-search-order* and adds a comment
explaining the chosen order.  -- If anyone actually has a Genera
backend, please speak up! ;-)


David


From nikodemus at random-state.net  Sun Dec 17 14:38:19 2006
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Sun, 17 Dec 2006 16:38:19 +0200
Subject: [mcclim-devel] Re: snapshot of clim-graphic-forms backend
References: <d3df77800612101958p67ee7a1avf86941ea16b0bc00@mail.gmail.com>
	<20061217122957.GA13304@gargravarr.knowledgetools.de>
Message-ID: <87mz5moaec.fsf@logxor.random-state.net>

David Lichteblau <david at lichteblau.com> writes:

> I just tried SBCL 1.0 on Windows 2000.  Demodemo appears as a window,
> but window contents do not get drawn, so the buttons are not visible.
> and the address book just says:
>   fatal error encountered in SBCL pid 832:
>   GC invariant lost, file "gencgc.c", line 833

This looks like one of the known issues with 1.0 on Win32, onfortunately
something that doesn't happen to everyone with the same inputs, depending
on at least the amount of stack Windows decides to give SBCL.

"Mostly Fixed" for SBCL in CVS, though.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."



From jdunrue at gmail.com  Sun Dec 17 17:39:18 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 17 Dec 2006 10:39:18 -0700
Subject: [mcclim-devel] snapshot of clim-graphic-forms backend
In-Reply-To: <20061217122957.GA13304@gargravarr.knowledgetools.de>
References: <d3df77800612101958p67ee7a1avf86941ea16b0bc00@mail.gmail.com>
	<20061217122957.GA13304@gargravarr.knowledgetools.de>
Message-ID: <d3df77800612170939v39258e97g8e0eba9e01325d6b@mail.gmail.com>

On 12/17/06, David Lichteblau <david at lichteblau.com> wrote:
> Quoting Jack Unrue (jdunrue at gmail.com):
> > I've uploaded a snapshot of my work on a McCLIM backend for
> > Windows:
>
> Thanks for writing this!
>
> Which Lisp implementation are you using for development?

I was using CLISP so that I could run GF-based programs from SLIME.
SBCL and SLIME aren't a good combination where GF is concerned and
I have yet to nail down the problem. I recall seeing a similar problem when
running the gtkairo backend on Win32, actually. Something is going wrong
as a window is created and the early window creation events are dispatched,
so although there is no crash it appears as though nothing is happening. I've
done some investigation with a window spy utility, but that's going off-topic
here.

> I just tried SBCL 1.0 on Windows 2000.  Demodemo appears as a window,
> but window contents do not get drawn, so the buttons are not visible.
> and the address book just says:
>   fatal error encountered in SBCL pid 832:
>   GC invariant lost, file "gencgc.c", line 833

Yep, I've seen several variations of that, too. As Nikodemus mentioned, I
think SBCL from CVS might behave better -- need to try it myself :-)

Assuming that I'm understanding correctly that you were trying to
run the GF backend, there's actually quite a lot of work to be done
yet. I was struggling to understand and fix some basic issues and
basically threw up my hands, hence my email about the snapshot.

The fact that you've taken a look at it is very heartening, and so I'm
feeling motivated to keep working. Thanks!

> I would like to suggest this patch for mcclim.asd and ports.lisp instead
> of the file replacements from your zip file:
>
> http://www.lichteblau.com/blubba/clim-gf.diff

OK, that's fine with me.

-- 
Jack Unrue


From ahefner at gmail.com  Mon Dec 18 18:02:43 2006
From: ahefner at gmail.com (Andy Hefner)
Date: Mon, 18 Dec 2006 13:02:43 -0500
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS mcclim/Backends/CLX
In-Reply-To: <20061217195352.87CD552014@common-lisp.net>
References: <20061217195352.87CD552014@common-lisp.net>
Message-ID: <31ffd3c40612181002q10ec7cb6uf08c141db4495f45@mail.gmail.com>

I'd be very interested if someone with an X server using :msbfirst
byte order could try this (seeing that the file icons in the listener
appear correct is probably sufficient). Every X server available to me
for testing has been :lsbfirst (including X11.app on a PPC Mac,
interestingly), and probably some kind of XFree derivative.

On 12/17/06, ahefner <ahefner at common-lisp.net> wrote:
> Update of /project/mcclim/cvsroot/mcclim/Backends/CLX
> In directory clnet:/tmp/cvs-serv3781
>
> Modified Files:
>         medium.lisp
> Log Message:
> Upload indexed patterns via xlib:put-image. Attempt to handle various
> pixel formats.


From ch-mcclim at bobobeach.com  Thu Dec 21 07:38:34 2006
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Wed, 20 Dec 2006 23:38:34 -0800
Subject: [mcclim-devel] Fwd: [mcclim-cvs] CVS mcclim
References: <20061220200710.5202C2202F@common-lisp.net>
Message-ID: <6F81546F-6364-4E5C-8B1F-4195FDEEB7B6@bobobeach.com>

FWIW, the pango changes break gtkcairo on macos. I'm sure there's an  
easy fix involving finding fonts, but I thought you should now that  
this used to work and no longer does. All the glyphs come up as empty  
rectangles.

Cyrus

Begin forwarded message:

> From: "dlichteblau" <dlichteblau at common-lisp.net>
> Date: December 20, 2006 12:07:10 PM PST
> To: mcclim-cvs at common-lisp.net
> Subject: [mcclim-cvs] CVS mcclim
>
> Update of /project/mcclim/cvsroot/mcclim
> In directory clnet:/tmp/cvs-serv8647
>
> Modified Files:
> 	NEWS
> Log Message:
> updated
>
>
> --- /project/mcclim/cvsroot/mcclim/NEWS	2006/12/14 22:02:16	1.13
> +++ /project/mcclim/cvsroot/mcclim/NEWS	2006/12/20 20:07:10	1.14
> @@ -6,6 +6,9 @@
>  *** Some bugfixes, including CMUCL support and better key event  
> handling.
>  *** Native implementation of context menus, list panes, label  
> panes, and
>      option panes.
> +*** Draw text using Pango.  (Bug fix: Fixed-width font supported  
> on Windows
> +    now.  Multiple lines of output in TEXT-SIZE supported now.
> +    TEXT-STYLE-FIXED-WIDTH-P works correctly now.)
>  ** Improvement: Added new editor substrate ("Drei").
>  ** Improvement: Improved the pathname presentation methods  
> considerably.
>  ** specification compliance: DELETE-GESTURE-NAME function now  
> implemented.
>
> _______________________________________________
> mcclim-cvs mailing list
> mcclim-cvs at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-cvs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20061220/751dcce7/attachment.html>

From eric.marsden at free.fr  Tue Dec 26 15:47:26 2006
From: eric.marsden at free.fr (Eric Marsden)
Date: Tue, 26 Dec 2006 16:47:26 +0100
Subject: [mcclim-devel] bug in CLIM-Listener application
Message-ID: <87irfy7j75.fsf@free.fr>

Hi,

Selecting a menu item in the Listener application leads to the action
object being printed in the listener, for example as

   #<CLIM:MENU-ITEM "Apropos" {10035ECCE1}>

instead of invoking the corresponding function.

This is with McCLIM from CVS, SBCL 1.0.0.34.

-- 
Eric Marsden



From eric.marsden at free.fr  Thu Dec 28 23:52:27 2006
From: eric.marsden at free.fr (Eric Marsden)
Date: Fri, 29 Dec 2006 00:52:27 +0100
Subject: [mcclim-devel] BUG: erasing content in the interactor pane
Message-ID: <87bqln8tok.fsf@free.fr>

Hi,

I see the following bug with CVS McCLIM using Closure and
mcclim-freetype, on SBCL. I recall a previous command with "M-p" (for some
reason I seem to need to type that twice for it to have an effect),
then backspace until the entire argument of the command has been
erased, then run into the following error. 

This problem seems to be correlated to the fact that backspacing over
the command arguments causes the entire command (including elements
that have not yet been deleted) to move leftwards by a few pixels per
backspace. 


The value -1 is not of type (UNSIGNED-BYTE 60).
   [Condition of type TYPE-ERROR]

Restarts:
  0: [ABORT] Return to application command loop
  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Closure" {1003C214C1}>)

Backtrace:
  0: (SB-PRETTY::MAKE-PRETTY-STREAM #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>)
      Locals:
        SB-DEBUG::ARG-0 = 1
        SB-DEBUG::ARG-1 = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
  1: (SB-PRETTY:OUTPUT-PRETTY-OBJECT "Visit" #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>)
      Locals:
        SB-DEBUG::ARG-0 = 2
        SB-DEBUG::ARG-1 = "Visit"
        SB-DEBUG::ARG-2 = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
      Catch-tags:
        SB-PRETTY::LINE-LIMIT-ABBREVIATION-HAPPENED
  2: (PRINC "Visit" #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>)
      Locals:
        SB-IMPL::OBJECT = "Visit"
        STREAM = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
  3: ((FLET #:CONTINUATION543) #<unavailable argument> #<unavailable argument>)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
  4: ((SB-PCL::FAST-METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD (CLIM:OUTPUT-RECORDING-STREAM #1="#<...>" . #1#)) #<unused argument> #<unused argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:CONTINUATION543) {1002917999}> #<unused argument> #<CLOSURE (FLET #:CONSTRUCTOR542) {1002917959}> :PARENT NIL)
      Locals:
        CLIM-INTERNALS::CONSTRUCTOR = #<CLOSURE (FLET #:CONSTRUCTOR542) {1002917959}>
        CLIM-INTERNALS::CONTINUATION = #<CLOSURE (FLET #:CONTINUATION543) {1002917999}>
        #:PARENT-DEFAULTING-TEMP = NIL
        STREAM = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
  5: ((SB-PCL::FAST-METHOD CLIM:STREAM-PRESENT (CLIM:OUTPUT-RECORDING-STREAM #1="#<...>" . #1#)) #<unused argument> #<unused argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> "Visit" STRING :VIEW #<DREI:DREI-TEXTUAL-VIEW {1005D30231}> :MODIFIER NIL :ACCEPTABLY NIL :FOR-CONTEXT-TYPE STRING :SINGLE-BOX NIL :ALLOW-SENSITIVE-INFERIORS T :SENSITIVE T :RECORD-TYPE CLIM:STANDARD-PRESENTATION)
      Locals:
        #:ACCEPTABLY-DEFAULTING-TEMP = NIL
        #:ALLOW-SENSITIVE-INFERIORS-DEFAULTING-TEMP = T
        #:FOR-CONTEXT-TYPE-DEFAULTING-TEMP = STRING
        #:MODIFIER-DEFAULTING-TEMP = NIL
        #:N-SUPPLIED-530 = T
        #:N-SUPPLIED-531 = T
        CLIM-INTERNALS::OBJECT = "Visit"
        #:RECORD-TYPE-DEFAULTING-TEMP = CLIM:STANDARD-PRESENTATION
        #:SENSITIVE-DEFAULTING-TEMP = T
        #:SINGLE-BOX-DEFAULTING-TEMP = NIL
        STREAM = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
        TYPE = STRING
        #:VIEW-DEFAULTING-TEMP = #<DREI:DREI-TEXTUAL-VIEW {1005D30231}>
  6: ((SB-PCL::FAST-METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD (CLIM:OUTPUT-RECORDING-STREAM #1="#<...>" . #1#)) #<unused argument> #<unused argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:CONTINUATION691) {1002917719}> #<unused argument> #<FUNCTION (FLET #:CONSTRUCTOR690) {1008430679}> :PARENT NIL)
      Locals:
        CLIM-INTERNALS::CONSTRUCTOR = #<FUNCTION (FLET #:CONSTRUCTOR690) {1008430679}>
        CLIM-INTERNALS::CONTINUATION = #<CLOSURE (FLET #:CONTINUATION691) {1002917719}>
        #:PARENT-DEFAULTING-TEMP = NIL
        STREAM = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
  7: (CLIM-INTERNALS::%INVOKE-UPDATING #<CLIM:STANDARD-UPDATING-OUTPUT-RECORD X 0:0 Y 2137:2137  (# . 1) {100350BE41}> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION315) {1002917209}>)
      Locals:
        SB-DEBUG::ARG-0 = #<CLIM:STANDARD-UPDATING-OUTPUT-RECORD X 0:0 Y 2137:2137  (#<DREI:DREI-AREA X -1:10 Y 2137:2152 {1005D2FA71}>
                                                                                     . 1) {100350BE41}>
        SB-DEBUG::ARG-1 = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
        SB-DEBUG::ARG-2 = #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION315) {1002917209}>
  8: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::COMPUTE-NEW-OUTPUT-RECORDS-1 (CLIM:STANDARD-UPDATING-OUTPUT-RECORD T T)) #<unavailable argument> #<unavailable argument> #<CLIM:STANDARD-UPDATING-OUTPUT-RECORD X 0:0 Y 2137:2137  (# . 1) {100350BE41}> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION315) {1002917209}>)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = #<CLIM:STANDARD-UPDATING-OUTPUT-RECORD X 0:0 Y 2137:2137  (#<DREI:DREI-AREA X -1:10 Y 2137:2152 {1005D2FA71}>
                                                                                     . 1) {100350BE41}>
        SB-DEBUG::ARG-3 = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
        SB-DEBUG::ARG-4 = #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION315) {1002917209}>
  9: ((SB-PCL::FAST-METHOD CLIM:INVOKE-UPDATING-OUTPUT (CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN #1="#<...>" . #1#)) #<unused argument> #<unused argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION315) {1002917209}> CLIM:STANDARD-UPDATING-OUTPUT-RECORD #<unavailable argument> #<FUNCTION EQUAL> "Visit" #<FUNCTION EQUAL> :FIXED-POSITION NIL :ALL-NEW NIL :PARENT-CACHE NIL)
      Locals:
        #:ALL-NEW-DEFAULTING-TEMP = NIL
        CLIM-INTERNALS::CACHE-TEST = #<FUNCTION EQUAL>
        CLIM-INTERNALS::CACHE-VALUE = "Visit"
        CLIM-INTERNALS::CONTINUATION = #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION315) {1002917209}>
        #:FIXED-POSITION-DEFAULTING-TEMP = NIL
        CLIM-INTERNALS::ID-TEST = #<FUNCTION EQUAL>
        #:PARENT-CACHE-DEFAULTING-TEMP = NIL
        CLIM-INTERNALS::RECORD-TYPE = CLIM:STANDARD-UPDATING-OUTPUT-RECORD
        STREAM = #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>
        CLIM-INTERNALS::UNIQUE-ID = :<NOT-AVAILABLE>
 10: ((FLET DREI-FUNDAMENTAL-SYNTAX::OUTPUT-WORD))
 11: ((SB-PCL::FAST-METHOD DREI-FUNDAMENTAL-SYNTAX::DISPLAY-LINE (CLIM:CLIM-STREAM-PANE DREI:DREI T)) #<unavailable argument> #<unavailable argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<DREI:DREI-AREA X -1:10 Y 2137:2152 {1005D2FA71}> #<DREI-BUFFER:STANDARD-LEFT-STICKY-MARK 0 {1006C436D1}>)
 12: ((SB-PCL::FAST-METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD (CLIM:OUTPUT-RECORDING-STREAM #1="#<...>" . #1#)) #<unused argument> #<unused argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:CONTINUATION691) {1002916939}> #<unused argument> #<FUNCTION (FLET #:CONSTRUCTOR690) {1008430679}> :PARENT NIL)
 13: (CLIM-INTERNALS::%INVOKE-UPDATING #<CLIM:STANDARD-UPDATING-OUTPUT-RECORD X 0:0 Y 2137:2137  (# . 0) {10029B88B1}> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION376) {10029141A9}>)
 14: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::COMPUTE-NEW-OUTPUT-RECORDS-1 (CLIM:STANDARD-UPDATING-OUTPUT-RECORD T T)) #<unavailable argument> #<unavailable argument> #<CLIM:STANDARD-UPDATING-OUTPUT-RECORD X 0:0 Y 2137:2137  (# . 0) {10029B88B1}> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION376) {10029141A9}>)
 15: ((SB-PCL::FAST-METHOD CLIM:INVOKE-UPDATING-OUTPUT (CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN #1="#<...>" . #1#)) #<unused argument> #<unused argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<CLOSURE (FLET #:UPDATING-OUTPUT-CONTINUATION376) {10029141A9}> CLIM:STANDARD-UPDATING-OUTPUT-RECORD #<unavailable argument> #<FUNCTION EQUAL> #<DREI-FUNDAMENTAL-SYNTAX::LINE-OBJECT {1002DB9251}> #<FUNCTION EQUAL> :FIXED-POSITION NIL :ALL-NEW NIL :PARENT-CACHE NIL)
 16: ((SB-PCL::FAST-METHOD DREI:DISPLAY-DREI-CONTENTS (CLIM:CLIM-STREAM-PANE DREI:DREI DREI-FUNDAMENTAL-SYNTAX:FUNDAMENTAL-SYNTAX)) (#(17 16 4) . #()) #<unavailable argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<DREI:DREI-AREA X -1:10 Y 2137:2152 {1005D2FA71}> #<DREI-FUNDAMENTAL-SYNTAX:FUNDAMENTAL-SYNTAX {1006C8EEB1}>)
 17: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) #<unavailable argument> #<unavailable argument> #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<DREI:DREI-AREA X -1:10 Y 2137:2152 {1005D2FA71}> #<DREI-FUNDAMENTAL-SYNTAX:FUNDAMENTAL-SYNTAX {1006C8EEB1}>)
 18: ((SB-PCL::FAST-METHOD DREI:DISPLAY-DREI-CONTENTS :AROUND (CLIM:EXTENDED-OUTPUT-STREAM DREI:DREI DREI-SYNTAX:SYNTAX)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<CLOSURE # {100ADB9D29}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (3)) #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}> #<DREI:DREI-AREA X -1:10 Y 2137:2152 {1005D2FA71}> #<DREI-FUNDAMENTAL-SYNTAX:FUNDAMENTAL-SYNTAX {1006C8EEB1}>)
 19: ((FLET #:CONTINUATION449) #<CLIM:INTERACTOR-PANE CLIM-USER::INTERACTOR {1004A50371}>)
 --more--

-- 
Eric Marsden



From david at lichteblau.com  Fri Dec 29 14:44:23 2006
From: david at lichteblau.com (David Lichteblau)
Date: Fri, 29 Dec 2006 15:44:23 +0100
Subject: [mcclim-devel] Patch: tab layout
Message-ID: <20061229144423.GA9648@babayaga.math.fu-berlin.de>

Hi,

most of you probably know Max-Gerd Retzlaff's Tab Layout or have
followed my progress on IRC while I was working on it.

For reference, here is a "final" version of the tab-layout, adapted for
inclusion into McCLIM.
  http://www.lichteblau.com/blubba/clim-tab-layout/tab-layout-3.diff
(Changelog compared to the original version and updated patches for
Beirc and FTD in the same directory.)

I am still waiting for feedback from MGR regarding the tab-layout's
license, since the original source code tarball does not explicitly
state a license.  Once I hear from MGR regarding the license, I'll
commit this patch.


d.

----------------------------------------------------------------------
Added the tab layout.

	* Extensions/tab-layout.lisp: New file.
	
	* Examples/tabdemo.lisp: New file.
	
	* mcclim.asd (CLIM): Added Extensions/tab-layout.lisp.
	(CLIM-EXAMPLES): Add tabdemo.lisp
	
	* package.lisp (CLIM-TAB-LAYOUT): New package.
	
	* Examples/demodemo.lisp: Added a button for the tabdemo.
	
	* Doc/make-docstrings.lisp: Process the clim-tab-layout package.
	
	* Doc/mcclim.texi: New chapter about the tab-layout.
	
	* Backends/CLX/frame-manager.lisp (GENERATE-STANDARD-PANE-SPECS,
	FIND-CONCRETE-PANE-CLASS): Obey define-abstract-pane-mapping even
	for names not the internal packages.
	
	* Backends/gtkairo/event.lisp (TAB-BUTTON-HANDLER): New.
		
	* Backends/gtkairo/frame-manager.lisp ((MAKE-PANE-2
	TAB-LAYOUT-PANE)): New. (RESOLVE-ABSTRACT-PANE-NAME): Renamed.  
		
	* Backends/gtkairo/gadgets.lisp (TAB-BUTTON-EVENT,
	TAB-PRESS-EVENT, TAB-RELEASE-EVENT, GTK-TAB-LAYOUT): New classes.
	(REALIZE-NATIVE-WIDGET, CONTAINER-PUT, (SETF
	CLIM-TAB-LAYOUT:TAB-LAYOUT-PAGES), REORDER-NOTEBOOK-PAGES,
	CONTAINER-MOVE, ALLOCATE-SPACE, (SETF
	CLIM-TAB-LAYOUT:TAB-LAYOUT-ENABLED-PAGE), CONNECT-NATIVE-SIGNALS,
	CLIM-TAB-LAYOUT:NOTE-TAB-PAGE-CHANGED, SET-TAB-PAGE-ATTRIBUTES,
	HANDLE-EVENT): New functions and methods on gtk-tab-layout.
	(PARENT-AD-HOC-PRESENTATION): New class.
		
	* Backends/gtkairo/port.lisp (GTK-WIDGET-MODIFY-FG): New function.
		
	* Backends/gtkairo/ffi.lisp: Regenerated.


From athas at sigkill.dk  Sun Dec 31 03:23:51 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Sun, 31 Dec 2006 04:23:51 +0100
Subject: [mcclim-devel] BUG: erasing content in the interactor pane
In-Reply-To: <87bqln8tok.fsf@free.fr> (Eric Marsden's message of "Fri, 29
	Dec 2006 00:52:27 +0100")
References: <87bqln8tok.fsf@free.fr>
Message-ID: <87hcvczr20.fsf@sigkill.dk>

Eric Marsden <eric.marsden at free.fr> writes:

> I see the following bug with CVS McCLIM using Closure and
> mcclim-freetype, on SBCL. I recall a previous command with "M-p"
> (for some reason I seem to need to type that twice for it to have an
> effect), then backspace until the entire argument of the command has
> been erased, then run into the following error.

This seems to be a McCLIM Freetype problem that causes some strings to
be printed one pixel to the left of where the stream cursor is
actually positioned. Goatee doesn't suffer from this problem because
it ignores text styles, but in Drei, the input will walk a pixel to
the left for every redisplay. I think this problem is font-dependent,
as I could only get it to show up with a :sans-serif font. This
Listener session sort of shows the problem (notice that the output
records have different positions based on which string is printed - I
guess the variable-width and anti-aliasing stuff causes it):

http://sigkill.dk/athas/vimi.png

-- 
\  Troels "Athas"
/\ Henriksen