From hocwp at free.fr  Mon Sep  4 19:58:38 2006
From: hocwp at free.fr (Philippe Brochard)
Date: Mon, 04 Sep 2006 21:58:38 +0200
Subject: [mcclim-devel] [ANN] cl-wav-synth - express noises as you think
	V2006-09-04
In-Reply-To: <87r6z3wc0n.fsf@grigri.elcforest> (Philippe Brochard's message of
	"Sat, 26 Aug 2006 21:08:24 +0200")
References: <87r6z3wc0n.fsf@grigri.elcforest>
Message-ID: <87u03nl7yp.fsf@grigri.elcforest>


Hi everybody,

I'm glad to announce the last public release of cl-wav-synth.

cl-wav-synth is a wav sample editor. It comes in two parts, the main
library for manipulating wav files and a (Mc)CLIM interface with a
full lisp listener, a sample pane editor, a spectrum pane editor and a
song pane editor.

The wav sample editor is driven from the lisp REPL: you can watch
immediately the result of each applied functions. cl-wav-synth comes
with some effects as echo, delay, pitch...

The spectrum editor is here just for educational purpose. It show the
effect of adding sinus together. But it can load spectrum from the
sharc project and can be used to produce instruments sounds (the sample
amplitude need to be modified to have a real sound).

The song editor is a way to express a song. A song is just a list of
events to write on a wav file. cl-wav-synth traverses the song list
and evaluates the form of each song-sample, if the result is a wav
sample, it is merged in the song wav file.


Since the last release, there have been many enhancements:
  For samples:
  - local, linear and bezier pitch
  - generics filters
  - envelope manipulation with bezier curve (draw and modulate with
    mouse or from the REPL)

Yes I've read again OnLisp from Paul Graham about bezier curves :)

You can find more here:

  http://common-lisp.net/project/cl-wav-synth/


Have fun.

And indeed, any feedbacks, ideas, criticisms are welcome.


Philippe

-- 
Philippe Brochard    <hocwp at free.fr>
                      http://hocwp.free.fr

-=-= http://www.gnu.org/home.fr.html =-=-


From hocwp at free.fr  Mon Sep  4 20:09:55 2006
From: hocwp at free.fr (Philippe Brochard)
Date: Mon, 04 Sep 2006 22:09:55 +0200
Subject: [mcclim-devel] Edit form in the clim listener
Message-ID: <87psebl7fw.fsf@grigri.elcforest>


Hi all,

In cl-wav-synth, I use the code below to edit a form previously
evaluated in the listener.

It works very well for me but is this an acceptable way to do it and
is there something planed to add the editing capability in the
listener ? (I've looked in the source and found something about
history but I doesn't found how to use it).


Best regards,


Philippe

----------------------------------------------------------------------
(define-command (com-eval :menu t :command-table lisp-commands)
    ((form 'clim:form :prompt "Form"))
  (let ((values (multiple-value-list
		 (handler-case (eval form)
		   (error (condition) (format nil "~A" condition))))))
    (fresh-line)
    (shuffle-specials form values)
    (display-evalues values)
    (fresh-line)))

(define-command (com-edit-form :name t :menu t :command-table lisp-commands)
    ((form 'form :prompt "Form"))
  (multiple-value-bind (x1 y1)
      (stream-cursor-position *standard-input*)
    (let ((new-form (accept 'clim:form :stream (frame-standard-input *application-frame*)
			    :prompt "New form" :default form
			    :insert-default t)))
      (multiple-value-bind (x2 y2)
	  (stream-cursor-position *standard-input*)
	(declare (ignore x2))
	(let* ((interactor (find-pane-named *application-frame* 'cl-wav-synth-clim::interactor))
	       (output-history (stream-output-history interactor))
	       (width (bounding-rectangle-width interactor)))
	  (decf y1 (stream-line-height interactor))
	  (map-over-output-records-overlapping-region
   	     #'(lambda (rec) (delete-output-record rec output-history))
	     output-history (make-rectangle* 0 y1 width y2))
	  (draw-rectangle* interactor 0 y1 width y2 :ink (pane-background interactor))
	  (setf (stream-cursor-position *standard-input*) (values x1 y1))
	  (print-listener-prompt interactor *application-frame*)
	  (present new-form 'form)
	  (fresh-line)
	  (force-output)
	  (execute-frame-command *application-frame* `(com-eval ,new-form)))))))

(define-presentation-to-command-translator edit-form
    (clim:command com-edit-form lisp-commands
		  :gesture :describe :echo t
		  :documentation ((object stream)
				  (format stream "Edit ~A" (second object)))
		  :pointer-documentation ((object stream)
					  (format stream "Edit ~A" (second object)))
		  :tester ((object) (eql (car object) 'com-eval)))
    (object)
  (list (second object)))

(define-presentation-to-command-translator edit-form-form
    (clim:form com-edit-form lisp-commands
	       :gesture :describe :echo t
	       :documentation ((object stream)
			       (format stream "Edit ~A" object))
	       :pointer-documentation ((object stream)
				       (format stream "Edit ~A" object)))
    (object)
  (list object))

(define-presentation-to-command-translator eval-form
    (clim:form com-eval lisp-commands
	       :gesture :select :echo t
	       :documentation ((object stream)
			       (format stream "Eval ~A" object))
	       :pointer-documentation ((object stream)
				       (format stream "Eval ~A" object)))
    (object)
  (list object))
----------------------------------------------------------------------


-- 
Philippe Brochard    <hocwp at free.fr>
                      http://hocwp.free.fr

-=-= http://www.gnu.org/home.fr.html =-=-


From dpkatz at gmail.com  Sun Sep 10 12:54:36 2006
From: dpkatz at gmail.com (Daniel Katz)
Date: Sun, 10 Sep 2006 08:54:36 -0400
Subject: [mcclim-devel] Repainting of shrinking windows?
Message-ID: <019BFF81-F25A-474B-A8F0-628FF3E8E522@gmail.com>

Hi,

I've been reading the "Guided Tour" paper included in mcclim/Doc, and
I've found a peculiar behavior for the "Hello World" example on my
system (latest mcclim from CVS, sbcl 0.9.13, Mac OS X 10.4.7 on PPC
running X11.app) and I'm not sure if it's
   - a bug in mcclim, or
   - a bug in X11.app, or
   - a bug in my understanding of how CLIM works, or
   - a feature!
In any event, the issue is as follows.


I run the following code (taken verbatim from the paper) in the
CLIM-USER package at the REPL:
------------------------------------------------------------------------
(define-application-frame hello-world ()
   ((greeting :initform "Hello World"
	     :accessor greeting))
   (:pane (make-pane 'hello-world-pane)))

(defclass hello-world-pane (clim-stream-pane)
   ())

(defmethod handle-repaint ((pane hello-world-pane) region)
   (let ((w (bounding-rectangle-width pane))
	(h (bounding-rectangle-height pane)))
     ;; Blank the pane out
     (draw-rectangle* pane 0 0 w h
		     :filled t
		     :ink (pane-background pane))
     ;; Draw greeting in center of pane
     (draw-text* pane
		(greeting *application-frame*)
		(floor w 2) (floor h 2)
		:align-x :center
		:align-y :center)))

(defun make-and-run-hello-world ()
   (run-frame-top-level
    (make-application-frame 'hello-world)))

(make-and-run-hello-world)
------------------------------------------------------------------------
and I do indeed get a very small window popping up with "Hello World"
in it.  (The window is so tiny, in fact, that it only shows about 5
letters, and that only thanks to the window manager requirement to
make the window large enough to accomodate the usual "expand, hide,
kill" buttons of the Mac OS X window manager.)  I then grab the manual
"resizing" corner of the window and make it bigger, and things are
fine, with the text of "Hello World" dynamically readjusting itself to
stay centered in the window.

The problem comes when I try to use the same mechanism to make the
window smaller.  Whenever dragging the corner of the window is used to
reduce the size of the window, the text does not automatically
recenter but rather stays in the same absolute position on the screen.
(I am attaching a PNG which shows the effect of expanding a window and
then shrinking it again using the "resizer" in the lower right corner
of the window -- the text is clearly no longer centered.)  Any  
attempt to enlarge
the window (in either or both dimensions) will instantly recenter the  
text again.

Clearly, the "shrink window" event is not being acted on for
recentering purposes.  But is this a bug in McClim (i.e., it should be
repainting on shrink but is not), or is it a bug in the Mac OS X
X11.app (i.e., it should be sending some sort of message on shrink  
but is
not) or is it my misunderstanding (i.e., I should be adding some code
to get the repaint to activate on shrink, and I have not done so)?

Thanks for any insight you can provide!

Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CLIM-grab.png
Type: image/png
Size: 8078 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060910/e9254833/attachment.png>
-------------- next part --------------



From clemens at endorphin.org  Sun Sep 10 19:29:49 2006
From: clemens at endorphin.org (Clemens Fruhwirth)
Date: Sun, 10 Sep 2006 21:29:49 +0200
Subject: [mcclim-devel] Repainting of shrinking windows?
In-Reply-To: <019BFF81-F25A-474B-A8F0-628FF3E8E522@gmail.com>
References: <019BFF81-F25A-474B-A8F0-628FF3E8E522@gmail.com>
Message-ID: <87slized02.wl%clemens@endorphin.org>

At Sun, 10 Sep 2006 08:54:36 -0400,
Daniel Katz <dpkatz at gmail.com> wrote:

> Clearly, the "shrink window" event is not being acted on for
> recentering purposes.  But is this a bug in McClim (i.e., it should be
> repainting on shrink but is not), or is it a bug in the Mac OS X
> X11.app (i.e., it should be sending some sort of message on shrink  
> but is
> not) or is it my misunderstanding (i.e., I should be adding some code
> to get the repaint to activate on shrink, and I have not done so)?

I think McCLIM acts alright to not send repaint events as no window
damage is reported. 

To fix this, Hello World should also listen to the
window-configuration-event.

(defmethod handle-event ((pane hello-world-pane) (event window-configuration-event))
  (handle-repaint paint +everwhere+))

..I hope +everywhere+ is the correct constant for the everywhere
region..

So maybe add a mental rule (and/or as footnote to the Hello World
example): whenever the content of a window is dependend on the window
size and we are using handle-repaint, remember to trigger this repaint
also on a window-configuration-event.
-- 
Fruhwirth Clemens - http://clemens.endorphin.org 
for robots: sp4mtrap at endorphin.org


From dpkatz at gmail.com  Mon Sep 11 11:22:26 2006
From: dpkatz at gmail.com (Daniel Katz)
Date: Mon, 11 Sep 2006 07:22:26 -0400
Subject: [mcclim-devel] Repainting of shrinking windows?
In-Reply-To: <87slized02.wl%clemens@endorphin.org>
References: <019BFF81-F25A-474B-A8F0-628FF3E8E522@gmail.com>
	<87slized02.wl%clemens@endorphin.org>
Message-ID: <B50CA284-EACF-43E4-9DDF-6AA95515FAC1@gmail.com>


On Sep 10, 2006, at 15:29, Clemens Fruhwirth wrote:

> At Sun, 10 Sep 2006 08:54:36 -0400,
> Daniel Katz <dpkatz at gmail.com> wrote:
>
>> Clearly, the "shrink window" event is not being acted on for
>> recentering purposes.  But is this a bug in McClim (i.e., it  
>> should be
>> repainting on shrink but is not), or is it a bug in the Mac OS X
>> X11.app (i.e., it should be sending some sort of message on shrink
>> but is not) or is it my misunderstanding (i.e., I should be adding  
>> some code
>> to get the repaint to activate on shrink, and I have not done so)?
>
> I think McCLIM acts alright to not send repaint events as no window
> damage is reported.

Okay -- this makes sense.  The 'handle-repaint' function says what to do
when a repaint is triggered, but doesn't say anything about the
circumstances under which a repaint will happen (e.g., when the text
becomes de-centered due to some window manipulation).  That was the
source of my confusion, I think.





> To fix this, Hello World should also listen to the window- 
> configuration-event.
>
> (defmethod handle-event ((pane hello-world-pane) (event window- 
> configuration-event))
>   (handle-repaint paint +everwhere+))

I assume that the final subform is meant to be (handle-repaint pane  
+everywhere+).


For the record, I tried this and didn't get the behavior of having  
the text
re-center when shrinking the window.  I then tried to test whether I was
getting window-configuration-event's with the following

(defmethod handle-event ((pane hello-world-pane) (event window- 
configuration-event))
   (print (class-of event))
   (terpri)
   (handle-repaint pane +everywhere+))

and found that I was getting no events anywhere.  Finally, I tried to  
examine all
of the relevant window-events with

(defmethod handle-event ((pane hello-world-pane) (event window-event))
   (print (class-of event))
   (terpri)
   (handle-repaint pane +everywhere+))

and found that every time I expanded the window I was getting a
#<STANDARD-CLASS WINDOW-REPAINT-EVENT>, and no event at all
for shrinking the window.  Seems peculiar to me (perhaps something
in the interaction of the window manager and CLIM?), but it's not what I
was really going after when I started this thread so I'm going to  
ignore it for now
and continue with the paper.





Thanks for your help!

Dan



From dpkatz at gmail.com  Tue Sep 12 12:13:27 2006
From: dpkatz at gmail.com (Daniel Katz)
Date: Tue, 12 Sep 2006 08:13:27 -0400
Subject: [mcclim-devel] Does toward-x key in draw-text* work in McCLIM?
Message-ID: <91B9D577-3B1F-4814-8670-0F29C59329D6@gmail.com>

Hi,

I was looking at the CLIM spec and noticed that draw-text* exposes
the possibility of changing the direction of the text drawn (e.g.,
having the text go right-to-left or top-to-bottom), but I don't seem
to be able to get it to work in McCLIM (latest CVS running with CLX
against the Mac OS X X11.app system).  In detail, I tried the
following code (modified slightly from the "hello world" example from
the "Guided Tour" paper:

------------------------------------------------------------------------
(define-application-frame hello-world ()
   ((greeting :initform "Hello World"
	     :accessor greeting))
   (:pane (make-pane 'hello-world-pane)))

(defclass hello-world-pane (clim-stream-pane)
   ())

(defmethod handle-repaint ((pane hello-world-pane) region)
   (let ((w (bounding-rectangle-width pane))
	(h (bounding-rectangle-height pane)))
     ;; Blank the pane out
     (draw-rectangle* pane 0 0 w h
		     :filled t
		     :ink (pane-background pane))
     ;; Draw greeting in center of pane
     (draw-text* pane
		(greeting *application-frame*)
		(floor w 2) (floor h 2)
   		:toward-x 0)))       ; I expect to get "dlroW olleH"

(defun make-and-run-hello-world ()
   (run-frame-top-level
    (make-application-frame 'hello-world :height 300 :width 300)))
------------------------------------------------------------------------

and given the "toward-x" key given in the call to draw-text* (in
handle-repaint), I'd expect to get a window with "dlroW olleH"
printed; instead, I still get "Hello World".  I tried a few other
values for the toward-x key (e.g. (1- (floor w 2)), 1, -1), but saw no
difference.


Grepping through the McCLIM source, I find that "toward-x" is mostly
ignore'd in the various back ends (e.g., Backends/CLX/medium.lisp), so
I am taking that as an indication that this functionality is not yet
implemented.  Is this correct?  Or am I just using the facility
incorrectly?

I'm sorry if this is a FAQ, but I looked at the "known bugs" page at
http://mcclim.cliki.net/Bug, but didn't see anything there about
draw-text* or its features...

Thanks!

Dan



From amoroso at mclink.it  Tue Sep 12 13:16:16 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 12 Sep 2006 15:16:16 +0200
Subject: [mcclim-devel] Does toward-x key in draw-text* work in McCLIM?
In-Reply-To: <91B9D577-3B1F-4814-8670-0F29C59329D6@gmail.com> (Daniel Katz's
	message of "Tue, 12 Sep 2006 08:13:27 -0400")
References: <91B9D577-3B1F-4814-8670-0F29C59329D6@gmail.com>
Message-ID: <87d5a1tecf.fsf@plato.moon.paoloamoroso.it>

Daniel Katz <dpkatz at gmail.com> writes:

> Grepping through the McCLIM source, I find that "toward-x" is mostly
> ignore'd in the various back ends (e.g., Backends/CLX/medium.lisp), so
> I am taking that as an indication that this functionality is not yet
> implemented.  Is this correct?  Or am I just using the facility

You are correct, it is not yet implemented.


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From athas at sigkill.dk  Wed Sep 13 07:35:54 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 13 Sep 2006 09:35:54 +0200
Subject: [mcclim-devel] Creation of a library of presentation type
	definitions
Message-ID: <87vensdxr9.fsf@sigkill.dk>

When hacking on CLIM applications, it often/always becomes necessary
to define new presentation types - some of these are very specialized
to the application, while others are very general concepts (such as
URLs). Having to reimplement these presentation types in every
application is pointless and impairs application integration (not very
much right now, since McCLIM doesn't support input contexts across
multiple frames).

Therefore, I propose the creation of a portable library of
general-purpose presentation type definitions containing definitions
of widely useful presentations such as `url' or `package', and
whatever else is not too specialized to specific applications. I think
this library should be bundled with McCLIM, yet not be dependent on
the of McCLIM as the underlying CLIM implementation, because most
users of free CLIM applications will be using McCLIM already, and
bundling the library with McCLIM will free them from having to hunt
down new dependencies.

What do you think?

-- 
\  Troels "Athas"
/\ Henriksen


From strandh at labri.fr  Thu Sep 14 07:50:27 2006
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 14 Sep 2006 09:50:27 +0200
Subject: [mcclim-devel] Creation of a library of presentation type definitions
In-Reply-To: <87vensdxr9.fsf@sigkill.dk>
References: <87vensdxr9.fsf@sigkill.dk>
Message-ID: <17673.2499.339325.560470@serveur5.labri.fr>

Troels Henriksen writes:
 > 
 > Therefore, I propose the creation of a portable library of
 > general-purpose presentation type definitions containing definitions
 > of widely useful presentations such as `url' or `package', and
 > whatever else is not too specialized to specific applications.
 >
 > What do you think?

I think that's an excellent idea. 
-- 
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 johnc at yagc.ndo.co.uk  Thu Sep 14 21:47:16 2006
From: johnc at yagc.ndo.co.uk (John Connors)
Date: Thu, 14 Sep 2006 22:47:16 +0100
Subject: [mcclim-devel] Debugging tips
Message-ID: <4509CDE4.3060406@yagc.ndo.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


How do I maximise the debuggability of mcclim? I'm going back to my
mcclim texture generator app, this time using the gtk backend, hoping to
 stress it a bit. I'm using sbcl-0.9.16. & SLIME

Does anyone have any debugging tips? Is there a strategic point in the
code where I can proclaim (debug 3) and get the whole of mcclim compiled
with debug info...?

- --
+--------------------------------------------------------+
|Cyborg Animation Programmer    |    johnc at yagc.ndo.co.uk|
|http://badbyteblues.blogspot.com -----------------------|
+--------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFCc3ktiwrK5pscc0RAg07AJ4t+OIm3YAY0GzwOfRsZulTsOK71ACgxLEu
btFeA7H6tCwSh5b+1H3kbNc=
=+ZQj
-----END PGP SIGNATURE-----


From nikodemus at random-state.net  Fri Sep 15 07:15:18 2006
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Fri, 15 Sep 2006 10:15:18 +0300
Subject: [mcclim-devel] Re: Debugging tips
References: <4509CDE4.3060406@yagc.ndo.co.uk>
Message-ID: <87lkoltxbt.fsf@logxor.random-state.net>

John Connors <johnc at yagc.ndo.co.uk> writes:

> How do I maximise the debuggability of mcclim? I'm going back to my
> mcclim texture generator app, this time using the gtk backend, hoping to
>  stress it a bit. I'm using sbcl-0.9.16. & SLIME
>
> Does anyone have any debugging tips? Is there a strategic point in the
> code where I can proclaim (debug 3) and get the whole of mcclim compiled
> with debug info...?

This is general SBCL information, not McCLIM information, but so it goes:

(declaim (optimize (debug 3) (compilation-speed 3))) in your
.sbclrc or in the repl. DO NOT LEAVE OUT THE COMPILATION-SPEED for
now: otherwise SBCL will create more debug inforation than you really
wan't for something the size of McCLIM -- this will hopefully change
sooon, but for the moment that's the way it goes.

If you do the declaim in a file, it will affect that file after the
point of declamation, but nothing else.

Cheers,

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



From jm at mak.com  Fri Sep 29 22:09:36 2006
From: jm at mak.com (John Morrison)
Date: Fri, 29 Sep 2006 18:09:36 -0400
Subject: [mcclim-devel] stupid newbie question re: initializing text-field
Message-ID: <200609291809.37498.jm@mak.com>

Sorry for what might be either a Stupid Newbie Question or Pilot
Error:

I am trying to implement a frame that allows "form-like" pop-editing
of a CL data structure which include strings.  How can I initialize
the text fields and text editors?

If I do what seems like the recommended thing according to the
Harlequin CLIM manual -- a :before method on run-frame-top-level, it
seems like maybe some goatee buffer pointer is not initialized until
after the primary run-frame-top-level method gets called.

(I made my own :around run-frame-top-level method, and the setf
gadget-value, in fact, succeeds after the (call-next-method) has run
-- but of course that's a little late for me.)

The attached lisp program seems to exhibit the symptoms: the "test1"
command works as expected and sets the value, but the :before method
does not seem to. 

I only tried this under Linux (CentOS 4.4) on a relatively recent SBCL
(0.9.14 RPM), using a relatively recent McCLIM (CVS updated approx
Sept 15th).  If anybody would please suggest further experiments, I
would carry them out post-haste.

Sorry if this is a stupid mechanical question: also, is there a
stylistically better way to do this?

Thanks,

-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




-------------- next part --------------
(in-package "CLIM-USER")

(define-application-frame test-frame ()
  ((initial-string :initform nil))
  (:panes
   (tester (make-pane 'text-field)))
  (:layouts
   (default (vertically () tester))))

#|
(defmethod run-frame-top-level :before ((instance test-frame) &key)
  (setf (gadget-value (find-pane-named frame 'tester))
	"this doesn't"))
|#


(define-test-frame-command (com-test1
			     :menu "Test 1"
			     :name "Test 1")
    ()
    (setf (gadget-value (find-pane-named *application-frame* 'tester))
	  "this works"))

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

From rpgoldman at real-time.com  Fri Sep 29 22:32:38 2006
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Fri, 29 Sep 2006 17:32:38 -0500
Subject: [mcclim-devel] stupid newbie question re: initializing text-field
In-Reply-To: <200609291809.37498.jm@mak.com>
References: <200609291809.37498.jm@mak.com>
Message-ID: <17693.40710.844081.604956@necronomicon.sift.info>

>>>>> "John" == John Morrison <jm at mak.com> writes:

    John> Sorry for what might be either a Stupid Newbie Question or
    John> Pilot Error:

    John> I am trying to implement a frame that allows "form-like"
    John> pop-editing of a CL data structure which include strings.
    John> How can I initialize the text fields and text editors?

    John> If I do what seems like the recommended thing according to
    John> the Harlequin CLIM manual -- a :before method on
    John> run-frame-top-level, it seems like maybe some goatee buffer
    John> pointer is not initialized until after the primary
    John> run-frame-top-level method gets called.

    John> (I made my own :around run-frame-top-level method, and the
    John> setf gadget-value, in fact, succeeds after the
    John> (call-next-method) has run
    John> -- but of course that's a little late for me.)

    John> The attached lisp program seems to exhibit the symptoms: the
    John> "test1" command works as expected and sets the value, but
    John> the :before method does not seem to.

    John> I only tried this under Linux (CentOS 4.4) on a relatively
    John> recent SBCL (0.9.14 RPM), using a relatively recent McCLIM
    John> (CVS updated approx Sept 15th).  If anybody would please
    John> suggest further experiments, I would carry them out
    John> post-haste.

    John> Sorry if this is a stupid mechanical question: also, is
    John> there a stylistically better way to do this?

Argh.  I wish I could answer you precisely.  I remember only vaguely
reading something in the CLIM spec that said "this is the method to
specialize if you want to set up your frame (or something like that)."

IIRC, it's ADOPT-FRAME to which you want to add this behavior.

Good luck!

r


From pw at snoopy.mv.com  Fri Sep 29 22:38:41 2006
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Fri, 29 Sep 2006 18:38:41 -0400
Subject: [mcclim-devel] stupid newbie question re: initializing text-field
References: <200609291809.37498.jm@mak.com>
Message-ID: <002001c6e418$0380f990$0201a8c0@moby>

| I only tried this under Linux (CentOS 4.4) on a relatively recent SBCL
| (0.9.14 RPM), using a relatively recent McCLIM (CVS updated approx
| Sept 15th).  If anybody would please suggest further experiments, I
| would carry them out post-haste.


Assuming you really meant this (whre INSTANCE is used instead of FRAME
in (find-pane-named ...)

(defmethod run-frame-top-level :before ((instance test-frame) &key)
  (setf (gadget-value (find-pane-named instance 'tester))
 "this doesn't"))

This does what you expected in Lispworks CLIM. I've used this sort of
initialization
many times.

Paul




From jm at mak.com  Fri Sep 29 23:07:45 2006
From: jm at mak.com (John Morrison)
Date: Fri, 29 Sep 2006 19:07:45 -0400
Subject: [mcclim-devel] stupid newbie question re: initializing text-field
In-Reply-To: <002001c6e418$0380f990$0201a8c0@moby>
References: <200609291809.37498.jm@mak.com>
	<002001c6e418$0380f990$0201a8c0@moby>
Message-ID: <200609291907.46134.jm@mak.com>

On Friday 29 September 2006 18:38, Paul Werkowski wrote:
> Assuming you really meant this (whre INSTANCE is used instead of FRAME
> in (find-pane-named ...)
>
> (defmethod run-frame-top-level :before ((instance test-frame) &key)
>   (setf (gadget-value (find-pane-named instance 'tester))
>  "this doesn't"))

Doh!

Even so, when fixing it as you kindly indicated, it still bombs --
please see attached updated foo.lisp and a log file containing a
backtrace...

-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


-------------- next part --------------
(in-package "CLIM-USER")

(define-application-frame test-frame ()
  ((initial-string :initform nil))
  (:panes
   (tester (make-pane 'text-field)))
  (:layouts
   (default (vertically () tester))))

#||#
(defmethod run-frame-top-level :before ((instance test-frame) &key)
  (setf (gadget-value (find-pane-named instance 'tester))
	"this doesn't"))
#||#


(define-test-frame-command (com-test1
			     :menu "Test 1"
			     :name "Test 1")
    ()
    (setf (gadget-value (find-pane-named *application-frame* 'tester))
	  "this works"))

(run-frame-top-level (make-application-frame 'test-frame))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.log
Type: text/x-log
Size: 3751 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060929/745762ec/attachment.bin>

From athas at sigkill.dk  Fri Sep 29 23:38:29 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 30 Sep 2006 01:38:29 +0200
Subject: [mcclim-devel] stupid newbie question re: initializing text-field
In-Reply-To: <200609291907.46134.jm@mak.com> (John Morrison's message of
	"Fri, 29 Sep 2006 19:07:45 -0400")
References: <200609291809.37498.jm@mak.com>
	<002001c6e418$0380f990$0201a8c0@moby> <200609291907.46134.jm@mak.com>
Message-ID: <87zmci2qh6.fsf@sigkill.dk>

> Even so, when fixing it as you kindly indicated, it still bombs --

The Goatee editable area object, which contains the buffer, is not
initialized until the first redisplay happens, so it is impossible to
access the buffer before then. Hence, you cannot use (setf
gadget-value) on a text-field or text-editor gadget in McCLIM before
your command loop is running and the gadget has been redisplayed at
least once. I'm pretty sure this is a bug in McCLIM (if anyone wants
to fix it, look at the definition of `handle-repaint' for
`text-field-pane' in gadget.lisp line 2542).

-- 
\  Troels "Athas"
/\ Henriksen