From a_bakic at yahoo.com  Fri Apr  1 20:29:18 2005
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Fri, 1 Apr 2005 12:29:18 -0800 (PST)
Subject: [mcclim-devel] A question re. (setf bounding-rectangle-m...) methods
Message-ID: <20050401202918.87108.qmail@web40601.mail.yahoo.com>

Hi,

I am trying to get Scigraph to work with CMUCL. So far I found what I believe
is a CMUCL 0305 bug: the third/last multiple-value-setq in function
device-draw-line in scigraph/draw.lisp exercises incorrect compilation of the
function. I replaced it with an equivalent multiple-value-bind and that fixed
the problem. (Both versions of the function worked when interpreted.) Perhaps
someone wants to take a look; I'll post to cmucl-devel if I do not get any
feedback.

Then I encountered a similar problem with (setf bounding-rectangle-min-x) and
friends in the same file. The error below is confusing (it occurs when I play
with zoom in/zoom out), but I noticed that the compiler complains about missing
setf methods when I recompiled the file. Then I looked at regions.lisp and the
spec, and I could not find the setf methods implemented or documented. Again,
the error is not raised by CMUCL 0305 when I the code in scigraph/draw.lisp is
interpreted.

Any suggestions are welcome.

Alex

Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:  10 is not of type (MOD
10)
   [Condition of type TYPE-ERROR]

Restarts:
  0: [ABORT] Return to application command loop
  1: [SCIGRAPH-TOP-LEVEL] Abort to SCIGRAPH Top Level
  2: [DESTROY] Destroy the process

Backtrace:
  0: (%CLIP-LINE 1083 161 928 341 ...)
  1: (DEVICE-DRAW-LINE #<APPLICATION-PANE DISPLAY {5A38C2D5}> 1083 161 928 ...)
  2: ("DEFMETHOD DATUM-STYLE-DISPLAYER (GRAPH-DATUM-LINE-SYMBOLOGY-MIXIN T (EQL
LINE-SYMBOL))" #<APPLICATION-PANE DISPLAY {5A38C2D5}> 928 341 (1572 5177/5000))
  3: ((METHOD INVOKE-WITH-NEW-OUTPUT-RECORD NIL (OUTPUT-RECORDING-STREAM T T
T)) (#() . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure
Over Function (FLET #:CONTINUATION37) {589F3B59}> ...)
  4: ("DEFMETHOD DATUM-DISPLAYER AROUND (PRESENTABLE-DATA-MIXIN T)"
#<APPLICATION-PANE DISPLAY {5A38C2D5}> 928 341 (1572 5177/5000))
  5: (MAP NIL #<Closure Over Function "DEFMETHOD DISPLAY-DATA
(ESSENTIAL-GRAPH-DATA-MAP-MIXIN T T)" {5882E631}> ((2096 261/200) (2095
1317/1000) (2094 13259/10000) (2093 13277/10000) (2092 13463/10000) ...))
  6: ((METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL NIL (MEDIUM T
T)) (#(2 5 6 3 2 ...) . #(# #)) #<unused-arg> #1=#<CLIM-CLX::CLX-MEDIUM
{5A4A7D45}> #1# ...)
  7: ((METHOD GRAPH-DISPLAY-DATA NIL (GRAPH-DATASETS-MIXIN T)) (#(32 33) . #())
#<unused-arg> #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY
{5A38C2D5}>)
  8: ((METHOD GRAPH-WITH-CLIPPING NIL (BASIC-GRAPH T T T)) #<#1=unused-arg>
#<#1#> #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY
{5A38C2D5}> ...)
  9: ("LAMBDA (G9552 G9553 G9554)" #<#1=unused-arg> #<#1#> #<ANNOTATED-GRAPH
ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY {5A38C2D5}>)
 10: ((METHOD INVOKE-WITH-NEW-OUTPUT-RECORD NIL (OUTPUT-RECORDING-STREAM T T
T)) (#() . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure
Over Function (FLET #:CONTINUATION97 (FLET #:UPDATING-OUTPUT-CONTINUATION6))
{5881ED81}> ...)
 11: ((FLET #:UPDATING-OUTPUT-CONTINUATION6) #<APPLICATION-PANE DISPLAY
{5A38C2D5}>)
 12: ((METHOD INVOKE-WITH-NEW-OUTPUT-RECORD NIL (OUTPUT-RECORDING-STREAM T T
T)) (#() . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure
Over Function (FLET #:CONTINUATION14 CLIM-INTERNALS::%INVOKE-UPDATING)
{5881E919}> ...)
 13: (CLIM-INTERNALS::%INVOKE-UPDATING #<STANDARD-UPDATING-OUTPUT-RECORD X
0.0d0:0.0d0 Y 0.0d0:0.0d0  #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> {5881E36D}>
#<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure Over Function (FLET
#:UPDATING-OUTPUT-CONTINUATION6) {5881D961}>)
 14: ((FLET #:CONTINUATION44) #<APPLICATION-PANE DISPLAY {5A38C2D5}>
#<STANDARD-UPDATING-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 
#<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> {5881E36D}>)
 15: ((METHOD INVOKE-WITH-NEW-OUTPUT-RECORD NIL (OUTPUT-RECORDING-STREAM T T
T)) (#() . #(#)) #<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure
Over Function (FLET #:CONTINUATION44) {5881D989}> ...)
 16: ((METHOD INVOKE-UPDATING-OUTPUT NIL
(CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN T T T T ...)) (#(46) . #(#))
#<unused-arg> #<APPLICATION-PANE DISPLAY {5A38C2D5}> #<Closure Over Function
(FLET #:UPDATING-OUTPUT-CONTINUATION6) {5881D961}> ...)
 17: ((METHOD DISPLAY (:AROUND) (PRESENTABLE-GRAPH-MIXIN T)) (#(50 49) . #())
#S(PCL::FAST-METHOD-CALL :FUNCTION #<Closure Over Function "LAMBDA (G9552 G9553
G9554)" {5A002AF9}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2))
#<ANNOTATED-GRAPH ANNOTATED-GRAPH-3> #<APPLICATION-PANE DISPLAY {5A38C2D5}>)
 18: ((METHOD EXECUTE-FRAME-COMMAND (:AROUND) (T T)) #<unused-arg>
#S(PCL::FAST-METHOD-CALL :FUNCTION #<Function (METHOD EXECUTE-FRAME-COMMAND NIL
#) {58C7E8C1}> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) #<GRAPH-VIEWER
{58618B55}> (COM-ZOOM-IN #<ANNOTATED-GRAPH ANNOTATED-GRAPH-3>
#<APPLICATION-PANE DISPLAY {5A38C2D5}>))
 19: ((METHOD DEFAULT-FRAME-TOP-LEVEL NIL (APPLICATION-FRAME)) (#() . #(# # # #
# ...)) #<unused-arg> #<GRAPH-VIEWER {58618B55}> NIL)



		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs


From rpgoldman at sift.info  Fri Apr  1 22:40:41 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Fri, 1 Apr 2005 16:40:41 -0600
Subject: [mcclim-devel] problem with format-graph-from-roots, ACL 6.2
Message-ID: <16973.52713.411.810069@gargle.gargle.HOWL>


I took some code invoking format-graph-from-roots from before the
mothering release and was trying to run it, and got a crash.

I traced fairly far down the stack and found something anomalous that
I was hoping someone could help me with.  

In the course of drawing one of my graph-nodes, I get to this point in
the stack:


[1c] GRAPH-MDP(108): :fr
((METHOD INVOKE-WITH-DRAWING-OPTIONS (SHEET T))
 #<APPLICATION-PANE APP @ #x72139792>
 #<Closure (FLET DRAW-TAEMS-NODE #:G7069) @ #xbfff547a> :INK
 #.+FOREGROUND-INK+ :TEXT-STYLE
 #<STANDARD-TEXT-STYLE :FIX :ROMAN :NORMAL>)

Now what's odd in that is that I seem to be using the method for the
case where the first parameter is of unrestricted type (T).  But there
is ANOTHER (better?) definition for the case where the first argument
is a SHEET.

As far as I can tell, the second argument IS a sheet:

[1c] GRAPH-MDP(111): (setf foo (second *))
#<APPLICATION-PANE APP @ #x72139792>
[1c] GRAPH-MDP(112): (clim::sheetp foo)
T
[1c] GRAPH-MDP(113): (typep foo 'clim::sheet)
T

I think the upshot of this is that the extra arguments (the drawing
options) are tossed away, instead of being passed on to the closure.

At the end of the day, this means that we try to call
invoke-with-sheet-medium-bound with the arguments:

CLOSURE NIL CLIM-CLX::CLX-MEDIUM

whereas that generic function seems to expect

CLOSURE MEDIUM-OR-NIL SHEET

Thanks,
R


From rpgoldman at sift.info  Fri Apr  1 23:48:16 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Fri, 1 Apr 2005 17:48:16 -0600
Subject: [mcclim-devel] A tough day for me and McCLIM
Message-ID: <16973.56768.895294.404988@gargle.gargle.HOWL>


I was just testing out the inspector, and was able to reliably cause
it to blow up.

CL-USER(168): (clouseau:inspector *taems-model* :new-process t)
#<MULTIPROCESSING:PROCESS
  Inspector Clouseau: #<TAEMS-MODEL @ #x72023142> @ #x72f7cd42>

...crashes with the followign error:

Error: Attempt to access the plist field of
       #<TAEMS-MODEL @ #x72023142> which is not a symbol.
  [condition type: SIMPLE-ERROR]

Restart actions (select using :continue):
 0: Return to application command loop
 1: Abort entirely from this process.
[Current process: Inspector Clouseau: *TAEMS-MODEL*]
[1] CL-USER(1): 

CL-USER(169): (clouseau:inspector '*taems-model* :new-process t)
#<MULTIPROCESSING:PROCESS Inspector Clouseau: *TAEMS-MODEL* @
  #x728a4da2>

This works ok (presumably because it's a symbol it has a property
list?), but when I click on the value cell of the *taems-model*
variable, Clouseau blows up with the same error.

The proximate cause seems to be PRINT-DOCUMENTATION, which pulls the
documentation and then tries to print it, as can be seen in this
error:

CL-USER(171): (documentation *taems-model* t)
Error: Attempt to access the plist field of
       #<TAEMS-MODEL @ #x72023142> which is not a symbol.
  [condition type: SIMPLE-ERROR]

Restart actions (select using :continue):
 0: Return to Top Level (an "abort" restart).
 1: Abort entirely from this process.

Does this mean that ACL is not doing the Right Thing with the
documentation function?  Or is CLOUSEAU wrong to assume that
everything will have documentation? Seems like documentation might not
be defined on objects, if I read the CLHS correctly.

The following change to PRINT-DOCUMENTATION seems to fix my problem.
Not sure how right it is, though.    

(defun print-documentation (object pane)
  "Print OBJECT's documentation, if any, to PANE"
  (when (catch 'no-docs 
	  (handler-bind ((warning #'muffle-warning)
			 (error #'(lambda (c) (declare (ignore c)) (throw 'no-docs nil))))
	    (documentation object t)))
    (with-heading-style (pane)
      (format pane "~&Documentation: "))
    (princ (documentation object t) pane)))



From a_bakic at yahoo.com  Sat Apr  2 09:35:04 2005
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Sat, 2 Apr 2005 01:35:04 -0800 (PST)
Subject: [mcclim-devel] A question re. (setf bounding-rectangle-m...)
	methods
In-Reply-To: <20050401202918.87108.qmail@web40601.mail.yahoo.com>
Message-ID: <20050402093504.64582.qmail@web40613.mail.yahoo.com>

FWIW,

> Then I encountered a similar problem with (setf bounding-rectangle-min-x) and

I replaced calls of the form (setf (bounding-rectangle-min-x .x.) le) with ones
of the form
(setf (aref coords 0) le) where coords is bound to (slot-value .x.
'coordinates). This works with McCLIM only (while it should for :clim-2).

> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:  10 is not of type (MOD
10)

I found a declaration (declare (type (integer 0 9) c1 c2)) in %clip-line; it
should be (declare (type (integer 0 10) c1 c2)) because the possible values of
c1 and c2 are 0, 2, 8 and 10.

BTW, in dwin/package.lisp, I had to replace (:use clim-lisp) with (:use
:clim-lisp).

Alex


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Personals - Better first dates. More second dates. 
http://personals.yahoo.com



From sketerpot at gmail.com  Sat Apr  2 17:22:18 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Sat, 2 Apr 2005 10:22:18 -0700
Subject: [mcclim-devel] A tough day for me and McCLIM
In-Reply-To: <16973.56768.895294.404988@gargle.gargle.HOWL>
References: <16973.56768.895294.404988@gargle.gargle.HOWL>
Message-ID: <7e267a920504020922403bb4c9@mail.gmail.com>

On Apr 1, 2005 4:48 PM, rpgoldman at sift.info <rpgoldman at sift.info> wrote:
> The proximate cause seems to be PRINT-DOCUMENTATION, which pulls the
> documentation and then tries to print it, as can be seen in this
> error:
> 
> CL-USER(171): (documentation *taems-model* t)
> Error: Attempt to access the plist field of
>        #<TAEMS-MODEL @ #x72023142> which is not a symbol.
>   [condition type: SIMPLE-ERROR]
> 
> Restart actions (select using :continue):
>  0: Return to Top Level (an "abort" restart).
>  1: Abort entirely from this process.
> 
> Does this mean that ACL is not doing the Right Thing with the
> documentation function?  Or is CLOUSEAU wrong to assume that
> everything will have documentation? Seems like documentation might not
> be defined on objects, if I read the CLHS correctly.

I'd say that ACL does indeed have a problem with documentation.
According to CLHS, "The generic function documentation returns the
documentation string associated with the given object if it is
available; otherwise it returns nil." On SBCL you also get a warning
saying that the type of documentation you asked for is not supported.
But throwing an exception seems wrong; CLHS says that DOCUMENTATION
has no exceptional situations.

And, judging by the cryptic nature of the error, I'm almost certain
that it's an ACL bug.

> The following change to PRINT-DOCUMENTATION seems to fix my problem.
> Not sure how right it is, though.
> 
> (defun print-documentation (object pane)
>   "Print OBJECT's documentation, if any, to PANE"
>   (when (catch 'no-docs
>           (handler-bind ((warning #'muffle-warning)
>                          (error #'(lambda (c) (declare (ignore c)) (throw 'no-docs nil))))
>             (documentation object t)))
>     (with-heading-style (pane)
>       (format pane "~&Documentation: "))
>     (princ (documentation object t) pane)))

That catch-throw trickery looks a little ugly, but the change
shouldn't hurt anything on any other implementations, so I'll commit
it. Thanks.

-Peter


From sketerpot at gmail.com  Sat Apr  2 18:05:37 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Sat, 2 Apr 2005 11:05:37 -0700
Subject: [mcclim-devel] A tough day for me and McCLIM
In-Reply-To: <7e267a920504020922403bb4c9@mail.gmail.com>
References: <16973.56768.895294.404988@gargle.gargle.HOWL>
	<7e267a920504020922403bb4c9@mail.gmail.com>
Message-ID: <7e267a9205040210055ffdd5b5@mail.gmail.com>

On Apr 2, 2005 10:22 AM, Peter Scott <sketerpot at gmail.com> wrote:
> That catch-throw trickery looks a little ugly, but the change
> shouldn't hurt anything on any other implementations, so I'll commit
> it. Thanks.

Scratch that; the catch-throw thing broke things over here, so I
ripped it out and replaced it with a HANLER-CASE which I'm much
happier about. And that uncovered some other bugs (thanks again) which
I think I've got fixed. Tell me if you have any problems with the
current CVS version of the inspector.

-Peter


From csr21 at cam.ac.uk  Sat Apr  2 22:16:57 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sat, 02 Apr 2005 23:16:57 +0100
Subject: [mcclim-devel] Better defaults for CLX backend
In-Reply-To: <sqk6nnho7j.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Thu, 31 Mar 2005 15:41:52 +0100")
References: <sqk6nnho7j.fsf@cam.ac.uk>
Message-ID: <sqhdiog6xy.fsf@cam.ac.uk>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> That said, I have completely failed to test this patch even to the
> point of compiling it, as locally both my sbcl and my clx are broken.
> If someone could test this and report back (or commit it themselves),
> that would be good.

Uh, forget that patch.

Instead, please test what I have just committed to CVS; I think it
should be no worse than what was there before in any case, and it
makes mcclim-over-ssh work for me -- that is, I think this fixes the
mccliki bug clim-over-ssh-x-fails.

Cheers,

Christophe


From boris at math.ubc.ca  Sun Apr  3 05:24:05 2005
From: boris at math.ubc.ca (Boris Tschirschwitz)
Date: Sat, 02 Apr 2005 21:24:05 -0800
Subject: [mcclim-devel] sb-bsd-sockets
In-Reply-To: <3afebc0e4aa245b5035a071f0d10c929@mastenbrook.net>
References: <424B07A8.3060500@math.ubc.ca>
	<3afebc0e4aa245b5035a071f0d10c929@mastenbrook.net>
Message-ID: <424F7DF5.2020006@math.ubc.ca>

Hi.

Thanks for all the help.

It turns out that Brian's suggestion to modify mcclim.asd takes care of 
getting rid of clx.

Boris.

PS: Of course, climacs still depends on clx

Brian Mastenbrook wrote:

>
> On Mar 30, 2005, at 2:10 PM, Boris Tschirschwitz wrote:
>
>> Hi.
>>
>> I am trying to use McCLIM with openmcl.
>> When compiling the beagle backend I get the error message that 
>> sb-bsd-sockets can't be found, apparently clx depends on it and 
>> mcclim depends on clx, even with beagle.
>> Making sb-bsd-sockets from sbcl-contrib known to asdf helps until 
>> sb-bsd-sockets wants sb-grovel and eventually sb-ext. This one I 
>> can't find on sbcl.
>>
>> Am I really supposed to use all these SBCL packages?
>> If so, where do I get the sb-ext?
>>
>> Thanks,
>> Boris.
>>
>
> Hi Boris,
>
> You should edit the file mcclim.asd in the root of the McCLIM source 
> tree to use the beagle backend instead of the CLX backend. By default 
> only the CLX backend is enabled because the beagle backend is still a 
> bit buggy. Search for clim-looks in the file and comment out the line 
> that sets up the clx backend as a dependancy, and uncomment the one 
> which sets up the beagle backend.
> -- 
> Brian Mastenbrook
> brian at mastenbrook.net
> http://www.iscblog.info/
>
>
>


From csr21 at cam.ac.uk  Sun Apr  3 06:28:49 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sun, 03 Apr 2005 07:28:49 +0100
Subject: [mcclim-devel] sb-bsd-sockets
In-Reply-To: <424F7DF5.2020006@math.ubc.ca> (Boris Tschirschwitz's message
	of "Sat, 02 Apr 2005 21:24:05 -0800")
References: <424B07A8.3060500@math.ubc.ca>
	<3afebc0e4aa245b5035a071f0d10c929@mastenbrook.net>
	<424F7DF5.2020006@math.ubc.ca>
Message-ID: <sqd5tcfk66.fsf@cam.ac.uk>

Boris Tschirschwitz <boris at math.ubc.ca> writes:

> PS: Of course, climacs still depends on clx

It does?  Why?

Cheers,

Christophe


From amoroso at mclink.it  Sun Apr  3 14:27:00 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sun, 03 Apr 2005 16:27:00 +0200
Subject: [mcclim-devel] How to open a frame opened with OPEN-WINDOW-STREAM
Message-ID: <873bu8vsuj.fsf@plato.moon.paoloamoroso.it>

I would like to simulate a modal dialog, contained in its own window,
via an ACCEPTING-VALUES inside a frame opened with
OPEN-WINDOW-STREAM.  I use code like this:

(in-package :clim-user)

(define-application-frame window-stream ()
  ()
  (:menu-bar t)
  (:panes
   (commands :interactor))
  (:layouts
   (default commands)))

(defun show-dialog (stream)
  (let (integer string)
    (restart-case
        (accepting-values (stream)
          (setq integer (accept 'integer :stream stream
                                :prompt "Gimme an integer "))
          (terpri stream)
          (setq string (accept 'string :stream stream
                               :prompt "Gimme a string "))
          (terpri stream))
      (abort () nil))
    (values integer string)))

(define-window-stream-command (com-dialog :menu t :name t)
    ()
  (let ((stream (open-window-stream)))
    (unwind-protect (multiple-value-bind (integer string) (show-dialog stream)
                      (format t "~&You entered ~D and ~A~%" integer string))
      (when (open-stream-p stream)
        (frame-exit (pane-frame stream))
        (close stream)))))

(define-window-stream-command (com-quit :menu t :name t)
    ()
  (frame-exit *application-frame*))

This mostly works, but the CLIM frame opened with OPEN-WINDOW-STREAM
is not closed.  I tried using only CLOSE in COM-DIALOG, but without
success.  How can I close that window?


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


From rpgoldman at sift.info  Sun Apr  3 14:58:58 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Sun, 3 Apr 2005 09:58:58 -0500
Subject: [mcclim-devel] A tough day for me and McCLIM
In-Reply-To: <7e267a920504020922403bb4c9@mail.gmail.com>
References: <16973.56768.895294.404988@gargle.gargle.HOWL>
	<7e267a920504020922403bb4c9@mail.gmail.com>
Message-ID: <16976.1202.636283.485087@gargle.gargle.HOWL>

>>>>> "PS" == Peter Scott <sketerpot at gmail.com> writes:

    PS> On Apr 1, 2005 4:48 PM, rpgoldman at sift.info <rpgoldman at sift.info> wrote:
    >> The proximate cause seems to be PRINT-DOCUMENTATION, which pulls the
    >> documentation and then tries to print it, as can be seen in this
    >> error:
    >> 
    >> CL-USER(171): (documentation *taems-model* t)
    >> Error: Attempt to access the plist field of
    >> #<TAEMS-MODEL @ #x72023142> which is not a symbol.
    >> [condition type: SIMPLE-ERROR]
    >> 
    >> Restart actions (select using :continue):
    >> 0: Return to Top Level (an "abort" restart).
    >> 1: Abort entirely from this process.
    >> 
    >> Does this mean that ACL is not doing the Right Thing with the
    >> documentation function?  Or is CLOUSEAU wrong to assume that
    >> everything will have documentation? Seems like documentation might not
    >> be defined on objects, if I read the CLHS correctly.

    PS> I'd say that ACL does indeed have a problem with documentation.
    PS> According to CLHS, "The generic function documentation returns the
    PS> documentation string associated with the given object if it is
    PS> available; otherwise it returns nil." On SBCL you also get a warning
    PS> saying that the type of documentation you asked for is not supported.
    PS> But throwing an exception seems wrong; CLHS says that DOCUMENTATION
    PS> has no exceptional situations.

    PS> And, judging by the cryptic nature of the error, I'm almost certain
    PS> that it's an ACL bug.

Note that I haven't tested this on ACL 7.0; this is ACL 6.2.

R
-- 
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
SIFT offices:  (612) 339-7438
Email:    rpgoldman at SIFT.info


From amoroso at mclink.it  Sun Apr  3 19:38:29 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sun, 03 Apr 2005 21:38:29 +0200
Subject: [mcclim-devel] How to open a frame opened with OPEN-WINDOW-STREAM
In-Reply-To: <873bu8vsuj.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's
	message of "Sun, 03 Apr 2005 16:27:00 +0200")
References: <873bu8vsuj.fsf@plato.moon.paoloamoroso.it>
Message-ID: <87hdinirbe.fsf@plato.moon.paoloamoroso.it>

Paolo Amoroso <amoroso at mclink.it> writes:

> I would like to simulate a modal dialog, contained in its own window,
> via an ACCEPTING-VALUES inside a frame opened with
> OPEN-WINDOW-STREAM.  I use code like this:
[...]
> This mostly works, but the CLIM frame opened with OPEN-WINDOW-STREAM
> is not closed.  I tried using only CLOSE in COM-DIALOG, but without
> success.  How can I close that window?

Ooops, I didn't notice this bug:

  Windows opened by open-window-stream are not automatically closed when their parent is closed
  http://mcclim.cliki.net/Bug#open-window-stream-not-closed

I do not need to close the parent, but what I reported is probably
related to this bug.  In the CLOSE method on CLIM-STREAM-PANE in
panes.lisp, the call to DISABLE-FRAME does not apparently do much.  I
tried adding the forms:

  (frame-exit *application-frame*)

or:

  (frame-exit (pane-frame stream))

before and after the one to DISABLE-FRAME, but the window still
refuses to close.


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


From csr21 at cam.ac.uk  Sun Apr  3 13:42:52 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sun, 03 Apr 2005 14:42:52 +0100
Subject: [mcclim-devel] sb-bsd-sockets
In-Reply-To: <sqd5tcfk66.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Sun, 03 Apr 2005 07:28:49 +0100")
References: <424B07A8.3060500@math.ubc.ca>
	<3afebc0e4aa245b5035a071f0d10c929@mastenbrook.net>
	<424F7DF5.2020006@math.ubc.ca> <sqd5tcfk66.fsf@cam.ac.uk>
Message-ID: <sq8y40f02r.fsf@cam.ac.uk>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> Boris Tschirschwitz <boris at math.ubc.ca> writes:
>
>> PS: Of course, climacs still depends on clx
>
> It does?  Why?

Ah, translate.lisp; if you're interested in trying climacs with the
beagle backend, you can safely excise translate.lisp from climacs.asd;
it is a hotfix for a clx-specific problem.

Cheers,

Christophe


From tourtelt at yahoo.com  Sun Apr  3 21:51:10 2005
From: tourtelt at yahoo.com (George Tourtellot)
Date: Sun, 3 Apr 2005 14:51:10 -0700 (PDT)
Subject: [mcclim-devel] demos problem
Message-ID: <20050403215110.49740.qmail@web54105.mail.yahoo.com>

Hello,
I'm just starting out with McCLIM.

I have CMUCL 19a installed, and ASDF installed, and
have followed instructions (using ASDF commands) in
file INSTALL.CMU.
All seems to be working properly until I actually try
running a demo.

For example, I do/get:
-------------------
 (clim-demo::run-test 'goatee::goatee-test)
Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
      NIL is not of type (MOD 536870911)
Error flushed ...

          (menutest::menutest)
Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
      NIL is not of type (MOD 536870911)
Error flushed ...
------------------

do you know why this happens? how can I get demos to
work?

thanks a lot,
George





		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 


From amoroso at mclink.it  Mon Apr  4 12:03:11 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 04 Apr 2005 14:03:11 +0200
Subject: [mcclim-devel] demos problem
References: <20050403215110.49740.qmail@web54105.mail.yahoo.com>
Message-ID: <87mzsekav4.fsf@plato.moon.paoloamoroso.it>

George Tourtellot <tourtelt at yahoo.com> writes:

>  (clim-demo::run-test 'goatee::goatee-test)
> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
>       NIL is not of type (MOD 536870911)
> Error flushed ...
>
>           (menutest::menutest)
> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
>       NIL is not of type (MOD 536870911)
> Error flushed ...
> ------------------
>
> do you know why this happens? how can I get demos to
> work?

The menu and goatee tests are not compiled with the other demos by the
build form:

  (asdf:operate 'asdf:load-op :clim-examples)

You have to explicitly compile and load the corresponding files:

  Examples/menutest.lisp
  Giatee/goatee-test.lisp

Would it be possible to make mcclim.asd include all working demos?


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


From rpgoldman at sift.info  Mon Apr  4 22:59:03 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Mon, 4 Apr 2005 17:59:03 -0500
Subject: [mcclim-devel] question about behavior of describe
Message-ID: <16977.50871.196375.93646@gargle.gargle.HOWL>


In the old days, I was able to click on an object that I had displayed
in a McCLIM application frame and describe it (using "describe
presentation"?).  Now this isn't available any more.  Now when I use
the right mouse menu, I see "Describe," but I have not been able to
persuade it to describe the things I have presented.  For that matter,
it doesn't really do anything even on numbers.  I realize that this is
probably a very dumb question, but is there some primer somewhere on
how to make this do something nice with my presentations?

Thanks,
R


From strandh at labri.fr  Tue Apr  5 03:48:10 2005
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 5 Apr 2005 05:48:10 +0200
Subject: [mcclim-devel] question about behavior of describe
In-Reply-To: <16977.50871.196375.93646@gargle.gargle.HOWL>
References: <16977.50871.196375.93646@gargle.gargle.HOWL>
Message-ID: <16978.2682.359374.64291@serveur5.labri.fr>

rpgoldman at sift.info writes:
 > 
 > In the old days, I was able to click on an object that I had displayed
 > in a McCLIM application frame and describe it (using "describe
 > presentation"?).  Now this isn't available any more.  Now when I use
 > the right mouse menu, I see "Describe," but I have not been able to
 > persuade it to describe the things I have presented.  For that matter,
 > it doesn't really do anything even on numbers.  I realize that this is
 > probably a very dumb question, but is there some primer somewhere on
 > how to make this do something nice with my presentations?

The previous default behavior was removed because not every
application wanted it (it was a rather implementation-oriented
feature).  

-- 
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 rpgoldman at sift.info  Tue Apr  5 04:52:09 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Mon, 4 Apr 2005 23:52:09 -0500
Subject: [mcclim-devel] question about behavior of describe
In-Reply-To: <16978.2682.359374.64291@serveur5.labri.fr>
References: <16977.50871.196375.93646@gargle.gargle.HOWL>
	<16978.2682.359374.64291@serveur5.labri.fr>
Message-ID: <16978.6521.962177.951388@gargle.gargle.HOWL>

>>>>> "RS" == Robert Strandh <strandh at labri.fr> writes:

    RS> rpgoldman at sift.info writes:
    >> 
    >> In the old days, I was able to click on an object that I had displayed
    >> in a McCLIM application frame and describe it (using "describe
    >> presentation"?).  Now this isn't available any more.  Now when I use
    >> the right mouse menu, I see "Describe," but I have not been able to
    >> persuade it to describe the things I have presented.  For that matter,
    >> it doesn't really do anything even on numbers.  I realize that this is
    >> probably a very dumb question, but is there some primer somewhere on
    >> how to make this do something nice with my presentations?

    RS> The previous default behavior was removed because not every
    RS> application wanted it (it was a rather implementation-oriented
    RS> feature).  

Thanks.  I understand and sympathize.  But is there some easy recipe
to get this behavior back?  Either to get it for a whole application
(my biggest use for McCLIM was for debugging tools), or for particular
objects?

I feel sure that this is a stupid question and that there's some
RTFMish thing I should be doing, but the CLIM literature seems so
scattered and fragmented that I'm finding it hard to get a handle on
it.

Best,
R


From pw at snoopy.mv.com  Tue Apr  5 10:56:33 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Tue, 5 Apr 2005 06:56:33 -0400
Subject: [mcclim-devel] question about behavior of describe
Message-ID: <20050405105633.7846.qmail@copper.mv.net>

> 
>     RS> The previous default behavior was removed because not every
>     RS> application wanted it (it was a rather implementation-oriented
>     RS> feature).  
> 
> Thanks.  I understand and sympathize.  But is there some easy recipe
> to get this behavior back?  Either to get it for a whole application
> (my biggest use for McCLIM was for debugging tools), or for particular
> objects?
> 

You could have your presentation types subclass a presentation type for
which you have a command, say com-describe-object, and then have
a presentation translator (DEFINE-PRESENTATION-TO-COMMAND-TRANSLATOR)
on the superclass and middle button (:describe gesture) to invoke it.

Paul



From rpgoldman at sift.info  Tue Apr  5 16:54:15 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Tue, 5 Apr 2005 11:54:15 -0500
Subject: [mcclim-devel] question about behavior of describe
In-Reply-To: <20050405105633.7846.qmail@copper.mv.net>
References: <20050405105633.7846.qmail@copper.mv.net>
Message-ID: <16978.49847.120727.901340@gargle.gargle.HOWL>


    RS> The previous default behavior was removed because not every
    RS> application wanted it (it was a rather implementation-oriented
    RS> feature).  

I apologize if this is another dumb question, but wouldn't it be
reasonable to allow McCLIM programmers to choose whether or not they
want the old default behavior by encapsulating it in a command-table,
and allowing the programmer to decide whether or not that behavior is
what s/he wants?

Possibly there would also have to be a presentation type defined that
we could adopt as a mixin in order to get this default behavior from a
mouse click.

I'm probably just whining --- that old default behavior + graphing
(format-graph-from-roots) was all I wanted for a debugger app, and now
it seems like a fairly substantial amount of programming + grokking
CLIM is required to recover what I used to get in about 30 loc....

One thing that still puzzles me is that there seems to be some
"Describe" functionality still there, but it doesn't seem happy with
ordinary presentations.  Indeed, I can't get it to work at all (at
least on ACL 6.2).  Nothing I seem to type into the prompt box
(including simple integers) does anything I recognize when I press
Exit.

R


From asf at boinkor.net  Tue Apr  5 18:02:20 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Tue, 05 Apr 2005 20:02:20 +0200
Subject: [mcclim-devel] question about behavior of describe
In-Reply-To: <16978.49847.120727.901340@gargle.gargle.HOWL>
References: <20050405105633.7846.qmail@copper.mv.net>
	<16978.49847.120727.901340@gargle.gargle.HOWL>
Message-ID: <87sm25gl03.wl%asf@boinkor.net>

Today, <rpgoldman at sift.info> wrote:
> RS> The previous default behavior was removed because not every
> RS> application wanted it (it was a rather implementation-oriented
> RS> feature).  
>
> I apologize if this is another dumb question, but wouldn't it be
> reasonable to allow McCLIM programmers to choose whether or not they
> want the old default behavior by encapsulating it in a
> command-table, and allowing the programmer to decide whether or not
> that behavior is what s/he wants?

Sorry if I'm missing the point of this thread, but at least on McCLIM
0.9.1, I can still access the "describe presentation" command by
left-clicking on the presentation while holding the Super key.

Granted, it's not in the most accessible places on many keyboards, but
it's available so it should be possible to re-map if you need it
somewhere else.

Good luck,
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From rpgoldman at real-time.com  Tue Apr  5 20:01:52 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Tue, 5 Apr 2005 15:01:52 -0500
Subject: [mcclim-devel] question about behavior of describe
In-Reply-To: <87sm25gl03.wl%asf@boinkor.net>
References: <20050405105633.7846.qmail@copper.mv.net>
	<16978.49847.120727.901340@gargle.gargle.HOWL>
	<87sm25gl03.wl%asf@boinkor.net>
Message-ID: <16978.61104.402073.704677@gargle.gargle.HOWL>

>>>>> "asf" == Andreas Fuchs <asf at boinkor.net> writes:

    asf> Today, <rpgoldman at sift.info> wrote:
    RS> The previous default behavior was removed because not every
    RS> application wanted it (it was a rather implementation-oriented
    RS> feature).  
    >> 
    >> I apologize if this is another dumb question, but wouldn't it be
    >> reasonable to allow McCLIM programmers to choose whether or not they
    >> want the old default behavior by encapsulating it in a
    >> command-table, and allowing the programmer to decide whether or not
    >> that behavior is what s/he wants?

    asf> Sorry if I'm missing the point of this thread, but at least on McCLIM
    asf> 0.9.1, I can still access the "describe presentation" command by
    asf> left-clicking on the presentation while holding the Super
    asf> key.

Perhaps the problem's at my end.  I do not seem to be able to do this
(although I have a super key defined, AFAICT).  Further, when I
explicitly add a menubar with "Describe presentation" on it:

(make-command-table 'debug-command-table
		    :errorp nil
		    :menu '(("Describe presentation"
			     :command
			     com-describe-presentation)
			    ("Describe object"
			     :command
			     com-describe-object)))

(make-command-table 'menubar-command-table
		    :errorp nil
		    :menu '(("Describe" :menu debug-command-table)))

The "Describe presentation" menu item appears grayed out and seems
inactive.  I'm using a copy I pulled from CVS yesterday (and rebuilt
from source).

Can anyone correct me on this?

R


From rpgoldman at sift.info  Tue Apr  5 21:40:37 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Tue, 5 Apr 2005 16:40:37 -0500
Subject: [mcclim-devel] manual
Message-ID: <16979.1493.181665.800077@gargle.gargle.HOWL>


I wanted to be able to navigate the manual better, so was playing with
formats.  

First I tried latex2html, but found that it doesn't deal well with the
new macros for all the definitions (e.g., \defmacro).  I wrestled with
this for a while, but had no luck.

Then I tried pdflatex with the hyperref package.  This lets us
generate pdf with the bookmarks pane of acrobat accessible, which
makes it much easier to mouse around the document.

The only problem is that you can't include ps files into pdflatex; you
must translate them into pdf first.

If that doesn't bother anyone, I could provide patches.  For the
moment, I'll put the new pdf up on my website for people to look at.

http://rpgoldman.real-time.com/papers/mcclim-manual.pdf

Cheers,
R


From strandh at labri.fr  Wed Apr  6 04:23:25 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 6 Apr 2005 06:23:25 +0200
Subject: [mcclim-devel] manual
In-Reply-To: <16979.1493.181665.800077@gargle.gargle.HOWL>
References: <16979.1493.181665.800077@gargle.gargle.HOWL>
Message-ID: <16979.25661.844078.356262@serveur5.labri.fr>

rpgoldman at sift.info writes:
 > 
 > I wanted to be able to navigate the manual better, so was playing with
 > formats.  
 > 
 > First I tried latex2html, but found that it doesn't deal well with the
 > new macros for all the definitions (e.g., \defmacro).  I wrestled with
 > this for a while, but had no luck.
 > 
 > Then I tried pdflatex with the hyperref package.  This lets us
 > generate pdf with the bookmarks pane of acrobat accessible, which
 > makes it much easier to mouse around the document.
 > 
 > The only problem is that you can't include ps files into pdflatex; you
 > must translate them into pdf first.
 > 
 > If that doesn't bother anyone, I could provide patches. 

Sure, thanks!

 > For the moment, I'll put the new pdf up on my website for people to
 > look at. 
 >
 > http://rpgoldman.real-time.com/papers/mcclim-manual.pdf

Looks pretty good.
-- 
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 rpgoldman at sift.info  Wed Apr  6 14:36:18 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Wed, 6 Apr 2005 09:36:18 -0500
Subject: [mcclim-devel] manual -- patches for pdflatex
In-Reply-To: <16979.25661.844078.356262@serveur5.labri.fr>
References: <16979.1493.181665.800077@gargle.gargle.HOWL>
	<16979.25661.844078.356262@serveur5.labri.fr>
Message-ID: <16979.62434.280323.538580@gargle.gargle.HOWL>


Notes on the changes:  

1.  The results might look better on more platforms if we used the
    roman and helvet packages.  I haven't experimented yet.

2.  I think if the macros for defun, etc. were rewritten into LaTeX
    rather than in raw TeX, latex2html might be happier.

3.  I have not yet patched the makefile.  I tend not to use make for
    latex docs, because I've never figured out how to get make to
    recognize when latex needs to do a second pass to get the
    cross-references right.  Perhaps someone else does...

4.  Annoyingly, the hyperref usepackage does NOT work with vanilla
    latex, so one can't just switch between latex and pdflatex.
    Probably adding some wrapper files around manual.tex for latex and
    pdflatex would solve this problem, or some \if fu.

Changes required:

1.  Generate the following files from postscript, using ps2pdf:

inspect-object-1.pdf
inspect-object-2.pdf
inspect-object-3.pdf
inspect-as-cells.pdf
ex2.pdf
native.pdf

2.  Patch manual.tex by replacing postscript figures with pdf figures,
    and add hyperref \usepackage to get pdf bookmarks.  Here's the
    patch:

Index: manual.tex
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Doc/manual.tex,v
retrieving revision 1.26
diff -c -r1.26 manual.tex
*** manual.tex	11 Mar 2005 22:34:59 -0000	1.26
--- manual.tex	6 Apr 2005 14:28:00 -0000
***************
*** 6,11 ****
--- 6,12 ----
  \usepackage{epsfig}
  \usepackage{alltt}
  \usepackage{moreverb}
+ \usepackage[pdftex]{hyperref}
  
  \setlength{\parskip}{0.3cm}
  \setlength{\parindent}{0cm}
***************
*** 372,378 ****
  
  \begin{figure}
  \begin{center}
! \inputfig{ex2.pstex_t}
  \end{center}
  \caption{\label{figex2} View of the improved example}
  \end{figure}
--- 373,379 ----
  
  \begin{figure}
  \begin{center}
! \includegraphics{ex2.pdf}
  \end{center}
  \caption{\label{figex2} View of the improved example}
  \end{figure}
***************
*** 643,650 ****
  c.  Mirrors are outlined with dotted rectangles. 
  
  \begin{figure}
! \begin{center}
! \inputfig{native.pstex_t}
  \end{center}
  \caption{\label{fignative} A sheet with a nontrivial transformation}
  \end{figure}
--- 644,652 ----
  c.  Mirrors are outlined with dotted rectangles. 
  
  \begin{figure}
!   \begin{center}
!     \input native.pstex_t
! %\inputfig{native.pstex_t}
  \end{center}
  \caption{\label{fignative} A sheet with a nontrivial transformation}
  \end{figure}
***************
*** 1576,1582 ****
  The new cons cell diagram format looks like this:
  
  \begin{center}
! \includegraphics{inspect-as-cells.eps}
  \end{center}
  
  \section{Extending Clouseau}
--- 1578,1584 ----
  The new cons cell diagram format looks like this:
  
  \begin{center}
! \includegraphics{inspect-as-cells.pdf}
  \end{center}
  
  \section{Extending Clouseau}
***************
*** 1718,1724 ****
  the right. This gives us some reasonably nice-looking output:
  
  \begin{center}
! \includegraphics{inspect-object-1.eps}
  \end{center}
  
  But what we really want is something more closely adapted to our
--- 1720,1726 ----
  the right. This gives us some reasonably nice-looking output:
  
  \begin{center}
! \includegraphics{inspect-object-1.pdf}
  \end{center}
  
  But what we really want is something more closely adapted to our
***************
*** 1754,1760 ****
  to \cl{x=y} and we're done. It looks like this:
  
  \begin{center}
! \includegraphics{inspect-object-2.eps}
  \end{center}
  
  Finally, for our amusement and further practice, we'll try to get some
--- 1756,1762 ----
  to \cl{x=y} and we're done. It looks like this:
  
  \begin{center}
! \includegraphics{inspect-object-2.pdf}
  \end{center}
  
  Finally, for our amusement and further practice, we'll try to get some
***************
*** 1816,1822 ****
  Our final version looks like this:
  
  \begin{center}
! \includegraphics{inspect-object-3.eps}
  \end{center}
  
  For more examples of how to extend the inspector, you can look at
--- 1818,1824 ----
  Our final version looks like this:
  
  \begin{center}
! \includegraphics{inspect-object-3.pdf}
  \end{center}
  
  For more examples of how to extend the inspector, you can look at




From wence at gmx.li  Wed Apr  6 18:44:02 2005
From: wence at gmx.li (Lawrence Mitchell)
Date: Wed, 06 Apr 2005 19:44:02 +0100
Subject: [mcclim-devel] Re: manual -- patches for pdflatex
References: <16979.1493.181665.800077@gargle.gargle.HOWL>
	<16979.25661.844078.356262@serveur5.labri.fr>
	<16979.62434.280323.538580@gargle.gargle.HOWL>
Message-ID: <?fnord?87ekdn7nkd.fsf@ID-97657.user.individual.net>

rpgoldman at sift.info wrote:

[...]

> ! \includegraphics{ex2.pdf}

If you leave off the extension, \includegraphics will
(generally) automatically pick the correct file format (.eps or
.pdf) depending on whether latex or pdflatex is being run.

[...]

-- 
Lawrence Mitchell <wence at gmx.li>



From rpgoldman at real-time.com  Wed Apr  6 19:58:13 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Wed, 6 Apr 2005 14:58:13 -0500
Subject: [mcclim-devel] Re: manual -- patches for pdflatex
In-Reply-To: <?fnord?87ekdn7nkd.fsf@ID-97657.user.individual.net>
References: <16979.1493.181665.800077@gargle.gargle.HOWL>
	<16979.25661.844078.356262@serveur5.labri.fr>
	<16979.62434.280323.538580@gargle.gargle.HOWL>
	<?fnord?87ekdn7nkd.fsf@ID-97657.user.individual.net>
Message-ID: <16980.16213.274711.313011@gargle.gargle.HOWL>

>>>>> "LM" == Lawrence Mitchell <wence at gmx.li> writes:

    LM> rpgoldman at sift.info wrote:
    LM> [...]

    >> ! \includegraphics{ex2.pdf}

    LM> If you leave off the extension, \includegraphics will
    LM> (generally) automatically pick the correct file format (.eps or
    LM> .pdf) depending on whether latex or pdflatex is being run.

    LM> [...]

Thanks!  I note also that I had to mess with native.pstex_t to make
this work, which feels a little unfortunate to me.  This is a little
tex file that mostly includes an image and decorates it with some
picture commands.  I'm inclined to suggest that it simply be folded
into the overall tex source, although it's integrated into the
Makefile...

Here's a new patch file that takes Lawrence's suggestions into
account, and a modified version of native.pstex_t.  Not mimulated.

----------------------------------------------------------------------
Index: manual.tex
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Doc/manual.tex,v
retrieving revision 1.26
diff -c -r1.26 manual.tex
*** manual.tex	11 Mar 2005 22:34:59 -0000	1.26
--- manual.tex	6 Apr 2005 19:56:40 -0000
***************
*** 7,12 ****
--- 7,17 ----
  \usepackage{alltt}
  \usepackage{moreverb}
  
+ \ifx\pdfoutput\undefined \csname newcount\endcsname\pdfoutput \fi 
+ \ifcase\pdfoutput  \else 
+ \usepackage[pdftex]{hyperref}
+ \fi
+ 
  \setlength{\parskip}{0.3cm}
  \setlength{\parindent}{0cm}
  
***************
*** 372,378 ****
  
  \begin{figure}
  \begin{center}
! \inputfig{ex2.pstex_t}
  \end{center}
  \caption{\label{figex2} View of the improved example}
  \end{figure}
--- 377,383 ----
  
  \begin{figure}
  \begin{center}
! \includegraphics{ex2}
  \end{center}
  \caption{\label{figex2} View of the improved example}
  \end{figure}
***************
*** 643,650 ****
  c.  Mirrors are outlined with dotted rectangles. 
  
  \begin{figure}
! \begin{center}
! \inputfig{native.pstex_t}
  \end{center}
  \caption{\label{fignative} A sheet with a nontrivial transformation}
  \end{figure}
--- 648,656 ----
  c.  Mirrors are outlined with dotted rectangles. 
  
  \begin{figure}
!   \begin{center}
!     \input native.pstex_t
! %\inputfig{native.pstex_t}
  \end{center}
  \caption{\label{fignative} A sheet with a nontrivial transformation}
  \end{figure}
***************
*** 1576,1582 ****
  The new cons cell diagram format looks like this:
  
  \begin{center}
! \includegraphics{inspect-as-cells.eps}
  \end{center}
  
  \section{Extending Clouseau}
--- 1582,1588 ----
  The new cons cell diagram format looks like this:
  
  \begin{center}
! \includegraphics{inspect-as-cells}
  \end{center}
  
  \section{Extending Clouseau}
***************
*** 1718,1724 ****
  the right. This gives us some reasonably nice-looking output:
  
  \begin{center}
! \includegraphics{inspect-object-1.eps}
  \end{center}
  
  But what we really want is something more closely adapted to our
--- 1724,1730 ----
  the right. This gives us some reasonably nice-looking output:
  
  \begin{center}
! \includegraphics{inspect-object-1}
  \end{center}
  
  But what we really want is something more closely adapted to our
***************
*** 1754,1760 ****
  to \cl{x=y} and we're done. It looks like this:
  
  \begin{center}
! \includegraphics{inspect-object-2.eps}
  \end{center}
  
  Finally, for our amusement and further practice, we'll try to get some
--- 1760,1766 ----
  to \cl{x=y} and we're done. It looks like this:
  
  \begin{center}
! \includegraphics{inspect-object-2}
  \end{center}
  
  Finally, for our amusement and further practice, we'll try to get some
***************
*** 1816,1822 ****
  Our final version looks like this:
  
  \begin{center}
! \includegraphics{inspect-object-3.eps}
  \end{center}
  
  For more examples of how to extend the inspector, you can look at
--- 1822,1828 ----
  Our final version looks like this:
  
  \begin{center}
! \includegraphics{inspect-object-3}
  \end{center}
  
  For more examples of how to extend the inspector, you can look at


----------------------------------------------------------------------

native.pstex_t

\begin{picture}(0,0)%
\includegraphics{native}%
\end{picture}%
\setlength{\unitlength}{3108sp}%
%
\begingroup\makeatletter\ifx\SetFigFont\undefined%
\gdef\SetFigFont#1#2#3#4#5{%
  \reset at font\fontsize{#1}{#2pt}%
  \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
  \selectfont}%
\fi\endgroup%
\begin{picture}(4983,4407)(1,-3673)
\end{picture}%

----------------------------------------------------------------------

Cheers,
R


From strandh at labri.fr  Thu Apr  7 07:58:13 2005
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 7 Apr 2005 09:58:13 +0200
Subject: [mcclim-devel] Re: manual -- patches for pdflatex
In-Reply-To: <16980.16213.274711.313011@gargle.gargle.HOWL>
References: <16979.1493.181665.800077@gargle.gargle.HOWL>
	<16979.25661.844078.356262@serveur5.labri.fr>
	<16979.62434.280323.538580@gargle.gargle.HOWL>
	<?fnord?87ekdn7nkd.fsf@ID-97657.user.individual.net>
	<16980.16213.274711.313011@gargle.gargle.HOWL>
Message-ID: <16980.59413.863407.674641@serveur5.labri.fr>

rpgoldman at real-time.com writes:
 >
 > Here's a new patch file that takes Lawrence's suggestions into
 > account, and a modified version of native.pstex_t.  Not mimulated.

Patch applied. Thanks.
-- 
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 rpgoldman at sift.info  Thu Apr  7 14:19:48 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Thu, 7 Apr 2005 09:19:48 -0500
Subject: [mcclim-devel] question about format-graph-from-roots
Message-ID: <16981.16772.338257.760529@gargle.gargle.HOWL>


Some time ago, Paolo (IIRC) posted a suggested patch to
format-graph-from-roots to supply a default for the arc-drawer keyword
argument.  Again, IIRC, the CLIM spec requires that there be such a
default.  I was just updating this morning, and noticed that the patch
has never been applied.  Would someone please apply it (unless there's
something wrong with it)?  One possible problem is that it ignores the
arc-drawing-options keyword, but it still seems better than not having
a default at all. 

Here's the patch:



Index: graph-formatting.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/graph-formatting.lisp,v
retrieving revision 1.11
diff -u -F^(def -r1.11 graph-formatting.lisp
--- graph-formatting.lisp       5 Dec 2004 19:37:52 -0000       1.11
+++ graph-formatting.lisp       7 Apr 2005 14:18:17 -0000
@@ -120,14 +120,20 @@ (define-graph-type :digraph digraph-grap
 ;;;; Entry

 (defun format-graph-from-roots (root-objects object-printer inferior-producer
-                                &rest graph-options
-                                &key stream orientation cutoff-depth
-                                     merge-duplicates duplicate-key duplicate-test
-                                     generation-separation
-                                     within-generation-separation
-                                     center-nodes arc-drawer arc-drawing-options
-                                     graph-type (move-cursor t)
-                                &allow-other-keys)
+                                            &rest graph-options
+                                            &key stream orientation cutoff-depth
+                                            merge-duplicates duplicate-key duplicate-test
+                                            generation-separation
+                                            within-generation-separation
+                                            center-nodes
+                                            (arc-drawer
+                                             #'(lambda (stream from to from-x from-y to-x to-y)
+                                                 (declare (ignore from to))
+                                                 (draw-line* stream from-x from-y to-x to-y)))
+
+                                            arc-drawing-options
+                                            graph-type (move-cursor t)
+                                            &allow-other-keys)
   (declare (ignore orientation generation-separation within-generation-separation center-nodes))
   ;; Mungle some arguments
   (check-type cutoff-depth (or null integer))


From rpgoldman at sift.info  Thu Apr  7 15:35:34 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Thu, 7 Apr 2005 10:35:34 -0500
Subject: [mcclim-devel] fussy clean-up items
Message-ID: <16981.21318.607444.636529@gargle.gargle.HOWL>


I was just reading over the warnings the ACL compiler gives me, and I
noticed that we have three definitions of make-keyword, in
presentations.lisp, commands.lisp, and utils.lisp.  I don't claim to
understand the dueling system definitions (mk-defsystem and asdf) to
know which ones should be killed, but any objections to killing a
couple?

Also, the compiler beefs about double definitions of 

(METHOD %PRESENTATION-TYPEP (T T T))
and
(METHOD %PRESENT (T T T T TEXTUAL-VIEW))

is this due to the eval-when form being evaluated first at compile
time, and then at load time?

Cheers,

r


From rpgoldman at real-time.com  Tue Apr 12 16:35:19 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Tue, 12 Apr 2005 11:35:19 -0500
Subject: [mcclim-devel] question about format-graph-from-roots
Message-ID: <16987.63687.43602.828188@gargle.gargle.HOWL>


One suggested patch and one question:

1.  Suggested patch: should we modify format-graph-from roots so that
    the defualt value for :arc-drawer is
    #'clim-internals::standard-arc-drawer?

2.  I have been trying to figure out how to draw a graph that has
    multiple different kinds of edges.  Actually, more specifically, I
    would like to draw a graph that is "mostly" a tree: it has a tree
    backbone, and then has some cross-edges.  It isn't at all obvious
    how to do this nicely.  There are (at least) two problems:

    i.  I don't see an elegant way to indicate the type of edges.
        AFAICT, the CLIM spec indicates that we simply generate
        children, i.e., nodes.  We never generate edges, except
        implicitly.  My best guess is that the way to do this is
        either:
	a. have the "from" node always have enough information to
	   determine what sort of edge is to be drawn from it to the
	   "to" node.  This actually breaks down a little in the case
	   where there can be multiple arcs from one "from" to a
	   single "to."
	b. create a new data structure (some form of association like
	   a hash table, alist or whatever) that records the type of
	   arc to be drawn, and stuff it into your arc drawer
	   function.

     ii. More seriously, there doesn't seem any obvious way to say
         that an arc between "from" and "to" is a cross-edge, and
         shouldn't increment the depth of "to," rather than being a
         child edge that DOES increment the depth.  Anyone have any
         suggestions for this?  It seems the more difficult problem.

Best,
R




From rpgoldman at real-time.com  Tue Apr 12 18:58:59 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Tue, 12 Apr 2005 13:58:59 -0500
Subject: [mcclim-devel] typesetting CLIM spec
Message-ID: <16988.6771.754388.448911@gargle.gargle.HOWL>


Flushed with my success pdf-ulating the manual, I had a run up at the
CLIM spec.  This seems to work with minimal patching.  Simply apply
the following, and use pdflatex instead of latex, and you get a
version that has bookmarks and hyperlinks in it.

One problem:  regions.tex seems to require a file named
file-normalization.epsi.  I was going to translate it into pdf, but
found that it's nowhere in the copy of mcclim that I checked out.  Is
this a bug with the spec LaTex?

Best,
r


Index: clim.tex
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Spec/src/clim.tex,v
retrieving revision 1.1
diff -c -r1.1 clim.tex
*** clim.tex	11 Dec 2000 06:59:59 -0000	1.1
--- clim.tex	12 Apr 2005 18:54:56 -0000
***************
*** 17,22 ****
--- 17,29 ----
    {\end{small}\clearpage}
  \makeatother
  
+ %% added to try to make nice bookmarks in PDF... [2005/04/12:rpg]
+ \ifx\pdfoutput\undefined \csname newcount\endcsname\pdfoutput \fi 
+ \ifcase\pdfoutput  \else 
+ \usepackage[pdftex]{hyperref}
+ \fi
+ 
+ 
  %\usepackage{times}
  
  %% For PDF


From amoroso at mclink.it  Tue Apr 12 19:22:11 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 12 Apr 2005 21:22:11 +0200
Subject: [mcclim-devel] question about format-graph-from-roots
In-Reply-To: <16987.63687.43602.828188@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Tue, 12 Apr 2005 11:35:19 -0500")
References: <16987.63687.43602.828188@gargle.gargle.HOWL>
Message-ID: <877jj77qcc.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> 1.  Suggested patch: should we modify format-graph-from roots so that
>     the defualt value for :arc-drawer is
>     #'clim-internals::standard-arc-drawer?

I think so.  Concerning the :arc-drawer argument of
clim:format-graph-from-roots, the CLIM specification says:

  If arc-drawer is unsupplied, the default behavior is to draw a thin
  line from the ``from'' node to the ``to'' node using draw-line* .

and the definition of clim-internals::standard-arc-drawer does that.


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


From rpgoldman at real-time.com  Tue Apr 12 20:11:02 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Tue, 12 Apr 2005 15:11:02 -0500
Subject: [mcclim-devel] question about format-graph-from-roots
In-Reply-To: <877jj77qcc.fsf@plato.moon.paoloamoroso.it>
References: <16987.63687.43602.828188@gargle.gargle.HOWL>
	<877jj77qcc.fsf@plato.moon.paoloamoroso.it>
Message-ID: <16988.11094.112933.793509@gargle.gargle.HOWL>

>>>>> "PA" == Paolo Amoroso <amoroso at mclink.it> writes:

    PA> rpgoldman at real-time.com writes:

    >> 1.  Suggested patch: should we modify format-graph-from roots so that
    >> the defualt value for :arc-drawer is
    >> #'clim-internals::standard-arc-drawer?

    PA> I think so.  Concerning the :arc-drawer argument of
    PA> clim:format-graph-from-roots, the CLIM specification says:

    PA>   If arc-drawer is unsupplied, the default behavior is to draw a thin
    PA>   line from the ``from'' node to the ``to'' node using draw-line* .

    PA> and the definition of clim-internals::standard-arc-drawer does that.

Great.  Would someone with CVS write permission be willing to make
this change?  Neither Paolo nor I can do this.

BTW, it might be nice to export the standard-arc-drawer and
standard-arrow-drawer functions, too....

Thanks,
R



From csr21 at cam.ac.uk  Wed Apr 13 08:35:32 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 13 Apr 2005 09:35:32 +0100
Subject: [mcclim-devel] question about format-graph-from-roots
In-Reply-To: <16988.11094.112933.793509@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Tue, 12 Apr 2005 15:11:02 -0500")
References: <16987.63687.43602.828188@gargle.gargle.HOWL>
	<877jj77qcc.fsf@plato.moon.paoloamoroso.it>
	<16988.11094.112933.793509@gargle.gargle.HOWL>
Message-ID: <sqoecj3wh7.fsf@cam.ac.uk>

rpgoldman at real-time.com writes:

> Great.  Would someone with CVS write permission be willing to make
> this change?  Neither Paolo nor I can do this.

Andy has done so.

While closing the bug on the mccliki bug page, I noticed that
text-paste-returns garbage is still logged as open.  Is this in fact
the case?  (Paolo?)

Cheers,

Christophe


From amoroso at mclink.it  Wed Apr 13 13:04:11 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 13 Apr 2005 15:04:11 +0200
Subject: [mcclim-devel] question about format-graph-from-roots
In-Reply-To: <sqoecj3wh7.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Wed, 13 Apr 2005 09:35:32 +0100")
References: <16987.63687.43602.828188@gargle.gargle.HOWL>
	<877jj77qcc.fsf@plato.moon.paoloamoroso.it>
	<16988.11094.112933.793509@gargle.gargle.HOWL>
	<sqoecj3wh7.fsf@cam.ac.uk>
Message-ID: <871x9ezv3o.fsf@plato.moon.paoloamoroso.it>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> While closing the bug on the mccliki bug page, I noticed that
> text-paste-returns garbage is still logged as open.  Is this in fact
> the case?  (Paolo?)

Ooops... It is fixed.  I forgot to update the entry when closing:

  http://mcclim.cliki.net/Bug#loop-when copying-text

Done.


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


From metch at daimi.au.dk  Thu Apr 14 17:40:45 2005
From: metch at daimi.au.dk (Peter Mechlenborg)
Date: Thu, 14 Apr 2005 19:40:45 +0200
Subject: [mcclim-devel] clim-debugger
Message-ID: <425EAB1D.5020107@daimi.au.dk>

Hi all


I finally took some time off to do a bit on the debugger again. It can
be found here:

http://www.daimi.au.dk/~metch/lisp/clim-debugger.lisp


Changes:

- A "more button" have been added, so more stack-frames can be viewed
   if 20 isn't enough.

- Scroll-bars have been added, thanks to Elliott Johnson. There's
   still a small problem though. The scroll-bars do not remember their
   position when a stack-frame or "more" is pressed. I don't know how
   to fix this, couldn't find anything in the specs and Clouseau didn't
   help either. Do anyone of you know how to do this?

- Frame variables are viewed with Clouseau when pressed.


What do you think?


Have fun,

   -- Peter


From asf at boinkor.net  Thu Apr 14 22:21:02 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Fri, 15 Apr 2005 00:21:02 +0200
Subject: [mcclim-devel] clim-debugger
In-Reply-To: <425EAB1D.5020107@daimi.au.dk>
References: <425EAB1D.5020107@daimi.au.dk>
Message-ID: <87ekddov8x.wl%asf@boinkor.net>

Today, Peter Mechlenborg <metch at daimi.au.dk> wrote:
> Changes:
>
> - A "more button" have been added, so more stack-frames can be
>   viewed if 20 isn't enough.
>
> - Scroll-bars have been added, thanks to Elliott Johnson. There's
>   still a small problem though. The scroll-bars do not remember their
>   position when a stack-frame or "more" is pressed. I don't know how
>   to fix this, couldn't find anything in the specs and Clouseau didn't
>   help either. Do anyone of you know how to do this?
>
> - Frame variables are viewed with Clouseau when pressed.
>
>
> What do you think?

I think it rocks. I found the fonts a bit unreadable on descriptive
texts, so I hacked on it a little. This patch adds:

 * better fonts on descriptions (not on reference-conditions reference
   slots yet, I'm hoping somebody figures a way to render them soon)
 * (maybe) better formatting of reference condition descriptions &
   extra condition info
 * better handling of multi-table-column presentation (you can now
   click on a stack frame number and on a restart description)
 * doesn't show the --MORE-- link when there are fewer than 20 frames.

Here's some lisp porn:
http://boinkor.net/lisp/porn/clim-debugger_pretty.png (-:
 
Hope you like it.
--- clim-debugger.orig.lisp     2005-04-14 19:08:32.000000000 +0200
+++ clim-debugger.lisp  2005-04-15 00:18:25.861376109 +0200
@@ -255,13 +255,14 @@
 ;;;   Display debugging info   ;;;;;;;;;;;;;;;;;;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
-(defun std-form (pane first second)
+(defun std-form (pane first second &key (family :sans-serif))
   (formatting-row 
       (pane)
-    (formatting-cell (pane) (bold (pane) (format t "~A" first)))
-    (formatting-cell 
-       (pane) 
-      (format t "~A" second))))
+    (with-text-family (pane :sans-serif)
+      (formatting-cell (pane) (bold (pane) (format t "~A" first))))
+    (formatting-cell (pane)
+      (with-text-family (pane family) 
+       (format t "~A" second)))))
 
 (defun display-debugger (frame pane)
   (let ((*standard-output* pane))
@@ -269,26 +270,32 @@
       (std-form pane "Condition type:" (type-of-condition (condition-info
                                                             pane)))
       (std-form pane "Description:"    (condition-message (condition-info
-                                                            pane))))
+                                                            pane)))
+      (when (condition-extra (condition-info pane))
+        (std-form pane "Extra:" (condition-extra (condition-info pane))
+                  :family :fix))
+      (when (condition-references (condition-info pane))
+        (std-form pane "References:" (condition-references (condition-info
+                                                            pane))
+                  :family :fix)))
     (fresh-line)
-    (when (condition-extra (condition-info pane))
-      (formatting-table (pane)
-       (std-form pane "Extra:" (condition-extra (condition-info pane))))
-      (fresh-line))
-    (when (condition-references (condition-info pane))
-      (formatting-table (pane)
-       (std-form pane "References:" (condition-references (condition-info
-                                                             pane))))
-      (fresh-line))
-    (bold (pane) (format t "Restarts:"))
+    
+    
+    (with-text-family (pane :sans-serif)
+      (bold (pane) (format t "Restarts:")))
     (fresh-line)
     (format t " ")
     (formatting-table 
        (pane)
       (loop for r in (restarts (condition-info pane))
-        do (formatting-row (pane) 
-             (formatting-cell (pane) (present r 'restart))
-             (formatting-cell (pane) (format t "~A" r)))))
+        do (formatting-row (pane)
+              (with-output-as-presentation (pane r 'restart)
+                (formatting-cell (pane)
+                  (format pane "~A" (restart-name r)))
+              
+                (formatting-cell (pane)
+                  (with-text-family (pane :sans-serif)
+                    (format pane "~A" r)))))))
     (fresh-line)
     (display-backtrace frame pane)
     (change-space-requirements pane
@@ -298,7 +305,8 @@
 
 (defun display-backtrace (frame pane)
   (declare (ignore frame)) 
-  (bold (pane) (format t "Backtrace:"))
+  (with-text-family (pane :sans-serif)
+    (bold (pane) (format t "Backtrace:")))
   (fresh-line)
   (format t " ")
   (formatting-table 
@@ -306,14 +314,17 @@
     (loop for stack-frame in (backtrace (condition-info pane))
          for i from 0
          do (formatting-row (pane)
-              (bold (pane) (formatting-cell (pane) (format t "~A: " i)))
-              (formatting-cell (pane) (present stack-frame 'stack-frame 
-                                               :view (view stack-frame)))))
-  (formatting-row (pane)
-    (formatting-cell (pane))
-    (formatting-cell (pane)
-      (bold (pane)
-       (present pane 'more-type))))))
+               (with-output-as-presentation (pane stack-frame 'stack-frame)
+                 (bold (pane) (formatting-cell (pane) (format t "~A: " i)))
+                 (formatting-cell (pane)
+                   (present stack-frame 'stack-frame 
+                            :view (view stack-frame))))))
+    (when (>= (length (backtrace (condition-info pane))) 20)
+      (formatting-row (pane)
+        (formatting-cell (pane))
+        (formatting-cell (pane)
+          (bold (pane)
+            (present pane 'more-type)))))))
 
 
 (define-presentation-method present (object (type stack-frame) stream
@@ -329,7 +340,8 @@
   (progn
     (princ (frame-string object) stream)
     (fresh-line)
-    (bold (stream) (format t "  Locals:"))
+    (with-text-family (stream :sans-serif)
+      (bold (stream) (format t "  Locals:")))
     (fresh-line)
     (format t "     ")
     (formatting-table 


Cheers,
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From metch at daimi.au.dk  Fri Apr 15 06:55:44 2005
From: metch at daimi.au.dk (Peter Mechlenborg)
Date: Fri, 15 Apr 2005 08:55:44 +0200
Subject: [mcclim-devel] clim-debugger
In-Reply-To: <87ekddov8x.wl%asf@boinkor.net>
References: <425EAB1D.5020107@daimi.au.dk> <87ekddov8x.wl%asf@boinkor.net>
Message-ID: <425F6570.1020905@daimi.au.dk>

Andreas Fuchs wrote:
> I think it rocks. I found the fonts a bit unreadable on descriptive
> texts, so I hacked on it a little. This patch adds:
> 
>  * better fonts on descriptions (not on reference-conditions reference
>    slots yet, I'm hoping somebody figures a way to render them soon)
>  * (maybe) better formatting of reference condition descriptions &
>    extra condition info
>  * better handling of multi-table-column presentation (you can now
>    click on a stack frame number and on a restart description)
>  * doesn't show the --MORE-- link when there are fewer than 20 frames.
> 

Super!

> Here's some lisp porn:
> http://boinkor.net/lisp/porn/clim-debugger_pretty.png (-:
>  
> Hope you like it.

I think I do, but I've never really used patch and I can't make it work 
(perhaps I'm a bit dense). I've copied the patch you provided to a file 
named clim-debugger.lisp-patch and tried this:

[goblin:~/lisp]$patch --verbose clim-debugger.lisp \
clim-debugger.lisp-patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- clim-debugger.orig.lisp     2005-04-14 19:08:32.000000000 +0200
|+++ clim-debugger.lisp  2005-04-15 00:18:25.861376109 +0200
--------------------------
Patching file clim-debugger.lisp using Plan A...
Hunk #1 FAILED at 255.
Hunk #2 FAILED at 270.
Hunk #3 succeeded at 305.
Hunk #4 FAILED at 314.
Hunk #5 succeeded at 340.
3 out of 5 hunks FAILED -- saving rejects to file clim-debugger.lisp.rej
Hmm...  Ignoring the trailing garbage.
done


Head of the patch-file:

[goblin:~/lisp]$head clim-debugger.lisp-patch
--- clim-debugger.orig.lisp     2005-04-14 19:08:32.000000000 +0200
+++ clim-debugger.lisp  2005-04-15 00:18:25.861376109 +0200
@@ -255,13 +255,14 @@
  ;;;   Display debugging info   ;;;;;;;;;;;;;;;;;;
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

-(defun std-form (pane first second)
+(defun std-form (pane first second &key (family :sans-serif))
    (formatting-row
        (pane)

Can anyone help me? Thanks.

   -- Peter


From metch at daimi.au.dk  Fri Apr 15 08:00:47 2005
From: metch at daimi.au.dk (Peter Mechlenborg)
Date: Fri, 15 Apr 2005 10:00:47 +0200
Subject: [mcclim-devel] clim-debugger
In-Reply-To: <425F6570.1020905@daimi.au.dk>
References: <425EAB1D.5020107@daimi.au.dk> <87ekddov8x.wl%asf@boinkor.net>
	<425F6570.1020905@daimi.au.dk>
Message-ID: <425F74AF.7050104@daimi.au.dk>

> 
> I think I do, but I've never really used patch and I can't make it work 
> (perhaps I'm a bit dense). I've copied the patch you provided to a file 
> named clim-debugger.lisp-patch and tried this:
> 

I talked to Andreas on #lisp, and it was a problem with tabs and spaces. 
It is fixed now, and the new version is uploaded.

   -- Peter


From strandh at labri.fr  Fri Apr 15 08:19:44 2005
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 15 Apr 2005 10:19:44 +0200
Subject: [mcclim-devel] clim-debugger
In-Reply-To: <425F74AF.7050104@daimi.au.dk>
References: <425EAB1D.5020107@daimi.au.dk> <87ekddov8x.wl%asf@boinkor.net>
	<425F6570.1020905@daimi.au.dk> <425F74AF.7050104@daimi.au.dk>
Message-ID: <16991.31008.959614.570230@serveur5.labri.fr>

Peter Mechlenborg writes:
 > > 
 > > I think I do, but I've never really used patch and I can't make it work 
 > > (perhaps I'm a bit dense). I've copied the patch you provided to a file 
 > > named clim-debugger.lisp-patch and tried this:
 > > 
 > 
 > I talked to Andreas on #lisp, and it was a problem with tabs and spaces. 
 > It is fixed now, and the new version is uploaded.

I suggest you put it in Apps/Debugger in the McCLIM hierarchy, or ask
Andreas to do so if you do not have commit privileges. 


-- 
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 metch at daimi.au.dk  Fri Apr 15 08:35:52 2005
From: metch at daimi.au.dk (Peter Mechlenborg)
Date: Fri, 15 Apr 2005 10:35:52 +0200
Subject: [mcclim-devel] clim-debugger
In-Reply-To: <16991.31008.959614.570230@serveur5.labri.fr>
References: <425EAB1D.5020107@daimi.au.dk>	<87ekddov8x.wl%asf@boinkor.net>	<425F6570.1020905@daimi.au.dk>	<425F74AF.7050104@daimi.au.dk>
	<16991.31008.959614.570230@serveur5.labri.fr>
Message-ID: <425F7CE8.5040704@daimi.au.dk>

Robert Strandh wrote:
> I suggest you put it in Apps/Debugger in the McCLIM hierarchy, or ask
> Andreas to do so if you do not have commit privileges. 
> 

I was thinking about that too. I don't have commit privileges, so if 
someone could do it for me that'll be great. I could also do it myself, 
if I was given the privileges, but that is up to you guys.

   -- Peter


From csr21 at cam.ac.uk  Fri Apr 15 19:05:20 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Fri, 15 Apr 2005 20:05:20 +0100
Subject: [mcclim-devel] clim-debugger
In-Reply-To: <425F7CE8.5040704@daimi.au.dk> (Peter Mechlenborg's message of
	"Fri, 15 Apr 2005 10:35:52 +0200")
References: <425EAB1D.5020107@daimi.au.dk> <87ekddov8x.wl%asf@boinkor.net>
	<425F6570.1020905@daimi.au.dk> <425F74AF.7050104@daimi.au.dk>
	<16991.31008.959614.570230@serveur5.labri.fr>
	<425F7CE8.5040704@daimi.au.dk>
Message-ID: <sqk6n3lv2n.fsf@cam.ac.uk>

Peter Mechlenborg <metch at daimi.au.dk> writes:

> Robert Strandh wrote:
>> I suggest you put it in Apps/Debugger in the McCLIM hierarchy, or ask
>> Andreas to do so if you do not have commit privileges.
>
> I was thinking about that too. I don't have commit privileges, so if
> someone could do it for me that'll be great. I could also do it
> myself, if I was given the privileges, but that is up to you guys.

Does anyone have anything against giving Peter write access?  Is there
an advantage in this case to going through someone else?

Cheers,

Christophe


From strandh at labri.fr  Fri Apr 15 21:57:48 2005
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 15 Apr 2005 23:57:48 +0200
Subject: [mcclim-devel] clim-debugger
In-Reply-To: <sqk6n3lv2n.fsf@cam.ac.uk>
References: <425EAB1D.5020107@daimi.au.dk> <87ekddov8x.wl%asf@boinkor.net>
	<425F6570.1020905@daimi.au.dk> <425F74AF.7050104@daimi.au.dk>
	<16991.31008.959614.570230@serveur5.labri.fr>
	<425F7CE8.5040704@daimi.au.dk> <sqk6n3lv2n.fsf@cam.ac.uk>
Message-ID: <16992.14556.591518.253637@serveur5.labri.fr>

Christophe Rhodes writes:
 > Peter Mechlenborg <metch at daimi.au.dk> writes:
 > 
 > > Robert Strandh wrote:
 > >> I suggest you put it in Apps/Debugger in the McCLIM hierarchy, or ask
 > >> Andreas to do so if you do not have commit privileges.
 > >
 > > I was thinking about that too. I don't have commit privileges, so if
 > > someone could do it for me that'll be great. I could also do it
 > > myself, if I was given the privileges, but that is up to you guys.
 > 
 > Does anyone have anything against giving Peter write access?  Is there
 > an advantage in this case to going through someone else?

I certainly have nothing against that.  Perhaps giving him write
access would encourage him to take more time off to contribute :-)

-- 
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 randomtalk at gmail.com  Sat Apr 16 20:20:52 2005
From: randomtalk at gmail.com (Jason Wang)
Date: Sat, 16 Apr 2005 16:20:52 -0400
Subject: [mcclim-devel] error on modifying example code
Message-ID: <939cf2005041613205477e130@mail.gmail.com>

hi, i just got McClim and see how it works.. and got my first attempt
in modifying the example code(s) in trying to get a feel how
everything works.. though, what seem to be a simple layout edition
turned out crashing my program upon start up (note, the example
program calculator is working fine before modification).. i modified
the following code snippet:
(:layouts
   (default
       (with-slots (text-field) *application-frame*
         (vertically (:width 150 :max-width 500)
           (setf text-field screen)
           (horizontally (:height 50) ac ce)
           (tabling (:grid t)
             (list one two three four)
             (list five six seven eight)
             (list nine zero plus dash)
             (list multiply divide result))))))
  (:top-level (calculator-frame-top-level . nil)))

the fifth last line to second last line would be the lines of
interest.. i just modified some layout component (or i thought to be),
and it gave me the following error:
There is no applicable method for the generic function
  #<STANDARD-GENERIC-FUNCTION CLIM:MOVE-SHEET (2)>
when called with arguments
  (NIL 69 99).
   [Condition of type SIMPLE-ERROR]

Backtrace:
  0: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable
argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION
CLIM:MOVE-SHEET (2)> (NIL 69 99))
  1: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable
argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION
CLIM:MOVE-SHEET (2)> (NIL 69 99))
  2: ((SB-PCL::FAST-METHOD CLIM:ALLOCATE-SPACE (CLIM:GRID-PANE T T))
(#(NIL 37) . #()) #<unavailable argument> #<CLIM:GRID-PANE "(Unnamed
Pane)" {9D40E49}> 92 132)
  3: ((SB-PCL::FAST-METHOD
CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE
(CLIM-INTERNALS::BOX-LAYOUT-MIXIN T T)) (#(NIL 32) . #())
#<unavailable argument> #<CLIM:VRACK-PANE "(Unnamed Pane)" {9D49159}>
92 186)
  4: ((SB-PCL::FAST-METHOD
CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE
(CLIM-INTERNALS::BOX-LAYOUT-MIXIN T T)) (#(NIL 32) . #())
#<unavailable argument> #<CLIM:VRACK-PANE "(Unnamed Pane)" {9D50D69}>
92 190)
  5: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL.
SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) #<unavailable argument>
#<unavailable argument> #<CLIM-INTERNALS::TOP-LEVEL-SHEET-PANE
CLIM-INTERNALS::TOP-LEVEL-SHEET {A305B91}> 92 190)
  6: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL.
SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable
argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}>
#<CLIM-DEMO::CALCULATOR {A35C971}>)
  7: ((SB-PCL::FAST-METHOD CLIM:ADOPT-FRAME (CLIM:FRAME-MANAGER
CLIM:APPLICATION-FRAME)) (#(NIL 1 15 12) . #()) #<unavailable
argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}>
#<CLIM-DEMO::CALCULATOR {A35C971}>)
  8: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL.
SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable
argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}>
#<CLIM-DEMO::CALCULATOR {A35C971}>)
  9: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND
(CLIM:APPLICATION-FRAME)) #<unavailable argument>
#S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD
CLIM:RUN-FRAME-TOP-LEVEL #)> :PV-CELL NIL :NEXT-METHOD-CALL NIL
:ARG-INFO (1 . T)) #<CLIM-DEMO::CALCULATOR {A35C971}> NIL)
 10: (CLIM-DEMO::CALCULATOR)
 11: (SB-INT:EVAL-IN-LEXENV (CLIM-DEMO::CALCULATOR) #<NULL-LEXENV>)
 12: (SWANK::EVAL-REGION "(clim-demo::calculator)
" T)
 13: ((LAMBDA NIL))
 14: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T))
#<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL)
{A35C0B5}>)
 15: (SWANK:LISTENER-EVAL "(clim-demo::calculator)
")
 16: (SB-INT:EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(clim-demo::calculator)
") #<NULL-LEXENV>)
 17: ((LAMBDA NIL))
 18: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T
T)) #<unused argument> #<unused argument> #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {A35BF25}>)
 19: ((LAMBDA NIL))
 20: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {A4ACDA1}>
#<FUNCTION (LAMBDA NIL) {B45C885}>)
 21: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {A4ACDA1}>)
 22: ((LAMBDA NIL))
 23: ((LAMBDA NIL))
 24: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {A4ACDA1}>
#<CLOSURE (LAMBDA NIL) {9070075}>)
 25: (SWANK::REPL-LOOP #<SWANK::CONNECTION {A4ACDA1}>)
 26: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA NIL) {9070055}>)
 27: ((LAMBDA NIL))
 28: ("foreign function: call_into_lisp")
 29: ("foreign function: funcall0")

anyone know what's wrong? thanks alot :D
-- 
www.programer.name - my own personal blog : )


From rpgoldman at real-time.com  Mon Apr 18 17:24:43 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Mon, 18 Apr 2005 12:24:43 -0500
Subject: [mcclim-devel] mcclim.asd patch for Allegro CL
Message-ID: <16995.60763.608090.418755@gargle.gargle.HOWL>


Here's a patch that causes Allegro (or at least my beloved,
increasingly aged ACL 6.2), to load CLX while loading MCCLIM.

Per Christophe's instructions on #lisp, consider this to be an
official whine to have the patch applied!  :-)

I don't believe that there's any way this could muck things up for
anyone not using ACL, but I am not infallible...

R
--- mcclim.asd  1 Mar 2005 15:46:13 -0000       1.4
+++ mcclim.asd  18 Apr 2005 17:19:18 -0000
@@ -80,6 +80,25 @@ (defsystem :clim-lisp
                       #+clisp     "fix-clisp")))
    (:file "package" :depends-on ("Lisp-Dep"))))

+;;; possibly this should be further refined to funciton properly for
+;;; Allegro on Windows platforms. [2005/04/18:rpg]
+#+allegro
+(defclass requireable-system (asdf:system)
+     ()
+  )
+
+#+allegro
+(defmethod asdf:perform ((op asdf:load-op) (system requireable-system))
+  (require (intern (slot-value system 'asdf::name) "KEYWORD")))
+
+#+allegro
+(defmethod asdf::traverse ((op asdf:load-op) (system requireable-system))
+  (list (cons op system)))
+
+#+allegro
+(defsystem :clx
+    :class requireable-system)
+
 (defsystem :clim-core
     :depends-on (:clim-lisp)
     :components ((:file "decls")
@@ -216,7 +235,7 @@ (defsystem :clim
      ))

 (defsystem :clim-clx
-    :depends-on (:clim #+(or sbcl openmcl ecl) :clx)
+    :depends-on (:clim #+(or sbcl openmcl ecl allegro) :clx)
     :components
     ((:module "Backends/CLX"
               :pathname #.(make-pathname :directory '(:relative "Backends" "CLX"))
@@ -276,7 +295,7 @@ (defsystem :clim-looks
     :depends-on (:clim
                  ;; If we're on an implementation that ships CLX, use
                  ;; it. Same if the user has loaded CLX already.
-                 #+(or sbcl openmcl ecl clx) :clim-clx
+                 #+(or sbcl openmcl ecl clx allegro) :clim-clx
                  #+gl                        :clim-opengl
                  ;; OpenMCL and MCL support the beagle backend (native
                  ;; OS X look&feel on OS X).


From amoroso at mclink.it  Tue Apr 19 16:07:11 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 19 Apr 2005 18:07:11 +0200
Subject: [mcclim-devel] How to change color of a text field
Message-ID: <87hdi2zr68.fsf@plato.moon.paoloamoroso.it>

How can I change the color of the text displayed in a text field?
Does the CLIM specification allow this?


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


From pw at snoopy.mv.com  Tue Apr 19 18:56:05 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Tue, 19 Apr 2005 14:56:05 -0400
Subject: [mcclim-devel] How to change color of a text field
References: <87hdi2zr68.fsf@plato.moon.paoloamoroso.it>
Message-ID: <000701c54511$72f274e0$0201a8c0@moby>



| How can I change the color of the text displayed in a text field?
| Does the CLIM specification allow this?

(make-pane 'text-field :foreground +red+ ....)

Paul




From amoroso at mclink.it  Tue Apr 19 19:10:38 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 19 Apr 2005 21:10:38 +0200
Subject: [mcclim-devel] How to change color of a text field
References: <87hdi2zr68.fsf@plato.moon.paoloamoroso.it>
	<000701c54511$72f274e0$0201a8c0@moby>
Message-ID: <87r7h6bn0x.fsf@plato.moon.paoloamoroso.it>

"Paul Werkowski" <pw at snoopy.mv.com> writes:

> | How can I change the color of the text displayed in a text field?
> | Does the CLIM specification allow this?
>
> (make-pane 'text-field :foreground +red+ ....)

Thanks, but I forgot to mention that I would like to dynamically
change the text color at runtime.

Andy suggested the use of pane-foreground.  But since there is no setf
method for pane-foreground, I tried with medium-ink/medium-foreground,
and a total redisplay with redisplay-frame-pane called on the gadget
and :force-p t.  This does not work.


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


From ahefner at gmail.com  Tue Apr 19 19:17:31 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Tue, 19 Apr 2005 15:17:31 -0400
Subject: [mcclim-devel] How to change color of a text field
In-Reply-To: <87r7h6bn0x.fsf@plato.moon.paoloamoroso.it>
References: <87hdi2zr68.fsf@plato.moon.paoloamoroso.it>
	<000701c54511$72f274e0$0201a8c0@moby>
	<87r7h6bn0x.fsf@plato.moon.paoloamoroso.it>
Message-ID: <31ffd3c40504191217ec422d@mail.gmail.com>

Try repaint-sheet rather than redisplay-frame-pane.

On 4/19/05, Paolo Amoroso <amoroso at mclink.it> wrote:
> 
> "Paul Werkowski" <pw at snoopy.mv.com> writes:
> 
> > | How can I change the color of the text displayed in a text field?
> > | Does the CLIM specification allow this?
> >
> > (make-pane 'text-field :foreground +red+ ....)
> 
> Thanks, but I forgot to mention that I would like to dynamically
> change the text color at runtime.
> 
> Andy suggested the use of pane-foreground. But since there is no setf
> method for pane-foreground, I tried with medium-ink/medium-foreground,
> and a total redisplay with redisplay-frame-pane called on the gadget
> and :force-p t. This does not work.
> 
> 
> Paolo
> --
> Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050419/1f048a67/attachment.html>

From amoroso at mclink.it  Wed Apr 20 09:50:42 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 20 Apr 2005 11:50:42 +0200
Subject: [mcclim-devel] How to change color of a text field
In-Reply-To: <31ffd3c40504191217ec422d@mail.gmail.com> (Andy Hefner's
	message of "Tue, 19 Apr 2005 15:17:31 -0400")
References: <87hdi2zr68.fsf@plato.moon.paoloamoroso.it>
	<000701c54511$72f274e0$0201a8c0@moby>
	<87r7h6bn0x.fsf@plato.moon.paoloamoroso.it>
	<31ffd3c40504191217ec422d@mail.gmail.com>
Message-ID: <87mzrtu68d.fsf@plato.moon.paoloamoroso.it>

Andy Hefner <ahefner at gmail.com> writes:

> Try repaint-sheet rather than redisplay-frame-pane.

I use code like this:

  (let ((gadget (find-pane-named *application-frame* 'my-text-field)))
    (setf (medium-foreground gadget) +blue+)
    (repaint-sheet gadget (sheet-region gadget))
    (redisplay-frame-pane *application-frame* gadget :force-p t))

But I still get the default black color.  The closest thing to
changing color I have been able to get, playing with
medium-ink/foreground and sheet-medium, is a blue text cursor.

By the way, I call this code from the text field's activation
callback: is this an issue?


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


From glitch at primula.ntu-kpi.kiev.ua  Wed Apr 20 20:11:06 2005
From: glitch at primula.ntu-kpi.kiev.ua (glitch)
Date: Wed, 20 Apr 2005 23:11:06 +0300
Subject: [mcclim-devel] keymap switching in McCLIM frame
Message-ID: <4266B75A.6040004@primula.ntu-kpi.kiev.ua>

I heard that i probably get help in this mailing list. I have stumbled 
on problem with keymap switching in McCLIM frames.
What i did:

$ clim
* (some-loading)
* (run-frame-top-level 'any-frame)
-> user gesture, that causes setxkbmap
-> no reaction
^C
(ext:quit)
$ clim
* (run-frame-top-level 'any-frame)
-> typing any keys
*trace-output*:
lookup-gesture-command: 0 :|cyrillic-<something>|   - why now?

cmucl19a clx5.2 McCLIM 0.9

Excuse me please for my broken English :(
best regards /glitch


From ahefner at gmail.com  Thu Apr 21 02:43:16 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 20 Apr 2005 22:43:16 -0400
Subject: [mcclim-devel] How to change color of a text field
In-Reply-To: <87hdi2zr68.fsf@plato.moon.paoloamoroso.it>
References: <87hdi2zr68.fsf@plato.moon.paoloamoroso.it>
Message-ID: <31ffd3c405042019433be8f8c1@mail.gmail.com>

I've worked out how to do this, with luck it works for what you're trying to 
do.

Here is an example:



(defun color-text-field (ink)
(let ((pane (find-pane-named *application-frame* 'text-field)))
;; The Goatee screen area keeps track of its own foreground color.
(setf (goatee::foreground-ink (climi::area pane)) ink)
;; The cursor is still drawn in foreground ink of the sheet-medium.
(setf (medium-foreground pane) ink)
;; Now force repaint of the sheet
(repaint-sheet pane (sheet-region pane))))


(defun red-text-field (gadget)
(color-text-field +red+))

(defun green-text-field (gadget)
(color-text-field +green+))

(define-application-frame colored-text-editing ()
()
(:panes
(text-field :text-field)
(red-button :push-button :activate-callback 'red-text-field :label "Redify")
(green-button :push-button :activate-callback 'green-text-field :label 
"Greenicate"))
(:layouts
(default
(vertically ()
text-field
(horizontally ()
red-button
green-button)))))





On 4/19/05, Paolo Amoroso <amoroso at mclink.it> wrote:
> 
> How can I change the color of the text displayed in a text field?
> Does the CLIM specification allow this?
> 
> Paolo
> --
> Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050420/c3deb286/attachment.html>

From ahefner at gmail.com  Thu Apr 21 03:38:24 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 20 Apr 2005 23:38:24 -0400
Subject: [mcclim-devel] Drawing graphs & scaling
In-Reply-To: <loom.20050322T162518-0@post.gmane.org>
References: <loom.20050322T162518-0@post.gmane.org>
Message-ID: <31ffd3c405042020385f437031@mail.gmail.com>

This should be fixed. Let me know if you have any further problems.

On 3/22/05, Thibault Langlois <tl at di.fc.ul.pt> wrote:
> 
> 
> Hello,
> 
> I would like to be able to scale a graph:
> 
> (defmethod plot ((object tree) stream)
> (with-scaling (stream 0.7)
> (draw-graph (list (root-node object))
> #'draw-node-colors
> :stream stream)))
> 
> where draw-graph is directly inspired from an example
> in allegro CLIM manual:
> 
> (defun draw-graph (root-nodes draw-node-function &rest keys)
> (apply #'format-graph-from-roots
> root-nodes
> #'(lambda (node s)
> (multiple-value-bind ()
> (with-output-as-presentation (s node 'node)
> (funcall draw-node-function node s))))
> #'(lambda (n)
> (if (visible-p n)
> (children n)))
> keys))
> and draw-node-colors draws a node using draw-rectangle*.
> 
> The problem is that when the scaling factor is not 1 the nodes are not
> correctly placed (although they are correctly scaled) with respect to 
> arcs.
> 
> Any ideas ?
> 
> Thanks.
> 
> Thibault
> 
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050420/150a7c1e/attachment.html>

From amoroso at mclink.it  Thu Apr 21 13:07:53 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 21 Apr 2005 15:07:53 +0200
Subject: [mcclim-devel] How to change color of a text field
References: <87hdi2zr68.fsf@plato.moon.paoloamoroso.it>
	<31ffd3c405042019433be8f8c1@mail.gmail.com>
Message-ID: <87ll7cnuqe.fsf@plato.moon.paoloamoroso.it>

Andy Hefner <ahefner at gmail.com> writes:

> I've worked out how to do this, with luck it works for what you're trying to 
> do.
>
> Here is an example:
>
>
>
> (defun color-text-field (ink)
[...]

It works fine, thank you very much.


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


From amoroso at mclink.it  Thu Apr 21 13:40:21 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 21 Apr 2005 15:40:21 +0200
Subject: [mcclim-devel] Drawing graphs & scaling
In-Reply-To: <31ffd3c405042020385f437031@mail.gmail.com> (Andy Hefner's
	message of "Wed, 20 Apr 2005 23:38:24 -0400")
References: <loom.20050322T162518-0@post.gmane.org>
	<31ffd3c405042020385f437031@mail.gmail.com>
Message-ID: <87zmvsmenu.fsf@plato.moon.paoloamoroso.it>

Andy Hefner <ahefner at gmail.com> writes:

> This should be fixed. Let me know if you have any further problems.
>
> On 3/22/05, Thibault Langlois <tl at di.fc.ul.pt> wrote:
[...]
>> The problem is that when the scaling factor is not 1 the nodes are not
>> correctly placed (although they are correctly scaled) with respect to 
>> arcs.

This is fixed, and it is *way* cool...


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


From ahefner at gmail.com  Tue Apr 26 03:23:59 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Mon, 25 Apr 2005 23:23:59 -0400
Subject: [mcclim-devel] clim-debugger
In-Reply-To: <16992.14556.591518.253637@serveur5.labri.fr>
References: <425EAB1D.5020107@daimi.au.dk> <87ekddov8x.wl%asf@boinkor.net>
	<425F6570.1020905@daimi.au.dk> <425F74AF.7050104@daimi.au.dk>
	<16991.31008.959614.570230@serveur5.labri.fr>
	<425F7CE8.5040704@daimi.au.dk> <sqk6n3lv2n.fsf@cam.ac.uk>
	<16992.14556.591518.253637@serveur5.labri.fr>
Message-ID: <31ffd3c4050425202348b558fe@mail.gmail.com>

I've checked Peter's debugger into CVS under Apps/Debugger. So, who
has the power to get him write access?

On 4/15/05, Robert Strandh <strandh at labri.fr> wrote:
> Christophe Rhodes writes:
>  > Peter Mechlenborg <metch at daimi.au.dk> writes:
>  >
>  > > Robert Strandh wrote:
>  > >> I suggest you put it in Apps/Debugger in the McCLIM hierarchy, or ask
>  > >> Andreas to do so if you do not have commit privileges.
>  > >
>  > > I was thinking about that too. I don't have commit privileges, so if
>  > > someone could do it for me that'll be great. I could also do it
>  > > myself, if I was given the privileges, but that is up to you guys.
>  >
>  > Does anyone have anything against giving Peter write access?  Is there
>  > an advantage in this case to going through someone else?
> 
> I certainly have nothing against that.  Perhaps giving him write
> access would encourage him to take more time off to contribute :-)
> 
> --
> 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.
> ---------------------------------------------------------------------
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>


From akopa at comcast.net  Tue Apr 26 16:48:45 2005
From: akopa at comcast.net (Matthew D Swank)
Date: Tue, 26 Apr 2005 11:48:45 -0500
Subject: [mcclim-devel] Re: clim-debugger
Message-ID: <426E70ED.20305@comcast.net>

It's not much, but:

;;; -*- Mode: Lisp; Package: COMMON-LISP-USER -*-

;;; ASDF system definition for the clim-debugger.

(asdf:defsystem clim-debugger
    :serial t
    :components
    ((:file "clim-debugger")))

-- 
"You do not really understand something unless you can explain it to your grandmother." ? Albert Einstein.



From glitch at primula.ntu-kpi.kiev.ua  Wed Apr 20 19:00:57 2005
From: glitch at primula.ntu-kpi.kiev.ua (glitch)
Date: Wed, 20 Apr 2005 22:00:57 +0300
Subject: [mcclim-devel] keymap switching in McCLIM frame
Message-ID: <4266A6E9.5000703@primula.ntu-kpi.kiev.ua>

I heard that i probably get help in this mailing list. I have stumbled 
on problem with keymap switching in McCLIM frames.
What i did:

$ clim
* (some-loading)
* (run-frame-top-level 'any-frame)
-> user gesture, that causes setxkbmap
-> no reaction
^C
(ext:quit)
$ clim
* (run-frame-top-level 'any-frame)
-> typing any keys
*trace-output*:
lookup-gesture-command: 0 :|cyrillic-<something>|   - why now?

cmucl19a clx5.2 McCLIM 0.9

Excuse me please for my broken English :(
best regards /glitch


From tl at di.fc.ul.pt  Fri Apr 22 14:12:24 2005
From: tl at di.fc.ul.pt (Thibault Langlois)
Date: Fri, 22 Apr 2005 15:12:24 +0100
Subject: [mcclim-devel] Drawing graphs & scaling
In-Reply-To: <31ffd3c405042020385f437031@mail.gmail.com>
References: <loom.20050322T162518-0@post.gmane.org>
	<31ffd3c405042020385f437031@mail.gmail.com>
Message-ID: <1114179144.17389.7.camel@wok>

On Wed, 2005-04-20 at 23:38 -0400, Andy Hefner wrote:
> This should be fixed. Let me know if you have any further problems.
> 

It is fixed ! Thanks a lot.
Here is a screenshot:
http://www.di.fc.ul.pt/~tl/clim-scaled-graphs.png

Thibault

> On 3/22/05, Thibault Langlois <tl at di.fc.ul.pt > wrote:
>         
>         Hello,
>         
>         I would like to be able to scale a graph:
>         
>         (defmethod plot ((object tree) stream) 
>           (with-scaling (stream 0.7)
>             (draw-graph (list (root-node object))
>                         #'draw-node-colors
>                         :stream stream)))
>         
>         where draw-graph is directly inspired from an example
>         in allegro CLIM manual: 
>         
>         (defun draw-graph (root-nodes draw-node-function &rest keys)
>           (apply #'format-graph-from-roots
>                  root-nodes
>                  #'(lambda (node s)
>                      (multiple-value-bind ()
>                          (with-output-as-presentation (s node 'node)
>                            (funcall draw-node-function node s))))
>                  #'(lambda (n)
>                      (if (visible-p n)
>                          (children n)))
>                  keys))
>         and draw-node-colors draws a node using draw-rectangle*.
>         
>         The problem is that when the scaling factor is not 1 the nodes
>         are not
>         correctly placed (although they are correctly scaled) with
>         respect to arcs.
>         
>         Any ideas ?
>         
>         Thanks.
>         
>         Thibault
>         
>         _______________________________________________ 
>         mcclim-devel mailing list
>         mcclim-devel at common-lisp.net
>         http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel

-- 
Thibault Langlois FCUL / DI
tl at di.fc.ul.pt



From duncan at robotcat.demon.co.uk  Tue Apr 26 22:42:47 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Tue, 26 Apr 2005 23:42:47 +0100
Subject: [mcclim-devel] A couple of Beagle changes
Message-ID: <830A6997-B6A4-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


The following patch (generated with 'cvs diff -u beagle', which I hope 
is correct) should modify Beagle so that the following are 'fixed' 
(i.e. as fixed as they ever get when I do things which is not very ;-)

    + rectangular tiles
    + line dashes
    + patterns (not stencils though)
    + dispatch repaint when mirror transform is set now untransforms the 
mirror region by the mirror transformation to hopefully speed things up 
a little (still veeery slow when the output history is large)

beagle/image.lisp can be removed from Beagle, and the 
lisp-bezier-path.lisp file needs adding.

Thanks,

-Duncan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: beagle.diff
Type: application/octet-stream
Size: 84360 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050426/f6a481c3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lisp-bezier-path.lisp
Type: application/octet-stream
Size: 2362 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050426/f6a481c3/attachment-0001.obj>
-------------- next part --------------

  
   

From rpgoldman at real-time.com  Wed Apr 27 02:47:14 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Tue, 26 Apr 2005 21:47:14 -0500
Subject: [mcclim-devel] possible buglet in highlighting shapes
Message-ID: <17006.64818.608786.797221@gargle.gargle.HOWL>


I have built a grapher-based tool, that allows me to distinguish
between multiple types of node by using shapes.  When I highlight
rectangular nodes, all is well.  But I have "roundtangle" nodes, and
when I pass the mouse over them, instead of seeing a box around them,
or a highlight outline around the roundtangle, McCLIM gives me THREE
rectangles, one around the body of the node, and one each around the
semi-circles on the end.

Actually, even the rectangle highlighting seems to me a little odd,
since the highlight outline is drawn INSIDE the node, instead of
around its outline.

Here's the code that draws the nodes:

(defun draw-taems-node (object stream)
  (declare (special normal-ink text-style))
  (with-drawing-options (stream :ink normal-ink
				:text-style text-style)
    (with-output-as-presentation (stream object 'taems-node)
      (if (typep object 'taems:tmethod)
	  (surrounding-output-with-border
	      (stream :shape :rectangle)
	    (format stream "~D: ~A"
		    (musliner:name object)
		    (taems:taems-name object)))
	(surrounding-output-with-border
	    (stream :shape :oval)
	  (format stream "~D: ~A"
		  (musliner:name object)
		  (taems:taems-name object)))))))

Alas, I am too stupid to figure out how to grab a screendump from X to
illustrate this; any suggestions?  I wasn't sure how to get xwd to
wait until I had a node highlighted before writing its output....

Thanks,
R


From amoroso at mclink.it  Wed Apr 27 08:55:34 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 27 Apr 2005 10:55:34 +0200
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <17006.64818.608786.797221@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Tue, 26 Apr 2005 21:47:14 -0500")
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
Message-ID: <87k6mooayh.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> Alas, I am too stupid to figure out how to grab a screendump from X to
> illustrate this; any suggestions?  I wasn't sure how to get xwd to

If you use KDE, you may try with `ksnapshot'.  Gnome probably has a
similar tool.


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


From amoroso at mclink.it  Wed Apr 27 09:14:18 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 27 Apr 2005 11:14:18 +0200
Subject: [mcclim-devel] possible buglet in highlighting shapes
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
Message-ID: <87wtqomvit.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> I have built a grapher-based tool, that allows me to distinguish
> between multiple types of node by using shapes.  When I highlight
> rectangular nodes, all is well.  But I have "roundtangle" nodes, and
> when I pass the mouse over them, instead of seeing a box around them,
> or a highlight outline around the roundtangle, McCLIM gives me THREE
> rectangles, one around the body of the node, and one each around the
> semi-circles on the end.
[...]
>     (with-output-as-presentation (stream object 'taems-node)

You may try playing with the :single-box argument of
with-output-as-presentation.


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


From spambait at CloudDancer.com  Wed Apr 27 09:06:04 2005
From: spambait at CloudDancer.com (GP lisper)
Date: Wed, 27 Apr 2005 02:06:04 -0700
Subject: [mcclim-devel] Re: possible buglet in highlighting shapes
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
Message-ID: <slrnd6ulfs.26r.spambait@phoenix.clouddancer.com>

On Tue, 26 Apr 2005 21:47:14 -0500, <rpgoldman at real-time.com> wrote:
>
> Alas, I am too stupid to figure out how to grab a screendump from X to
> illustrate this; any suggestions?

xvidcap --frames 1 --cap_geometry 1280x1024+0+0 --gui no --file bug.png


-- 
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.



From duncan at robotcat.demon.co.uk  Wed Apr 27 07:15:20 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Wed, 27 Apr 2005 08:15:20 +0100
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <17006.64818.608786.797221@gargle.gargle.HOWL>
Message-ID: <1D1DB9C2-B6EC-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


I suspect changing the line '(with-output-as-presentation (stream 
object 'taems-node)' to add ':single-box t' should fix this: 
'(with-output-as-presentation (stream object 'taems-node :single-box t)'

See ?23.2.1, specifically 'presentation-single-box' in the spec.

Can't help with screen grabbing, sorry.

-Duncan


On Wednesday, April 27, 2005, at 03:47 AM, rpgoldman at real-time.com 
wrote:

>
> I have built a grapher-based tool, that allows me to distinguish
> between multiple types of node by using shapes.  When I highlight
> rectangular nodes, all is well.  But I have "roundtangle" nodes, and
> when I pass the mouse over them, instead of seeing a box around them,
> or a highlight outline around the roundtangle, McCLIM gives me THREE
> rectangles, one around the body of the node, and one each around the
> semi-circles on the end.
>
> Actually, even the rectangle highlighting seems to me a little odd,
> since the highlight outline is drawn INSIDE the node, instead of
> around its outline.
>
> Here's the code that draws the nodes:
>
> (defun draw-taems-node (object stream)
>   (declare (special normal-ink text-style))
>   (with-drawing-options (stream :ink normal-ink
> 				:text-style text-style)
>     (with-output-as-presentation (stream object 'taems-node)
>       (if (typep object 'taems:tmethod)
> 	  (surrounding-output-with-border
> 	      (stream :shape :rectangle)
> 	    (format stream "~D: ~A"
> 		    (musliner:name object)
> 		    (taems:taems-name object)))
> 	(surrounding-output-with-border
> 	    (stream :shape :oval)
> 	  (format stream "~D: ~A"
> 		  (musliner:name object)
> 		  (taems:taems-name object)))))))
>
> Alas, I am too stupid to figure out how to grab a screendump from X to
> illustrate this; any suggestions?  I wasn't sure how to get xwd to
> wait until I had a node highlighted before writing its output....
>
> Thanks,
> R
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From pw at snoopy.mv.com  Wed Apr 27 11:20:58 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Wed, 27 Apr 2005 07:20:58 -0400
Subject: [mcclim-devel] possible buglet in highlighting shapes
Message-ID: <20050427112058.7668.qmail@copper.mv.net>

> I have built a grapher-based tool, that allows me to distinguish
> between multiple types of node by using shapes.  When I highlight
> rectangular nodes, all is well.  But I have "roundtangle" nodes, and
> when I pass the mouse over them, instead of seeing a box around them,
> or a highlight outline around the roundtangle, McCLIM gives me THREE
> rectangles, one around the body of the node, and one each around the
> semi-circles on the end.

You probably want to use :single-box T in with-output-as-presentation.


Paul



From rpgoldman at real-time.com  Wed Apr 27 14:39:07 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Wed, 27 Apr 2005 09:39:07 -0500
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <87wtqomvit.fsf@plato.moon.paoloamoroso.it>
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
Message-ID: <17007.41995.725215.885595@gargle.gargle.HOWL>


My thanks to all of you who pointed me at the :single-box argument for
with-output-as-presentation.  And an extra thank-you to Paolo for the
ksnapshot pointer.

A quick question, though, and this is not intended as a flame ---
is this problem a manifestation of some issues with programming
(Mc)CLIM?

My impression is that there are two challenges to programming with
McCLIM:

1.  The paradigm is radically different from any other interface
    coding framework.

    This certainly isn't a killer for me, because I happily used
    Garnet for many years (and if I understood X well enough to
    modernize its back-end, I would probably go back to it today).

2.  There seems to be an awful lot of black art to getting a CLIM UI
    to look right and behave in ways that users will perceive as
    normal.

    I don't have a good read on how much this is because McCLIM is
    still evolving, and how much this is because of the nature of the
    CLIM beast.  Do we need better defaults to make things happen more
    naturally?  How feasible would that be if we want to comply with
    the CLIM spec?  Or should we provide macrology to wrap things up
    more easily for new CLIM programmers?  I'm still fumbling around
    myself, so I find it hard to say what would make things easier,
    since I might just be doing things wrong.

Best,
R


From amoroso at mclink.it  Wed Apr 27 19:17:41 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 27 Apr 2005 21:17:41 +0200
Subject: [mcclim-devel] possible buglet in highlighting shapes
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
Message-ID: <877jiot4fe.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> is this problem a manifestation of some issues with programming
> (Mc)CLIM?

CLIM does require a lot of study.  I frequently browse and re-read the
printed copy of the CLIM manual I keep on my shelves.  I also print
and study all the CLIM code I can get my hands on (a rich source--no
pun intended--of aha! moments).

In the case of the particular problem you mentioned, I immediately
recognized a :single-box issue, but didn't exactly remember the
argument name and the details.  After telling you about ksnapshot, it
took me a few minutes to check the manual and find the relevant
information.


> My impression is that there are two challenges to programming with
> McCLIM:
[...]
> 2.  There seems to be an awful lot of black art to getting a CLIM UI
>     to look right and behave in ways that users will perceive as
>     normal.

Can you provide a few examples?


>     more easily for new CLIM programmers?  I'm still fumbling around
>     myself, so I find it hard to say what would make things easier,
>     since I might just be doing things wrong.

Keep asking questions.  I personally try to answer all the CLIM
questions posted here and in other Lisp forums--well, I am not always
successful :)


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


From duncan at robotcat.demon.co.uk  Wed Apr 27 23:02:38 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Thu, 28 Apr 2005 00:02:38 +0100
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <17007.41995.725215.885595@gargle.gargle.HOWL>
Message-ID: <7392F606-B770-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


I've been working with McCLIM on and off for 18 months or so now I 
guess... mainly back end related stuff, but more recently I've started 
looking at actually building apps. I'll offer my opinions in the 
following...

On Wednesday, April 27, 2005, at 03:39 PM, rpgoldman at real-time.com 
wrote:

>
> My thanks to all of you who pointed me at the :single-box argument for
> with-output-as-presentation.  And an extra thank-you to Paolo for the
> ksnapshot pointer.
>
> A quick question, though, and this is not intended as a flame ---
> is this problem a manifestation of some issues with programming
> (Mc)CLIM?
>
> My impression is that there are two challenges to programming with
> McCLIM:
>
> 1.  The paradigm is radically different from any other interface
>     coding framework.
>

I'd agree with this to a certain extent; I've observed many 
similarities between CLIM and the Cocoa APIs from Apple in the 
windowing substrate (UI is based around NSViews (sheets) which can be 
scaled and rotated arbitrarily using affine transforms, whose coords 
are transformed into the coords of its parent; patterns can be used as 
inks (rectangular-tile); events are passed to NSViews as required, the 
NSView handles the event (or passes it on) which is similar to the 
event handling in CLIM, + other stuff).

Of course, that could be the 'easy' bit in CLIM. I haven't seem 
presentations etc. anywhere else and haven't grokked them properly yet, 
so that's pretty different.

For other GUI toolkits I've used, I'd agree the difference is radical.

I'm hoping that practice will make things easier.

>     This certainly isn't a killer for me, because I happily used
>     Garnet for many years (and if I understood X well enough to
>     modernize its back-end, I would probably go back to it today).
>
> 2.  There seems to be an awful lot of black art to getting a CLIM UI
>     to look right and behave in ways that users will perceive as
>     normal.
>

I'd agree with this too; I initially wanted to port DEUCE to CL when I 
started looking at McCLIM. Then I got a Mac, and decided to work on a 
back end instead. My plan was to implement a slow-but-correct 
Cocoa-based back end for McCLIM. I'm half-way there now (I have 
something that's slow) but getting the correct part is the trick. I've 
read certain sections of the spec repeatedly ('geometry substrate', 
'windowing substrate', parts of 'building applications' mainly), and 
inspected the McCLIM code in detail too in these areas and I still have 
no idea what the 'correct' behaviour is in many cases.

Some things seem not to work properly, but it's hard to be sure because 
the spec is vague (for example, how do you create a sheet whose 
orientation is :graphics rather than :default, and whose coords are 1 
unit = 1 inch? Sure, I can manually provide a transform to do this, but 
shouldn't picking a graft with these properties make this happen out of 
the box? Maybe it does, I don't know, because there doesn't seem to be 
a way to specify the graft options anywhere (without using 'find 
graft') - my expectation was (and sort of still is) that this should be 
able to be specified as part of the 'define application frame' 
functionality (i.e. done at a high level rather than a low level in 
application code). Assuming it can only be done at a low level, how 
does the application developer change the graft? Create all the sheets, 
find a new graft with the (non-default) options, degraft and then 
regraft the hierarchy on the new graft? Not use 
'define-application-frame'? The spec discusses graft options, but it's 
not clear if that's just for completeness (e.g. 'here's how CLIM on 
Genera works') or whether the facilities are actually supposed to be 
used. There's even a comment in the spec about "I'm not sure how much 
of this [graft functionality] is obsolete".

Also things like specifying an :application pane type in the :panes  of 
an application frame, passing ':scroll-bars t' but not having the pane 
become scrollable when output is drawn that doesn't fit on the mirror 
region. I'm not sure if this is user error or implementation error.

>     I don't have a good read on how much this is because McCLIM is
>     still evolving, and how much this is because of the nature of the
>     CLIM beast.

I think from my point of view it's 25:75. McCLIM is still evolving, and 
there are some obvious areas reading the code that are 'wrong' (in 
quotation marks because it's not actually obvious at all whether it's 
wrong or not. I'm thinking specifically about 'update-mirror-geometry' 
where comments in the code lead me to believe compromises are made 
because of 'X limitations').

(And should the native transformation of a graft be 
+identity-transformation+ (suspect it should depend on units & 
orientation)? Should the native region of a graft be +everywhere+? 
These seem to be reasonable assumptions, the spec is silent, so how to 
decide?).

Most of this (IMHO) is definitely down to vagueness in the spec (for 
another example, according to the LispWorks CLIM user guide, a 
platform-specific fontspec can be used as a text-style (e.g. an X 
fontspec), and this is intimated at in the spec too, but it's not made 
clear). I have no idea if McCLIM supports this though (I think: no). 
And then there's the 'design protocol' (section 14.7). Hrm. (+ see 
above on grafts).

>   Do we need better defaults to make things happen more
>     naturally?  How feasible would that be if we want to comply with
>     the CLIM spec?

I think the defaults used in the code correspond to those outlined in 
the spec. The LispM had a natty tool (well - Explorers had one) called 
'profile' that allowed settings to be changed easily by the user. I 
dare say one day somebody will write one for McCLIM (it doesn't 
actually look like it would be too hard to me). Then we would have the 
best of both worlds; defaults in the code that corresponded to the 
spec, but that were easily modified by the user.

>   Or should we provide macrology to wrap things up
>     more easily for new CLIM programmers?  I'm still fumbling around
>     myself, so I find it hard to say what would make things easier,
>     since I might just be doing things wrong.

I think some tools would help here - particularly a UI builder 
(presumably that has some support for defining presentations and 
commands). I feel that in the future (as tools are developed) things 
will be better (for the application developer) than they are currently 
(although I also think that just implementing as much of the spec as 
has been implemented already is quite an outstanding achievement).

-Duncan


>
> Best,
> R
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From tl at di.fc.ul.pt  Wed Apr 27 23:02:18 2005
From: tl at di.fc.ul.pt (Thibault Langlois)
Date: Thu, 28 Apr 2005 00:02:18 +0100
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <877jiot4fe.fsf@plato.moon.paoloamoroso.it>
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
Message-ID: <1114642938.6637.75.camel@wok>

On Wed, 2005-04-27 at 21:17 +0200, Paolo Amoroso wrote:
> rpgoldman at real-time.com writes:
> 
> > is this problem a manifestation of some issues with programming
> > (Mc)CLIM?
> 
> CLIM does require a lot of study.  I frequently browse and re-read the
> printed copy of the CLIM manual I keep on my shelves.  I also print
> and study all the CLIM code I can get my hands on (a rich source--no
> pun intended--of aha! moments).
> 

I'm slowly learning CLIM and I usually check LW CLIM manual. I recently
printed the Allegro CLIM manual and although they are both based on the
spec, Allegro CLIM manual tend to have more examples. There always have
been people kind enough to show me a way to solve the problems I had
(both on this list and on #lisp). 
Before asking I usually grep through the CLIM code I found to see how
some feature is used. 

The last (unsolved :-) problem is related to keystrokes when I define a
command with the define-frame-command macro.

I tried to do as described in the allegro CLIM manual:

(define-test-commands-1-command (com-quit :name t
                                          :keystroke (:q :control))
 ()
 (frame-exit *application-frame*))

but C-q in the interactor does nothing.

The LW CLIM manual gives a different syntax for keystrokes that is not
readable with cmucl/McCLIM: :keystroke #\c-\q

I tried to define a gesture:
(define-gesture-name :quit :keyboard (#\q :control))

(define-test-commands-1-command
    (com-quit :name t
              :keystroke :quit)
   ()
 (frame-exit *application-frame*))

I have seen examples like this one and I think it should work but it
does not (C-q does nothing).

It would be usefull to have a place were to keep these hints. I am not
sure McCLIM cliki is the right place. The anotable version of the specs
could be a convenient place to put such hints (because one would be able
to read the doc and see other users' advices) but the anotations I have
seen are mostly about the standard, not very useful for a user with
little experience. 

Thibault

> In the case of the particular problem you mentioned, I immediately
> recognized a :single-box issue, but didn't exactly remember the
> argument name and the details.  After telling you about ksnapshot, it
> took me a few minutes to check the manual and find the relevant
> information.
> 
> 
> > My impression is that there are two challenges to programming with
> > McCLIM:
> [...]
> > 2.  There seems to be an awful lot of black art to getting a CLIM UI
> >     to look right and behave in ways that users will perceive as
> >     normal.
> 
> Can you provide a few examples?
> 
> 
> >     more easily for new CLIM programmers?  I'm still fumbling around
> >     myself, so I find it hard to say what would make things easier,
> >     since I might just be doing things wrong.
> 
> Keep asking questions.  I personally try to answer all the CLIM
> questions posted here and in other Lisp forums--well, I am not always
> successful :)
> 
> 
> Paolo
-- 
Thibault Langlois <tl at di.fc.ul.pt>
FCUL / DI



From ahefner at gmail.com  Wed Apr 27 23:36:07 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 27 Apr 2005 19:36:07 -0400
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <7392F606-B770-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
References: <17007.41995.725215.885595@gargle.gargle.HOWL>
	<7392F606-B770-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <31ffd3c405042716365d74339a@mail.gmail.com>

On 4/27/05, Duncan Rose <duncan at robotcat.demon.co.uk> wrote:

> Also things like specifying an :application pane type in the :panes  of
> an application frame, passing ':scroll-bars t' but not having the pane

<grumble>
Can you find where in the spec this is required? I think this keyword
is fictional, and I'm astonished at the number of people trying to use
it. Maybe it is a vendor extension, but it doesn't make any sense to
me. Scrolling is acheived by embedding the pane in another pane which
provides scroll bars and a viewport. If I expect :scroll-bars t to
work as expected, make-pane would have to return the scroller pane
rather than the the pane I asked it to create (which makes no sense at
all), or there would have to be some magic backdoor whereby adopting
my pane caused a chain of parents to be adopted in its place. I don't
much like that either (if I was modifying the UI dynamically, with a
bunch of gadgets in a container, I'd no longer know which one to
disown when its time came without walking the entire tree of
children).

I have heard this complaint so often now that it is tempting to add a
check which will yell at programmers who expect this to work.
</grumble>


From duncan at robotcat.demon.co.uk  Thu Apr 28 05:11:51 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Thu, 28 Apr 2005 06:11:51 +0100
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <31ffd3c405042716365d74339a@mail.gmail.com>
Message-ID: <07872279-B7A4-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>

Having rapidly checked the spec...

On Thursday, April 28, 2005, at 12:36 AM, Andy Hefner wrote:

> On 4/27/05, Duncan Rose <duncan at robotcat.demon.co.uk> wrote:
>
>> Also things like specifying an :application pane type in the :panes  
>> of
>> an application frame, passing ':scroll-bars t' but not having the pane
>
> <grumble>
> Can you find where in the spec this is required? I think this keyword
> is fictional, and I'm astonished at the number of people trying to use
> it. Maybe it is a vendor extension, but it doesn't make any sense to
> me. Scrolling is acheived by embedding the pane in another pane which

You are right; it's not in the spec. I'm actually quite suprised I 
didn't already know this considering how much time I've spend reading 
the thing ;-)  I'll make an excuse that I haven't read chapter 29 in as 
much detail as some of the others...

Speaking purely personally, when I'm trying to struggle through a 
mysterious coding exercise, and printed docs make less sense than they 
could, I try to find a canonical (existing) application from which to 
copy and go for the 'it works for application XXX, why not me?'. In 
this case there's only one canonical application in my opinion (I 
choose to discount the address book demo). Can you guess which it is?

Here's it's define-application-frame form:

;;; Listener application frame
(define-application-frame listener (standard-application-frame
                                     command-history-mixin)
     ((system-command-reader :accessor system-command-reader
			    :initarg :system-command-reader
			    :initform t))
   (:panes (interactor :interactor :scroll-bars T
                       :display-function 
#'listener-initial-display-function
                       :display-time t)
           (doc :pointer-documentation)
           (wholine (make-pane 'wholine-pane
                      :display-function 'display-wholine :scroll-bars nil
                      :display-time :command-loop :end-of-line-action 
:allow)))
   (:top-level (default-frame-top-level :prompt 'print-listener-prompt))
   (:command-table (listener
                    :inherit-from (application-commands lisp-commands 
filesystem-commands show-commands)
                    :menu (("Application" :menu application-commands)
                           ("Lisp"        :menu lisp-commands)
                           ("Filesystem"  :menu filesystem-commands)
                           ("Show"        :menu show-commands))))
   (:disabled-commands com-pop-directory com-drop-directory 
com-swap-directory)
   (:menu-bar t)
   (:layouts (default
	      (vertically ()
                 interactor
                 doc
                 wholine))))

I suggest if you want to see this option used less often, it should NOT 
be present here. Even if the :scroll-bars is left out, the application 
pane gets a scroll bar drawn in it, which then appears to be unusable. 
Could well be another user error though...

> provides scroll bars and a viewport. If I expect :scroll-bars t to
> work as expected, make-pane would have to return the scroller pane
> rather than the the pane I asked it to create (which makes no sense at
> all), or there would have to be some magic backdoor whereby adopting
> my pane caused a chain of parents to be adopted in its place.

Sort of like the way every frame contains a raised pane with a menu 
pane in it, even if they never get used? I agree, it's annoying ;-)

I've attached a little utility I'm calling 'glimpse' at the moment; 
fire it up ('glimpse:glimpse' after building) and 'show sheet 
hierarchy' (hopefully it will work; it's a quick and nasty hack but 
might grow into more sometime. Perhaps others will find it interesting).


>  I don't
> much like that either (if I was modifying the UI dynamically, with a
> bunch of gadgets in a container, I'd no longer know which one to
> disown when its time came without walking the entire tree of
> children).
>
> I have heard this complaint so often now that it is tempting to add a
> check which will yell at programmers who expect this to work.

Just take the code out of the listener and its use will probably 
disappear.

-Duncan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: glimpse.lisp
Type: application/octet-stream
Size: 6942 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050428/59d76d2d/attachment.obj>
-------------- next part --------------


> </grumble>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>

From ahefner at gmail.com  Thu Apr 28 05:55:56 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 28 Apr 2005 01:55:56 -0400
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <07872279-B7A4-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
References: <31ffd3c405042716365d74339a@mail.gmail.com>
	<07872279-B7A4-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <31ffd3c4050427225542869e5@mail.gmail.com>

Wow, that is very funny.

> You are right; it's not in the spec. I'm actually quite suprised I
> didn't already know this considering how much time I've spend reading
> the thing ;-)  I'll make an excuse that I haven't read chapter 29 in as
> much detail as some of the others...

Gotcha! It actually is in the spec, sort of, in section 29.4.3 as an
argument to make-clim-stream-pane. It is not in the index, which has
caused me to overlook it on several occasions. It appears it exists
only as an argument to make-clim-stream-pane and the derived
functions, and is not an initarg usable in a call to make-pane. I
don't see anywhere in the spec stating that define-application-frame
should be smart enough to use make-clim-stream-pane rather than
make-pane in certain cases, but I'm not looking very hard either.

Keep on hacking..


From ahefner at gmail.com  Thu Apr 28 06:07:09 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 28 Apr 2005 02:07:09 -0400
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <1114642938.6637.75.camel@wok>
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<1114642938.6637.75.camel@wok>
Message-ID: <31ffd3c405042723076cee4866@mail.gmail.com>

I took a brief look at this tonight, and I see that the keystrokes are
indeed not working as expected. I tried a variation on you example
using a single character with no modifier, and that worked fine. I'm
pretty sure this was working not too long ago (my old tests appear to
include a command with :keystroke (#\g :control), and presumably they
all worked). Or, maybe the situation is different in some subtle way
than what I tested.  I guess I'll take a look at what happened over
the weekend..

The #\c-\q syntax is new to me.

On 4/27/05, Thibault Langlois <tl at di.fc.ul.pt> wrote:

> The last (unsolved :-) problem is related to keystrokes when I define a
> command with the define-frame-command macro.
> 
> I tried to do as described in the allegro CLIM manual:
> 
> (define-test-commands-1-command (com-quit :name t
>                                           :keystroke (:q :control))
>  ()
>  (frame-exit *application-frame*))
> 
> but C-q in the interactor does nothing.
> 
> The LW CLIM manual gives a different syntax for keystrokes that is not
> readable with cmucl/McCLIM: :keystroke #\c-\q
> 
> I tried to define a gesture:
> (define-gesture-name :quit :keyboard (#\q :control))
> 
> (define-test-commands-1-command
>     (com-quit :name t
>               :keystroke :quit)
>    ()
>  (frame-exit *application-frame*))
> 
> I have seen examples like this one and I think it should work but it
> does not (C-q does nothing).


From pw at snoopy.mv.com  Thu Apr 28 11:11:01 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Thu, 28 Apr 2005 07:11:01 -0400
Subject: [mcclim-devel] possible buglet in highlighting shapes
References: <17007.41995.725215.885595@gargle.gargle.HOWL><7392F606-B770-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<31ffd3c405042716365d74339a@mail.gmail.com>
Message-ID: <001201c54be2$f8463550$0201a8c0@moby>


----- Original Message ----- 
From: "Andy Hefner" <ahefner at gmail.com>
To: <mcclim-devel at common-lisp.net>
Sent: Wednesday, April 27, 2005 7:36 PM
Subject: Re: [mcclim-devel] possible buglet in highlighting shapes


On 4/27/05, Duncan Rose <duncan at robotcat.demon.co.uk> wrote:

> Also things like specifying an :application pane type in the :panes  of
> an application frame, passing ':scroll-bars t' but not having the pane

<...>

<I have heard this complaint so often now that it is tempting to add a
check which will yell at programmers who expect this to work.

FWIW, This works fine in Lispworks CLIM, in fact, :scrollbars T
is the default.

Paul




From rpgoldman at real-time.com  Thu Apr 28 17:02:35 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 28 Apr 2005 12:02:35 -0500
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <877jiot4fe.fsf@plato.moon.paoloamoroso.it>
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
Message-ID: <17009.5931.275190.675482@gargle.gargle.HOWL>

>>>>> "PA" == Paolo Amoroso <amoroso at mclink.it> writes:

    PA> rpgoldman at real-time.com writes:

    >> My impression is that there are two challenges to programming with
    >> McCLIM:
    PA> [...]
    >> 2.  There seems to be an awful lot of black art to getting a CLIM UI
    >> to look right and behave in ways that users will perceive as
    >> normal.

    PA> Can you provide a few examples?

Sure, but not original ones:  

- one thing that seems odd is the lack of a conventional selection
  concept, which we see in the now-standard direct manipulation
  interfaces.  I.e., you select an object and that provides the focus
  of all commands.  I'm not sure that providing this is even feasible
  with CLIM, because of its radically different paradigm.

- Examples of use of standard gadgets.  E.g., on others' suggestion,
  I've been meaning to get the file selector factored out of climacs
  and put into mcclim, for example.  Alas, my plate is already
  overfull right now, so it will probably be at least a small number
  of weeks before I get to this.

- An easier introduction to providing an application frame with a menu
  bar, since that seems like a central UI paradigm these days.  Note
  that I may simply have missed some good sources.

- Earlier I was having a lot of difficulty telling when McCLIM would
  decide that my input was complete, but I think this was just
  transient accepting-values problems that seem much better...


    >> more easily for new CLIM programmers?  I'm still fumbling around
    >> myself, so I find it hard to say what would make things easier,
    >> since I might just be doing things wrong.

    PA> Keep asking questions.  I personally try to answer all the CLIM
    PA> questions posted here and in other Lisp forums--well, I am not always
    PA> successful :)

At the expense of inviting flames, in my dreams there's some way to
get started with CLIM that's as easy as (or approaches as easy as)
getting started with Tcl/Tk.  With that, in about 10 lines, one can
have a screen with buttons and stuff that happens.  OK, admittedly you
end up with a dead end not too far down the pike, but that's what I
would dream of.  

Somehow it seemed a lot harder to get over that initial hurdle of
defining an application frame, a presentation type, a command, a
and command-translator.  Perhaps if I mull over some more macrology,
that will become clearer.

Maybe when there's a bigger palette of built-in gadgets, and more lore
about how to use them, this will be easier.

As a programmer, relatively familiar with the callback model, I have a
very hard time grappling with the paradigm which seems like:  define a
case where you want to get a particular type of value, define ways of
presenting values, and then magic happens and the values you present
can be pulled back in.

Note that part of this is because I'm lazy, but that's a different way
of saying that developing CLIM UIs isn't a main part of what I need to
do.  I'd like a smoother path from "here's a dead-easy way to do the
simpile thing to more and more complex stuff."

I realize that we're all volunteers here, and I'm not demanding that
this be handed to me on a platter --- to the extent I can help in this
project, I'd be happy to do so.  I just don't see the way yet.

Best,
R


From rpgoldman at real-time.com  Thu Apr 28 17:09:14 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 28 Apr 2005 12:09:14 -0500
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <31ffd3c405042716365d74339a@mail.gmail.com>
References: <17007.41995.725215.885595@gargle.gargle.HOWL>
	<7392F606-B770-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<31ffd3c405042716365d74339a@mail.gmail.com>
Message-ID: <17009.6330.917.129046@gargle.gargle.HOWL>

>>>>> "AH" == Andy Hefner <ahefner at gmail.com> writes:

    AH> On 4/27/05, Duncan Rose <duncan at robotcat.demon.co.uk> wrote:
    >> Also things like specifying an :application pane type in the :panes  of
    >> an application frame, passing ':scroll-bars t' but not having the pane

    AH> <grumble>
    AH> Can you find where in the spec this is required? I think this keyword
    AH> is fictional, and I'm astonished at the number of people trying to use
    AH> it. Maybe it is a vendor extension, but it doesn't make any sense to
    AH> me. Scrolling is acheived by embedding the pane in another pane which
    AH> provides scroll bars and a viewport. If I expect :scroll-bars t to
    AH> work as expected, make-pane would have to return the scroller pane
    AH> rather than the the pane I asked it to create (which makes no sense at
    AH> all), or there would have to be some magic backdoor whereby adopting
    AH> my pane caused a chain of parents to be adopted in its place. I don't
    AH> much like that either (if I was modifying the UI dynamically, with a
    AH> bunch of gadgets in a container, I'd no longer know which one to
    AH> disown when its time came without walking the entire tree of
    AH> children).

    AH> I have heard this complaint so often now that it is tempting to add a
    AH> check which will yell at programmers who expect this to work.
    AH> </grumble>

I have sympathy with both sides of this debate, because it seems like
a clash of intuitions, and they are both right.  And because I
suffered through this with the Garnet toolkit, which had the same
thing with its scrollable windows.

Andy does a great job of explaining why, from an implementation pov,
it would not be great to have :scroll-bars t.  He also explains why
it might hamper developing new interfaces by specialization.

However, the other side is valid, too.  It seems like an entirely
valid intuition that scrollability is an ATTRIBUTE of a window, rather
than a container around the window.  OK, the latter corresponds to
implementation better, but the former corresponds better to the
intuitions of a programmer who is not familiar with the implementation
of his toolkit.  I also think we have plenty of evidence from other
graphics toolkits that this is a reasonable intuition.

Having said that I see both sides of this debate as reasonable, I'm
not sure what the hell to propose.  Most unsatisfactory.

R


From rpgoldman at real-time.com  Thu Apr 28 17:17:15 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 28 Apr 2005 12:17:15 -0500
Subject: [mcclim-devel] Black art
In-Reply-To: <17009.5931.275190.675482@gargle.gargle.HOWL>
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
Message-ID: <17009.6811.306786.30827@gargle.gargle.HOWL>


I think one thing that makes it more confusing for a newcomer to CLIM
is the way many of the manuals are written.  

I have looked at both the LW and the Allegro manuals, and maybe
they're great manuals, but they are terrible to learn from.  

For example, the Franz CLIM UG seems to be written from the bottom-up,
in parallel to the architecture of the software.  It starts with
drawing planes and the screen, and then works up to gadgets.

But if one looks at sources that try to teach a programmer how to do
things, they always start with tasks the programmer might want to
accomplish, and work down into detail.  So a guide to using CLIM
should start with application frames, move to gadgets, etc.

Again, I'm not trying to complain that this isn't in those manuals ---
manuals and tutorials aren't the same.

And I don't want to be seen as a whiner who just wants everything
given to him on a platter.

What I'd like to do is just share some perceptions of what I think
might make things easier for McCLIM users and might make McCLIM more
popular.

Best,
R


From rpgoldman at sift.info  Thu Apr 28 17:23:01 2005
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Thu, 28 Apr 2005 12:23:01 -0500
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <07872279-B7A4-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
References: <31ffd3c405042716365d74339a@mail.gmail.com>
	<07872279-B7A4-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <17009.7157.406984.175502@gargle.gargle.HOWL>


OK, sorry.  But for the stupid, what's the magic to put in
make-application-frame that will give us something that's scrollable?

If there is no easy way to specify a scrollable pane, isn't that a
problem?  

I accept Andy's worry about losing the ability to grab onto the "real"
internal pane, but it still seems that there should be an easy way to
specify scrollable panes w/o having to go beyond the
define-application-frame syntax.  But I'm getting confused, so maybe
I'm missing something.

Thanks,
R




From duncan at robotcat.demon.co.uk  Thu Apr 28 17:40:17 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Thu, 28 Apr 2005 18:40:17 +0100
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <17009.7157.406984.175502@gargle.gargle.HOWL>
Message-ID: <95C28656-B80C-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Thursday, April 28, 2005, at 06:23 PM, Robert P. Goldman wrote:

>
> OK, sorry.  But for the stupid, what's the magic to put in
> make-application-frame that will give us something that's scrollable?
>
> If there is no easy way to specify a scrollable pane, isn't that a
> problem?
>
> I accept Andy's worry about losing the ability to grab onto the "real"
> internal pane, but it still seems that there should be an easy way to
> specify scrollable panes w/o having to go beyond the
> define-application-frame syntax.  But I'm getting confused, so maybe
> I'm missing something.
>
> Thanks,
> R
>
>

I think the consensus is that all CLIM 'windows' (i.e. panes that are in
fact clim-stream-pane types) DO (or at least, should) accept the 
:scroll-bars
keyword in 'define-application-frame' and will default this to some 
sensible
value (dependent of pane type) if not provided.

This *should* mean that no magic is required; just use an :interactor or
:application (or :command-menu, :title, or :pointer-documentation) pane 
and
scrolling should 'just happen' (well - some of these types have a 
default
:scroll-bars of nil and so won't scroll out of the box).

That's my current understanding of the spec. Whether I'm right or not is
a different question ;-)

-Duncan



From ahefner at gmail.com  Thu Apr 28 17:40:44 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 28 Apr 2005 13:40:44 -0400
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <17009.7157.406984.175502@gargle.gargle.HOWL>
References: <31ffd3c405042716365d74339a@mail.gmail.com>
	<07872279-B7A4-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<17009.7157.406984.175502@gargle.gargle.HOWL>
Message-ID: <31ffd3c4050428104051ec0dfe@mail.gmail.com>

On 4/28/05, Robert P. Goldman <rpgoldman at sift.info> wrote:

> OK, sorry.  But for the stupid, what's the magic to put in
> make-application-frame that will give us something that's scrollable?
> 
> If there is no easy way to specify a scrollable pane, isn't that a
> problem?

I think you are missing something. Use the 'scrolling' macro in your
layout, for example:

(define-application-frame ...
  ...
  (:layouts
    (default
      (scrolling () my-pane)))) ;; Is that the sort of macrology
you're looking for?

http://www.mikemac.com/mikemac/clim/panes.html#Macro%20scrolling

As I noted earlier, the :scroll-bars may also work, but only for
stream panes (interactors, application-panes, etc), not necessarily
arbitrary panes (buttons, layout panes, etc), and must require some
magic support in define-application-frame that the spec doesn't appear
to mention. I haven't looked for where this magic must exist in
McCLIM, so I don't know exactly what happens.


From smustudent1 at yahoo.com  Thu Apr 28 17:53:05 2005
From: smustudent1 at yahoo.com (C Y)
Date: Thu, 28 Apr 2005 10:53:05 -0700 (PDT)
Subject: [mcclim-devel] Black art
In-Reply-To: 6667
Message-ID: <20050428175306.39622.qmail@web31706.mail.mud.yahoo.com>

I think what it comes down to is there simply is no beginner level
guide written (or even tutorial that I can find) which says "here's how
to create an application."  Because, at root level, that's what new
developers are asking - I have an interface in my head, how do build it
and I get it to run?

One suggestion I do have is an extension of the requests to include the
file-selector as a component in McCLIM - create a library of "standard
interface components" that people can quickly bolt together, and then
they will have only to define the tricky, application specific parts of
the code.  Thinks like menu bars, file-selectors, tabbed windows,
scrollable windows, status bars, slidable controllers, button palettes,
example configuration dialogs, etc. would be really nice to have
available as bolt on components.  These would also form a very good
basis for a graphical UI designer ala glade or QT Designer.  For each
of these, a sort of mini API can be defined, and how they are
implimented internally can change without bothering user code.  This is
probably way beyond the CLIM spec, but it would be an excellent way to
lower the barrier of entry.  And as people create new components, if
appropriate they can be added to the available library until it's only
a special case presentation like a spreadsheet grid or a mathematical
document or an image editing display/interaction that would need to be
custom written - most of the rest of the graphical components could be
gotten from "standard" or even previous custom objects contributed to
the library.  And a graphical CLIM interface builder could possibly go
a long way towards helping people create "correct" code or at least
avoid errors.

Does this make sense to anyone else?

CY

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


From smustudent1 at yahoo.com  Thu Apr 28 18:02:54 2005
From: smustudent1 at yahoo.com (C Y)
Date: Thu, 28 Apr 2005 11:02:54 -0700 (PDT)
Subject: [mcclim-devel] Axiom
Message-ID: <20050428180254.39026.qmail@web31707.mail.mud.yahoo.com>

There has been some discussion going on on the Axiom list about
graphics, and Tim Daly made the following interesting remark:

"I've looked at McClim which is a path I'd dearly love to take but so
far I've not gotten it to work. If someone could reproduce the first
page of the browser (a few buttons, an image) in McClim that might be
enough to get me over the hurdle. A pure lisp solution is preferred."

How difficult would this be to create (assume current McCLIM skills =
<very small quantity>) ?  I would like to take a stab at this (or if
somebody with actual skill does that would be even better) because if
Axiom impliments a GUI in McCLIM it would (IMHO) do a world of good for
both Axiom and McCLIM.  I have gotten McCLIM to work before (though not
on GCL) and if it's not insanely difficult I'd like to take a shot at
it.

CY

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


From smustudent1 at yahoo.com  Thu Apr 28 18:17:24 2005
From: smustudent1 at yahoo.com (C Y)
Date: Thu, 28 Apr 2005 11:17:24 -0700 (PDT)
Subject: [mcclim-devel] Axiom
In-Reply-To: 6667
Message-ID: <20050428181724.16465.qmail@web31710.mail.mud.yahoo.com>


I should mention the browser is not the most complicated thing in the
world graphically, as it dates from a rather earlier period in
interface history.  (A few buttons, objects, etc.)  I can't produce a
screenshot right now because my last install went wonky :-(.

CY

--- C Y <smustudent1 at yahoo.com> wrote:
> There has been some discussion going on on the Axiom list about
> graphics, and Tim Daly made the following interesting remark:
> 
> "I've looked at McClim which is a path I'd dearly love to take but so
> far I've not gotten it to work. If someone could reproduce the first
> page of the browser (a few buttons, an image) in McClim that might be
> enough to get me over the hurdle. A pure lisp solution is preferred."
> 
> How difficult would this be to create (assume current McCLIM skills =
> <very small quantity>) ?  I would like to take a stab at this (or if
> somebody with actual skill does that would be even better) because if
> Axiom impliments a GUI in McCLIM it would (IMHO) do a world of good
> for
> both Axiom and McCLIM.  I have gotten McCLIM to work before (though
> not
> on GCL) and if it's not insanely difficult I'd like to take a shot at
> it.
> 
> CY
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> 

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


From duncan at robotcat.demon.co.uk  Thu Apr 28 18:02:18 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Thu, 28 Apr 2005 19:02:18 +0100
Subject: [mcclim-devel] Black art
In-Reply-To: <17009.6811.306786.30827@gargle.gargle.HOWL>
Message-ID: <A8E882BC-B80F-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Thursday, April 28, 2005, at 06:17 PM, rpgoldman at real-time.com wrote:

>
> I think one thing that makes it more confusing for a newcomer to CLIM
> is the way many of the manuals are written.
>

Indeed.

> I have looked at both the LW and the Allegro manuals, and maybe
> they're great manuals, but they are terrible to learn from.
>
> For example, the Franz CLIM UG seems to be written from the bottom-up,
> in parallel to the architecture of the software.  It starts with
> drawing planes and the screen, and then works up to gadgets.
>

I think both the Franz + Lispworks docs are derived pretty much from the
spec, and as such follow a structure that makes sense in a specification
but probably less sense in a tutorial. Whether the 'user guides' can be
considered tutorials or not is a different question, I suspect many 
people
would say they can't.

The specification itself seems to be written in the order the different
layers of CLIM need to be implemented to have everything work; geometry
comes first (most specific, the foundation of windows, sheets, output
recording, etc.) followed by the next layer (Windowing) which is the
basis for presenting information to the user and reading input from the
user; then the input and output protocols (implemented on top of the
fundamental windowing features) and finally 'application building'.

You almost want to read the spec from back to front as an application
developer I think. Probably the most important thing to take on board
is that CLIM is rigidly layered. The lower, more detailed parts can be
used if needed but generally only the high level parts are necessary
for a large class of applications (default behaviours, basic windowing,
input handling and basic drawing).

There's a good paper floating around somewhere that describes this
layering (for CLIM 1 I think but the general principles are the same
even if some specifics are different). I don't have the link to this
handy either, but it's called "A Guided Tour of the Common Lisp
Interface Manager" by Rao, York and Doughty.

> But if one looks at sources that try to teach a programmer how to do
> things, they always start with tasks the programmer might want to
> accomplish, and work down into detail.  So a guide to using CLIM
> should start with application frames, move to gadgets, etc.
>

I agree with this; I think that this is the approach the McCLIM tutorial
is taking (I seem to have mislaid this document, perhaps somebody else
can provide a pointer). Here's another document (referenced from the
McCLIM wiki) which takes the approach you propose:

http://constantly.at/lisp/ui.html

> Again, I'm not trying to complain that this isn't in those manuals ---
> manuals and tutorials aren't the same.
>
> And I don't want to be seen as a whiner who just wants everything
> given to him on a platter.
>
> What I'd like to do is just share some perceptions of what I think
> might make things easier for McCLIM users and might make McCLIM more
> popular.
>

We could ask the same of Lisp in general perhaps ;-)

-Duncan

> Best,
> R
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From lanning at scra.org  Thu Apr 28 18:26:43 2005
From: lanning at scra.org (Craig Lanning)
Date: Thu, 28 Apr 2005 14:26:43 -0400
Subject: [mcclim-devel] Black art
In-Reply-To: <20050428175306.39622.qmail@web31706.mail.mud.yahoo.com>
References: <20050428175306.39622.qmail@web31706.mail.mud.yahoo.com>
Message-ID: <1114712803.4626.22.camel@dhcp139.isg-scra.org>

On Thu, 2005-04-28 at 10:53 -0700, C Y wrote:
> I think what it comes down to is there simply is no beginner level
> guide written (or even tutorial that I can find) which says "here's how
> to create an application."  Because, at root level, that's what new
> developers are asking - I have an interface in my head, how do build it
> and I get it to run?

This will go a long way in getting people to switch.

I've already started working on just such a guide.  My current working
document (mostly notes and an outline) is in OpenOffice.org format.  If
there is interest in adding the document to McCLIM I'd be happy to
convert it to another format.

> One suggestion I do have is an extension of the requests to include the
> file-selector as a component in McCLIM - create a library of "standard
> interface components" that people can quickly bolt together, and then
> they will have only to define the tricky, application specific parts of
> the code.  Thinks like menu bars, file-selectors, tabbed windows,
> scrollable windows, status bars, slidable controllers, button palettes,
> example configuration dialogs, etc. would be really nice to have
> available as bolt on components.  These would also form a very good
> basis for a graphical UI designer ala glade or QT Designer.  For each
> of these, a sort of mini API can be defined, and how they are
> implimented internally can change without bothering user code.  This is
> probably way beyond the CLIM spec, but it would be an excellent way to
> lower the barrier of entry.  And as people create new components, if
> appropriate they can be added to the available library until it's only
> a special case presentation like a spreadsheet grid or a mathematical
> document or an image editing display/interaction that would need to be
> custom written - most of the rest of the graphical components could be
> gotten from "standard" or even previous custom objects contributed to
> the library.

>   And a graphical CLIM interface builder could possibly go
> a long way towards helping people create "correct" code or at least
> avoid errors.

I built one of these more than 10 years ago.  I'll dust off the code and
post it to the list in the next few days.  (It probably needs updating
since I haven't looked at it in at least 5 years.)

Craig




From ahefner at gmail.com  Thu Apr 28 19:01:20 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 28 Apr 2005 15:01:20 -0400
Subject: [mcclim-devel] Selection mechanism musings (was: possible buglet in
	highlighting shapes)
In-Reply-To: <17009.5931.275190.675482@gargle.gargle.HOWL>
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
Message-ID: <31ffd3c405042812011992cac0@mail.gmail.com>

On 4/28/05, rpgoldman at real-time.com <rpgoldman at real-time.com> wrote:

> - one thing that seems odd is the lack of a conventional selection
>   concept, which we see in the now-standard direct manipulation
>   interfaces.  I.e., you select an object and that provides the focus
>   of all commands.  I'm not sure that providing this is even feasible
>   with CLIM, because of its radically different paradigm.

Agreed. I don't think the omission requires a rethinking of CLIM from
the ground up - you can certainly implement the notion of a selection
yourself if you wanted to - but a standard approach and some utilities
might make life easier. I have some thoughts on how to address this,
and I think they can be implemented in terms of the spec (I haven't
worked out specifics of what it would look like). It could be nice to
provide the functionality ourselves so users don't have to reinvent
the wheel. I've tried several times (unsuccessfully) to elicit
discussion of this on IRC - perhaps the mailing list is a more
appropriate forum.  :)

I can imagine two approachs to this. The first would be to do it
manually, undercutting some of the beauty of the CLIM command
framework. Keep track of the current selection as a slot within the
application frame, enable commands which are applicable to the
selected object, disable commands that are no longer applicable, and
use the value of the selected slot directly within your commands.
Gadget callbacks or even commands on presentations would
select/deselect objects, update the selection slot, enable/disable
commands, etc. If you wanted command input at an interactor to work as
expected, you'd need to define two versions of the commands, one which
uses the 'invisible' selection from the selection slot and one to use
from the command line which prompted for an argument as usual. I think
this is more or less how apps written in a conventional toolkit end up
doing things.

As an example I'll use a graphical file manager, where the frame
represents the view of one directory of files. The application frame
would contain a slot with a list of the currently selected files. You
would define commands in response to the click, control-click,
shift-click gestures which modify the current selection and redisplay
the folder contents to reflect the modified selection. Commands such
as com-delete-files would be defined with no arguments, and would act
on the value of selection slot. To avoid confusing users, you want to
disable com-delete-files and similar commands when the selection is
empty.

The second (and more interesting) approach would be to extend the CLIM
command framework to support a more conventional notion of selected
objects. I think this can be reduced to simply a programmatic way of
transparently providing default arguments to commands, ideally
sensitive to context. I'll return to the file manager example. Using
this approach you could define commands operating on files (such as
com-delete-files) as taking an argument of type (sequence pathname).
If a user enters the command at an interactor, it would prompt for a
list a of pathnames. When selected from a menu the application can
choose to provide default values however it wishes (from a
gadget-value, some internal state, whatever), prompting only for any
remaning arguments (preferrably via a dialog), or executing
immediately if there are no more required arguments. For determining
the current selection, applications could define their own selection
commands as before, or McCLIM could supply an optional mechanism
allowing you to select presentations within a stream pane. The method
supplying the values for the (sequence pathnames) argument in our file
manager would simply query this selection. Some rethinking of the
behavior of the right-button menu also becomes necessary.

I'm not certain what the ideal interface would look like.
Specifically, I'm not sure how you'd want to match arguments (by name?
by presentation type? both? a specific argument to a specific command?
by some extra data tagged on when the argument was declared?). I
imagine a generic function which would be called on each argument of a
chosen command which would have the first shot at providing a value
for the command before the user is prompted. Application writers would
define methods to provide the desired behavior for things like our
file manager. It may be useful to specialize on the frame, context in
which the command was invoked (:interactor, :frame-menu,
:right-button-menu, etc), command name, argument name, and argument
presentation type. Did I miss anything? There are many other ways I
could imagine to acheive similar ends.

I'm sure an app could do most of this stuff within the existing spec.
I haven't worked out exactly how, but providing a customized
read-frame-command might be start. It's possible there is some hook in
the spec doing exactly what I want that I've overlooked.

A tester for commands (similar to the tested user in CLIM presentation
translators) which could be specialized on context would make both
approaches easier (ex. command menu items could be greyed out if they
are not applicable to the current selection or state of the
application).

Something to keep in mind for hypothetical CLIM 3.0 discussions, anyway..


From ahefner at gmail.com  Thu Apr 28 19:03:57 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 28 Apr 2005 15:03:57 -0400
Subject: [mcclim-devel] Axiom
In-Reply-To: <20050428180254.39026.qmail@web31707.mail.mud.yahoo.com>
References: <20050428180254.39026.qmail@web31707.mail.mud.yahoo.com>
Message-ID: <31ffd3c405042812035ec17c48@mail.gmail.com>

What kind of browser?

On 4/28/05, C Y <smustudent1 at yahoo.com> wrote:
> "I've looked at McClim which is a path I'd dearly love to take but so
> far I've not gotten it to work. If someone could reproduce the first
> page of the browser (a few buttons, an image) in McClim that might be
> enough to get me over the hurdle. A pure lisp solution is preferred."
>


From ahefner at gmail.com  Thu Apr 28 19:06:04 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 28 Apr 2005 15:06:04 -0400
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <95C28656-B80C-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
References: <17009.7157.406984.175502@gargle.gargle.HOWL>
	<95C28656-B80C-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <31ffd3c40504281206694bff89@mail.gmail.com>

I think that magic IS required, but it goes on behind the users back.  :)

On 4/28/05, Duncan Rose <duncan at robotcat.demon.co.uk> wrote:

> I think the consensus is that all CLIM 'windows' (i.e. panes that are in
> fact clim-stream-pane types) DO (or at least, should) accept the
> :scroll-bars
> keyword in 'define-application-frame' and will default this to some
> sensible
> value (dependent of pane type) if not provided.
> 
> This *should* mean that no magic is required; just use an :interactor or
> :application (or :command-menu, :title, or :pointer-documentation) pane
> and
> scrolling should 'just happen' (well - some of these types have a
> default
> :scroll-bars of nil and so won't scroll out of the box).


From moore at bricoworks.com  Thu Apr 28 19:20:57 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Thu, 28 Apr 2005 21:20:57 +0200
Subject: [mcclim-devel] Black art
In-Reply-To: <1114712803.4626.22.camel@dhcp139.isg-scra.org>
References: <20050428175306.39622.qmail@web31706.mail.mud.yahoo.com>
	<1114712803.4626.22.camel@dhcp139.isg-scra.org>
Message-ID: <aea3cbfe944cb1a0c17fb751b931d107@bricoworks.com>


On Apr 28, 2005, at 8:26 PM, Craig Lanning wrote:

> On Thu, 2005-04-28 at 10:53 -0700, C Y wrote:
>> I think what it comes down to is there simply is no beginner level
>> guide written (or even tutorial that I can find) which says "here's 
>> how
>> to create an application."  Because, at root level, that's what new
>> developers are asking - I have an interface in my head, how do build 
>> it
>> and I get it to run?
>
> This will go a long way in getting people to switch.
>
> I've already started working on just such a guide.  My current working
> document (mostly notes and an outline) is in OpenOffice.org format.  If
> there is interest in adding the document to McCLIM I'd be happy to
> convert it to another format.
>
Also, a chapter of my dissertation is "A First Application in CLIM" and 
will be part of the McCLIM documentation. It will be finished "soon," 
like in a couple of weeks.

Tim



From smustudent1 at yahoo.com  Thu Apr 28 20:49:25 2005
From: smustudent1 at yahoo.com (C Y)
Date: Thu, 28 Apr 2005 13:49:25 -0700 (PDT)
Subject: [mcclim-devel] Selection mechanism musings (was: possible buglet
	in highlighting shapes)
In-Reply-To: <31ffd3c405042812011992cac0@mail.gmail.com>
Message-ID: <20050428204925.61022.qmail@web31705.mail.mud.yahoo.com>

Selection mechanisms are of interest to me because I suspect as some
point I'm going to be looking at defining a custom one for mathematical
documents.  Most input can be icons, key bindings, or both (e.g. Ctrl-f
for a fraction) but selecting mathematics for various operations will
be a challenge.  (This may ultimately be one of the harder problems
associated with 2D mathematical input, as I understand it, but not
having tried it I can't say for sure.)

I wish I knew enough about this to have an opinion - I guess I need to
read the spec for a while and see if I can get it to "click".

CY

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


From smustudent1 at yahoo.com  Thu Apr 28 22:04:40 2005
From: smustudent1 at yahoo.com (C Y)
Date: Thu, 28 Apr 2005 15:04:40 -0700 (PDT)
Subject: [mcclim-devel] Axiom
In-Reply-To: 6667
Message-ID: <20050428220440.72707.qmail@web31713.mail.mud.yahoo.com>


I note, to my surprise, the screenshots page on Axiom only has the
TeXmacs screenshots.  I'll try to get this sucker working tonight and
make some of the browser.  Basically, as far as I can remember, it was
a text browser with the ability to imbed images and send commands to
Axiom.  A breakthrough for its time but rather dated now - it should be
pretty simple (in theory) to mock up something like it.  (Sinking
feeling as this gets filed under famous last words...)

CY

--- Andy Hefner <ahefner at gmail.com> wrote:
> What kind of browser?
> 
> On 4/28/05, C Y <smustudent1 at yahoo.com> wrote:
> > "I've looked at McClim which is a path I'd dearly love to take but
> so
> > far I've not gotten it to work. If someone could reproduce the
> first
> > page of the browser (a few buttons, an image) in McClim that might
> be
> > enough to get me over the hurdle. A pure lisp solution is
> preferred."
> >
> 

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


From rpgoldman at sift.info  Thu Apr 28 23:45:35 2005
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Thu, 28 Apr 2005 18:45:35 -0500
Subject: [mcclim-devel] Black art
In-Reply-To: <20050428175306.39622.qmail@web31706.mail.mud.yahoo.com>
References: <20050428175306.39622.qmail@web31706.mail.mud.yahoo.com>
Message-ID: <17009.30111.888130.435746@gargle.gargle.HOWL>

>>>>> "C" == C Y <C> writes:

    C> I think what it comes down to is there simply is no beginner level
    C> guide written (or even tutorial that I can find) which says "here's how
    C> to create an application."  Because, at root level, that's what new
    C> developers are asking - I have an interface in my head, how do build it
    C> and I get it to run?

There is actually a good tutorial article, 

http://kantz.com/jason/clim-primer/

The only thing wrong with it is that there isn't more of it!



From rpgoldman at sift.info  Fri Apr 29 02:41:02 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Thu, 28 Apr 2005 21:41:02 -0500
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <31ffd3c4050428104051ec0dfe@mail.gmail.com>
References: <31ffd3c405042716365d74339a@mail.gmail.com>
	<07872279-B7A4-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<17009.7157.406984.175502@gargle.gargle.HOWL>
	<31ffd3c4050428104051ec0dfe@mail.gmail.com>
Message-ID: <17009.40638.434570.503225@gargle.gargle.HOWL>

>>>>> "AH" == Andy Hefner <ahefner at gmail.com> writes:

    AH> On 4/28/05, Robert P. Goldman <rpgoldman at sift.info> wrote:
    >> OK, sorry.  But for the stupid, what's the magic to put in
    >> make-application-frame that will give us something that's scrollable?
    >> 
    >> If there is no easy way to specify a scrollable pane, isn't that a
    >> problem?

    AH> I think you are missing something. Use the 'scrolling' macro in your
    AH> layout, for example:

    AH> (define-application-frame ...
    AH>   ...
    AH>   (:layouts
    AH>     (default
    AH>       (scrolling () my-pane)))) ;; Is that the sort of macrology
    AH> you're looking for?

Thanks, Andy.  I was looking in the wrong place.  This explains my
wrong-headedness before, too.  Scrolling is obviously an aspect of
layout, rather than pane content.  I retract my original comments...

R


-- 
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
SIFT offices:  (612) 339-7438
Email:    rpgoldman at SIFT.info


From amoroso at mclink.it  Fri Apr 29 07:46:50 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 09:46:50 +0200
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <31ffd3c405042723076cee4866@mail.gmail.com> (Andy Hefner's
	message of "Thu, 28 Apr 2005 02:07:09 -0400")
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<1114642938.6637.75.camel@wok>
	<31ffd3c405042723076cee4866@mail.gmail.com>
Message-ID: <87sm1a10ut.fsf@plato.moon.paoloamoroso.it>

Andy Hefner <ahefner at gmail.com> writes:

> I took a brief look at this tonight, and I see that the keystrokes are
> indeed not working as expected. I tried a variation on you example

I confirm this.


> The #\c-\q syntax is new to me.

This might be a formatting artifact of the conversion process for
producing multiple versions--e.g. PDF, HTML--of the LW CLIM manual
from a single source.  Just--wildly--guessing...


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


From amoroso at mclink.it  Fri Apr 29 07:54:33 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 09:54:33 +0200
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <7392F606-B770-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	(Duncan Rose's message of "Thu, 28 Apr 2005 00:02:38 +0100")
References: <7392F606-B770-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <87oeby10hy.fsf@plato.moon.paoloamoroso.it>

Duncan Rose <duncan at robotcat.demon.co.uk> writes:

> something that's slow) but getting the correct part is the trick. I've
> read certain sections of the spec repeatedly ('geometry substrate',
> 'windowing substrate', parts of 'building applications' mainly), and
> inspected the McCLIM code in detail too in these areas and I still
> have no idea what the 'correct' behaviour is in many cases.

You may check the CLIM mailing list archives.  They provide
explanations and clarifications on many design decisions and
implementation issues.


> Most of this (IMHO) is definitely down to vagueness in the spec (for
> another example, according to the LispWorks CLIM user guide, a
> platform-specific fontspec can be used as a text-style (e.g. an X
> fontspec), and this is intimated at in the spec too, but it's not made
> clear). I have no idea if McCLIM supports this though (I think:

The main problem with CLIM vendors manuals is that they don't make
clear what is in the spec and what is an extension.


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


From amoroso at mclink.it  Fri Apr 29 08:07:17 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 10:07:17 +0200
Subject: [mcclim-devel] Black art
In-Reply-To: <A8E882BC-B80F-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	(Duncan Rose's message of "Thu, 28 Apr 2005 19:02:18 +0100")
References: <A8E882BC-B80F-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <87br7y0zwq.fsf@plato.moon.paoloamoroso.it>

Duncan Rose <duncan at robotcat.demon.co.uk> writes:

> There's a good paper floating around somewhere that describes this
> layering (for CLIM 1 I think but the general principles are the same
> even if some specifics are different). I don't have the link to this
> handy either, but it's called "A Guided Tour of the Common Lisp
> Interface Manager" by Rao, York and Doughty.

The article you mean is here:

  http://www.cliki.net/CLIM


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


From yoel.jacobsen at gmail.com  Fri Apr 29 05:25:08 2005
From: yoel.jacobsen at gmail.com (Yoel Jacobsen)
Date: Fri, 29 Apr 2005 08:25:08 +0300
Subject: [mcclim-devel] Subclassing text-field?
Message-ID: <894fac1f05042822251d4c2fc1@mail.gmail.com>

I would like to have a numeric-only text-field. I want it to return
numbers with gadget-value, and to be able to setf it with numbers (and
not strings). Is subclassing text-field (and text-field-pane?) and
defining gadget-value and (setf gadget-value) the solution? If so, it
seems to be more complicated than I thought.

Any idea/help/example?

Thanks,
  Yoel


From amoroso at mclink.it  Fri Apr 29 09:44:19 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 11:44:19 +0200
Subject: [mcclim-devel] Re: Black art
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
	<17009.6811.306786.30827@gargle.gargle.HOWL>
Message-ID: <87pswdx6h8.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> I think one thing that makes it more confusing for a newcomer to CLIM
> is the way many of the manuals are written.  
>
> I have looked at both the LW and the Allegro manuals, and maybe
> they're great manuals, but they are terrible to learn from.  

The lack of good tutorial-style material and sample code has been a
constant complaint raised in the CLIM mailing list archives.  Some
vendors, such as Symbolics, offered training, and some tutorial
sessions were done at Lisp conferences.  A suggestion for the next
Lispnik events, large and small: CLIM tutorials.


> What I'd like to do is just share some perceptions of what I think
> might make things easier for McCLIM users and might make McCLIM more
> popular.

Keep the questions going until my fingers bleed on the keyboard :)


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


From amoroso at mclink.it  Fri Apr 29 09:48:51 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 11:48:51 +0200
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <1114642938.6637.75.camel@wok> (Thibault Langlois's message of
	"Thu, 28 Apr 2005 00:02:18 +0100")
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<1114642938.6637.75.camel@wok>
Message-ID: <87ekctx69o.fsf@plato.moon.paoloamoroso.it>

Thibault Langlois <tl at di.fc.ul.pt> writes:

> It would be usefull to have a place were to keep these hints. I am not

Such tips used to be collected here:

  http://mcclim.cliki.net/Tip

It was suggested to collect them in the manual, and some were moved
there.


> sure McCLIM cliki is the right place. The anotable version of the specs
> could be a convenient place to put such hints (because one would be able
> to read the doc and see other users' advices) but the anotations I have
> seen are mostly about the standard, not very useful for a user with
> little experience. 

You probably saw few annotations because the annotation interface was
broken.  Gilbert plans to fix it and move it to a new location.


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


From amoroso at mclink.it  Fri Apr 29 09:59:23 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 11:59:23 +0200
Subject: [mcclim-devel] Subclassing text-field?
References: <894fac1f05042822251d4c2fc1@mail.gmail.com>
Message-ID: <87sm19vr7o.fsf@plato.moon.paoloamoroso.it>

I have just posted this reply to your comp.lang.lisp thread.


Paolo

------------------------------------------------------------------------
"Yoel Jacobsen" <yoel.jacobsen at gmail.com> writes:

> I would like to have a numeric-only text-field. I want it to return
> numbers with gadget-value, and to be able to setf it with numbers (and
> not strings). Is subclassing text-field (and text-field-pane?) and
> defining gadget-value and (setf gadget-value) the solution? If so, it
> seems to be more complicated than I thought.

Off the top of my head, this should work.  A possibly more idiomatic
way would be to put something like this into an accepting-values form:

  (let (my-number)
    (setf my-number (accept 'number :stream stream
                                    :prompt "Insert a number "
                                    :default 0)))

But, if I understand correctly, McCLIM currently has a couple of
limitations:

- accepting-values is not fully implemented, and it does not use
  gadget views (this mostly mean that the look may not be pretty)
- restrictions on the type of accepted value are not enforced, and
  only a warning message is printed

As has been suggested, you may get additional feedback from the McCLIM
mailing list.


Paolo
------------------------------------------------------------------------

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


From amoroso at mclink.it  Fri Apr 29 11:48:01 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 13:48:01 +0200
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <31ffd3c405042723076cee4866@mail.gmail.com> (Andy Hefner's
	message of "Thu, 28 Apr 2005 02:07:09 -0400")
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<1114642938.6637.75.camel@wok>
	<31ffd3c405042723076cee4866@mail.gmail.com>
Message-ID: <878y31st1q.fsf@plato.moon.paoloamoroso.it>

Andy Hefner <ahefner at gmail.com> writes:

> I took a brief look at this tonight, and I see that the keystrokes are
> indeed not working as expected. I tried a variation on you example
> using a single character with no modifier, and that worked fine. I'm
> pretty sure this was working not too long ago (my old tests appear to

Does this involve the :use-keystrokes argument of read-command, or
maybe read-command-using-keystrokes?  I don't understand whether the
user has to explicitly specialize a frame top-level in order to make
keystrokes work.


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


From amoroso at mclink.it  Fri Apr 29 12:02:19 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 14:02:19 +0200
Subject: [mcclim-devel] possible buglet in highlighting shapes
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
Message-ID: <87zmvhrdtg.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> - Examples of use of standard gadgets.  E.g., on others' suggestion,

The LUV-93 CLIM tutorial code:

  ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/gui/clim/clim_2/luv93tut/0.html

has some such examples in file gadgets.lisp.  I don't know whether
this is what you mean.  More uses are in actual applications.  I tried
to post links to all the CLIM code I run across here:

  http://mcclim.cliki.net/Application

And yes, I agree that this is not necessarily an efficient way of
answering your question :)


> - An easier introduction to providing an application frame with a menu
>   bar, since that seems like a central UI paradigm these days.  Note

Do you mean something beyond what provided by
src/Examples/menutest.lisp in the McCLIM distribution?


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


From duncan at robotcat.demon.co.uk  Fri Apr 29 17:03:40 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Fri, 29 Apr 2005 18:03:40 +0100
Subject: [mcclim-devel] possible buglet in highlighting shapes
In-Reply-To: <87oeby10hy.fsf@plato.moon.paoloamoroso.it>
Message-ID: <A25B03A6-B8D0-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Friday, April 29, 2005, at 08:54 AM, Paolo Amoroso wrote:

> Duncan Rose <duncan at robotcat.demon.co.uk> writes:
>
>> something that's slow) but getting the correct part is the trick. I've
>> read certain sections of the spec repeatedly ('geometry substrate',
>> 'windowing substrate', parts of 'building applications' mainly), and
>> inspected the McCLIM code in detail too in these areas and I still
>> have no idea what the 'correct' behaviour is in many cases.
>
> You may check the CLIM mailing list archives.  They provide
> explanations and clarifications on many design decisions and
> implementation issues.
>

This is a useful resource (well... it's interesting) but not helpful in 
this case. I wasn't very clear but I was more talking about things that 
might relate the the back end. For example, what is a 'mirror region'? 
Is it the visible (presumably rectangular) area of the mirror that is 
visible, not accounting for occlusion? Or is it the 'physical' area of 
the mirror, which only makes sense when the mirror transform is taken 
in account? What does it mean to modify the mirror region?

I talk about this specifically because when McCLIM resizes a mirrored 
sheet, the size of the mirror also appears to change. This is a good 
thing in CLX since it appears to me that scrolling can be implemented 
just by informing the X server what the new offsets are, and the 
display is updated *by X*. This is not however so good for Beagle, 
since it just means I end up with a potentially huge window server 
object which then has to be redisplayed via the CLIM machinery. Now 
Cocoa has very good support for performing windowing operations that 
parallel CLIMs support in many ways, but it's hard to use them when 
dealing with a mirror that has a region of 550 x 16245 (say) and a 
mirror transformation that modifies y ordinates by -15800, when I could 
have a mirror with a region that's 550 x 445, and a noop transform.

The CLIM spec is very quiet on these kinds of issues, preferring to 
leave these kinds of things up to the back ends (which is a good thing) 
but it's very difficult to get any indication of what a 'mirror region' 
is INTENDED to be. I was toying with moving 'update-mirror-geometry' 
into the back ends, so CLX + Beagle could do this differently (and 
'care-for-new-native-transformation' seems to never be invoked which is 
strange) but I haven't decided whether to do this or not.

It wasn't until I happened to read the glossary in the Lispworks CLIM 
UG that I understood that in CLIM terminology, a 'window' is just a 
clim-stream-pane class. Basic, maybe, but it certainly helps 
understanding what people are talking about sometimes ;-)

>
>> Most of this (IMHO) is definitely down to vagueness in the spec (for
>> another example, according to the LispWorks CLIM user guide, a
>> platform-specific fontspec can be used as a text-style (e.g. an X
>> fontspec), and this is intimated at in the spec too, but it's not made
>> clear). I have no idea if McCLIM supports this though (I think:
>
> The main problem with CLIM vendors manuals is that they don't make
> clear what is in the spec and what is an extension.
>
>
> Paolo
> -- 
> Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From duncan at robotcat.demon.co.uk  Fri Apr 29 17:13:27 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Fri, 29 Apr 2005 18:13:27 +0100
Subject: [mcclim-devel] Selection mechanism musings (was: possible buglet
	in highlighting shapes)
In-Reply-To: <31ffd3c405042812011992cac0@mail.gmail.com>
Message-ID: <0091F00C-B8D2-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>

On Thursday, April 28, 2005, at 08:01 PM, Andy Hefner wrote:

 >On 4/28/05, rpgoldman at real-time.com <rpgoldman at real-time.com> wrote:
 >
 >>- one thing that seems odd is the lack of a conventional selection
 >>   concept, which we see in the now-standard direct manipulation
 >>   interfaces.  I.e., you select an object and that provides the focus
 >>   of all commands.  I'm not sure that providing this is even feasible
 >>   with CLIM, because of its radically different paradigm.
 >
 >Agreed. I don't think the omission requires a rethinking of CLIM from
 >the ground up - you can certainly implement the notion of a selection
 >yourself if you wanted to - but a standard approach and some utilities
 >might make life easier. I have some thoughts on how to address this,
 >and I think they can be implemented in terms of the spec (I haven't
 >worked out specifics of what it would look like). It could be nice to
 >provide the functionality ourselves so users don't have to reinvent
 >the wheel. I've tried several times (unsuccessfully) to elicit
 >discussion of this on IRC - perhaps the mailing list is a more
 >appropriate forum.  :)
 >

I'm sure something about this came up on the clim mailing list (archives
are linked from the CLIM cliki page somewhere) at some point and the 
point
was made that this kind of thing can be done within the CLIM framework
using some feature or other which I unfortunately can't remember at the
moment...

Scanning mail archives ... done. [elapsed time: 1.5 hours]

Ack, every time I delve into those mailing list archives I'm stuck for
hours. The thing I was thinking of was 'presentation actions' but having
reread some of the messages I think I misremembered the advice about 
them.
I don't think CLIM 2 has them anyway (the translation infrastructure was
probably beefed up so they became unnecessary I'm guessing).

I've attached a couple of mails that looked relevent to this discussion.
Any code probably won't work with CLIM 2, but should be relatively 
easily
ported I guess. If nothing else, approximate dates and subject lines 
might
make the rest of the related messages easier to locate...

I actually think this mode of interaction (using selections) might 
assist
accessibility; particularly if there was a selection history that could
be navigated trivially. Perhaps the presentation history mechanism would
help here, but that's just a random guess since I know very little about
that (yet).

 >I can imagine two approachs to this. The first would be to do it
 >manually, undercutting some of the beauty of the CLIM command
 >framework. Keep track of the current selection as a slot within the
 >application frame, enable commands which are applicable to the
 >selected object, disable commands that are no longer applicable, and
 >use the value of the selected slot directly within your commands.
 >Gadget callbacks or even commands on presentations would
 >select/deselect objects, update the selection slot, enable/disable
 >commands, etc. If you wanted command input at an interactor to work as
 >expected, you'd need to define two versions of the commands, one which
 >uses the 'invisible' selection from the selection slot and one to use
 >from the command line which prompted for an argument as usual. I think
 >this is more or less how apps written in a conventional toolkit end up
 >doing things.
 >

Why would this need to be done manually, undercutting the current 
command
framework? I feel (i.e. it's purely subjective!) that the command 
framework
could be bent sufficiently to support this automatically... well, maybe.

Selection functionality can be split into at least two parts I think. 
The
first is how selections are made, and that kind of depends I suppose on 
what
is being selected.
The second relates to what to do with the selection once made. The
right-click
menu has already been mentioned. Being able to drag arbitrary 'selection
sets'
around seems like a useful thing, but so too would being able to set 
(say)
the
text style for a selection set (that contained text).

I'd have thought having a 'add-object-to-selection-set' command would be
sufficient to maintain any selection (ok, I guess 'remove-...' might be
needed too ;-). Some kind of specialization would be needed to cope with
different kinds of selections (multiple presentations, window regions,
blocks
of text).

Is there any reason a command couldn't accept a "selection-set" as an 
input?

Then the commands that operate with a selection set could work as you
describe.

However I strongly feel that using the current CLIM command structure
(action - on what) is not suitable to commands that would operate on a
selection
set (on what - action). I would propose NOT having commands that 
requested
selections at all. Commands operating on selections would either 
operate on
the current selection, or report an error (no selection).

This is kind of the way Emacs dired works after all; use 'd' to mark 
files
for
deletion, then 'x' to do the actual delete. If you 'x' without any 'd', 
the
result is a simple warning.

This feels (to my rather inexperienced mind ;-) to be something that is
achievable largely within the existing framework (some extension of 
commands
and 'presentations' would probably be needed).

I thought CLIM (under CLX at least) already supported some kind of 
selection
mechanism? Or is that single-presentation only? I must confess to not 
having
looked in detail yet, I have enough trouble hacking Beagle to support 
the
CLX
functionality of 12 months ago :-)


 >As an example I'll use a graphical file manager, where the frame
 >represents the view of one directory of files. The application frame
 >would contain a slot with a list of the currently selected files. You
 >would define commands in response to the click, control-click,
 >shift-click gestures which modify the current selection and redisplay
 >the folder contents to reflect the modified selection. Commands such
 >as com-delete-files would be defined with no arguments, and would act
 >on the value of selection slot. To avoid confusing users, you want to
 >disable com-delete-files and similar commands when the selection is
 >empty.
 >

We seem to be thinking along the same lines ;-) I don't think the 
commands
would need to be disabled though (having said that, it would be nice to
be able to make them unavailable from menus and such, so maybe they do
need to be disabled).

 >The second (and more interesting) approach would be to extend the CLIM
 >command framework to support a more conventional notion of selected
 >objects. I think this can be reduced to simply a programmatic way of
 >transparently providing default arguments to commands, ideally
 >sensitive to context. I'll return to the file manager example. Using
 >this approach you could define commands operating on files (such as
 >com-delete-files) as taking an argument of type (sequence pathname).
 >If a user enters the command at an interactor, it would prompt for a
 >list a of pathnames. When selected from a menu the application can
 >choose to provide default values however it wishes (from a
 >gadget-value, some internal state, whatever), prompting only for any
 >remaning arguments (preferrably via a dialog), or executing
 >immediately if there are no more required arguments. For determining
 >the current selection, applications could define their own selection
 >commands as before, or McCLIM could supply an optional mechanism
 >allowing you to select presentations within a stream pane. The method
 >supplying the values for the (sequence pathnames) argument in our file
 >manager would simply query this selection. Some rethinking of the
 >behavior of the right-button menu also becomes necessary.
 >

I like this, but I think it's a restatement of what's already been said.
Maybe I'm missing something. The only thing I'd add is that perhaps
prompting for additional arguments strikes me as a 'bad thing'. We'll
be giving the user's familiarity on the one hand (click + operate) but
taking it away with the other (start asking for additional stuff).
Anything other than an 'are you sure [y/n]' dialogue seems unnecessary
at this point IMO. Anyway, if we are going to break the 'standard'
selection protocol (i.e. as implemented in most os'es at the moment)
I think I'd rather not have it at all.

What are we hoping to achieve with all this? The ability to generate
appliactions that can look and feel like native apps? Or just a fix
for the 'one file at a time' problem of the LispMs (which may have
been fixed anyway, I don't know). The implementation would be different
depending on the answer I think.

 >I'm not certain what the ideal interface would look like.
 >Specifically, I'm not sure how you'd want to match arguments (by name?
 >by presentation type? both? a specific argument to a specific command?
 >by some extra data tagged on when the argument was declared?). I
 >imagine a generic function which would be called on each argument of a
 >chosen command which would have the first shot at providing a value
 >for the command before the user is prompted. Application writers would
 >define methods to provide the desired behavior for things like our
 >file manager. It may be useful to specialize on the frame, context in
 >which the command was invoked (:interactor, :frame-menu,
 >:right-button-menu, etc), command name, argument name, and argument
 >presentation type. Did I miss anything? There are many other ways I
 >could imagine to acheive similar ends.

I think I've stated my thoughts... this looks like it will be an 
interesting
discussion.

-Duncan

ps. would the drag and drop stuff be tied in to selections too? It seems
like that would be a good idea to me...

-D


 >
 >I'm sure an app could do most of this stuff within the existing spec.
 >I haven't worked out exactly how, but providing a customized
 >read-frame-command might be start. It's possible there is some hook in
 >the spec doing exactly what I want that I've overlooked.
 >
 >A tester for commands (similar to the tested user in CLIM presentation
 >translators) which could be specialized on context would make both
 >approaches easier (ex. command menu items could be greyed out if they
 >are not applicable to the current selection or state of the
 >application).
 >
 >Something to keep in mind for hypothetical CLIM 3.0 discussions,
 >anyway..
 >_______________________________________________
 >mcclim-devel mailing list
 >mcclim-devel at common-lisp.net
 >http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
 >
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: email1.txt
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050429/df463a17/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: email2.txt
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050429/df463a17/attachment-0001.txt>
-------------- next part --------------




From smustudent1 at yahoo.com  Fri Apr 29 19:19:20 2005
From: smustudent1 at yahoo.com (C Y)
Date: Fri, 29 Apr 2005 12:19:20 -0700 (PDT)
Subject: [mcclim-devel] re: Black art
Message-ID: <20050429191920.50152.qmail@web31707.mail.mud.yahoo.com>

>>   And a graphical CLIM interface builder could possibly go
>> a long way towards helping people create "correct" code or at 
>> least avoid errors.
>
> I built one of these more than 10 years ago.  I'll dust off the 
> code and post it to the list in the next few days.  (It probably 
> needs updating since I haven't looked at it in at least 5 years.)

In case I forgot to say it elsewhere, drool... :-)

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  Fri Apr 29 19:59:58 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Fri, 29 Apr 2005 14:59:58 -0500
Subject: [mcclim-devel] resizeable panes
Message-ID: <17010.37438.264108.469809@gargle.gargle.HOWL>


Is there any easy way to give a McCLIM pane one of those handy-dandy
stretch interactors that conventional UIs have?  You know, where you
can re-allocate space across a pair of panes by dragging on the
bounday line, or a little icon attached to the boundary?

Thanks,
R


From amoroso at mclink.it  Fri Apr 29 20:18:28 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 29 Apr 2005 22:18:28 +0200
Subject: [mcclim-devel] resizeable panes
In-Reply-To: <17010.37438.264108.469809@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Fri, 29 Apr 2005 14:59:58 -0500")
References: <17010.37438.264108.469809@gargle.gargle.HOWL>
Message-ID: <874qdpbaln.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> Is there any easy way to give a McCLIM pane one of those handy-dandy
> stretch interactors that conventional UIs have?  You know, where you
> can re-allocate space across a pair of panes by dragging on the
> bounday line, or a little icon attached to the boundary?

At least one CLIM implementation, probably Franz's, provides access to
the Motif sashes.


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


From smustudent1 at yahoo.com  Fri Apr 29 20:28:20 2005
From: smustudent1 at yahoo.com (C Y)
Date: Fri, 29 Apr 2005 13:28:20 -0700 (PDT)
Subject: [mcclim-devel] resizeable panes
In-Reply-To: 6667
Message-ID: <20050429202820.95758.qmail@web31714.mail.mud.yahoo.com>

--- Paolo Amoroso <amoroso at mclink.it> wrote:
> rpgoldman at real-time.com writes:
> 
> > Is there any easy way to give a McCLIM pane one of those
> handy-dandy
> > stretch interactors that conventional UIs have?  You know, where
> you
> > can re-allocate space across a pair of panes by dragging on the
> > bounday line, or a little icon attached to the boundary?
> 
> At least one CLIM implementation, probably Franz's, provides access
> to
> the Motif sashes.
> 
> 
> Paolo

So CLIM itself doesn't address this?

CY

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


From ahefner at gmail.com  Fri Apr 29 22:34:49 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Fri, 29 Apr 2005 18:34:49 -0400
Subject: [mcclim-devel] resizeable panes
In-Reply-To: <17010.37438.264108.469809@gargle.gargle.HOWL>
References: <17010.37438.264108.469809@gargle.gargle.HOWL>
Message-ID: <31ffd3c4050429153439b45739@mail.gmail.com>

I have a quick hack in McCLIM  which accomplishes this somewhat
tolerably. It is a gadget which can be inserted in a
horizontal/vertical-box/rack pane which will adjust the space
requirements of the two panes adjacent to it. I believe it is called
box-adjuster-gadget (and if that's wrong, you can find the code at end
of mcclim/gadgets.lisp). IIRC it is exported from the clim-extensions
package.

Currently it sometimes lags behind the mouse cursor in a way that is
not intuitive. This is a funky interaction with the layout gadgets,
which are being too smart for their own good. It should be easily
fixable by anyone with the patience to learn how the layout gadgets
are implemented.

On 4/29/05, rpgoldman at real-time.com <rpgoldman at real-time.com> wrote:
> 
> Is there any easy way to give a McCLIM pane one of those handy-dandy
> stretch interactors that conventional UIs have?  You know, where you
> can re-allocate space across a pair of panes by dragging on the
> bounday line, or a little icon attached to the boundary?
> 
> Thanks,
> R
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>


From amoroso at mclink.it  Sat Apr 30 08:25:34 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sat, 30 Apr 2005 10:25:34 +0200
Subject: [mcclim-devel] resizeable panes
In-Reply-To: <20050429202820.95758.qmail@web31714.mail.mud.yahoo.com> (C.
	Y.'s message of "Fri, 29 Apr 2005 13:28:20 -0700 (PDT)")
References: <20050429202820.95758.qmail@web31714.mail.mud.yahoo.com>
Message-ID: <87is24y8ld.fsf@plato.moon.paoloamoroso.it>

C Y <smustudent1 at yahoo.com> writes:

> So CLIM itself doesn't address this?

It doesn't, this is an extension.


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


From duncan at robotcat.demon.co.uk  Sat Apr 30 08:54:06 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 09:54:06 +0100
Subject: [mcclim-devel] Command translator question
Message-ID: <68D6EE3A-B955-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


I'm trying to define a presentation command translator which will 
invoke 'describe presentation' on specific types. Unfortunately it 
doesn't work (or at least, works in a way that I'm not expecting so if 
it's working it's not doing what I want ;-)

Looking at the translators defined in the Listener and in 
builtin-commands.lisp hasn't helped. Here's the translator:

(define-presentation-to-command-translator port-select-to-command  ; 
name
   (t                     ; from-type
    com-describe          ; command-name - maybe 
com-describe-presentation?
    global-command-table  ; command table containing command
    :gesture :select      ; activate on :select (left-button click)
    ;; :tester ...
    :documentation
    "Invoke the 'describe presentation' command on the selected 
presentation"
    :pointer-documentation ((object stream) (format stream "Describe ~A" 
object))
    :menu t               ; command should appear in popped-up menus
    ;; :priority ...
    :echo nil)            ; don't echo the command when it is invoked
   ;; arglist must be a subset (using string-equal) of:
   ;;    (object presentation context-type frame event window x y)
   (object)
   ;; body of translator; returns a list of the arguments to the command
   ;; named by command-name.
   (list object))

In case I was providing the wrong 'from-type' I changed it to T (all 
types, I hope). I've written this using the Beagle back end but it 
doesn't work for me when run under CLX either...

Any suggestions would be appreciated, I'm obviously missing something...

I've attached the complete code for context in case it's helpful.

-Duncan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: glimpse.lisp
Type: application/octet-stream
Size: 11211 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050430/6d41a702/attachment.obj>

From tim at tenkan.org  Sat Apr 30 09:45:05 2005
From: tim at tenkan.org (Tim Daly Jr.)
Date: 30 Apr 2005 11:45:05 +0200
Subject: [mcclim-devel] interactor-pane scrolls off the bottom
Message-ID: <87fyx8k38e.fsf@beer.intern>


If you say

    (define-application-frame foo ()
      ()
      (:pane (make-pane 'interactor-pane :width 400 :height 300)))

    (clim:run-frame-top-level (clim:make-application-frame 'foo))

You get a window.  Hit RET a few times in that window, and the prompt
will scroll off the bottom of it, never to return.  Is it meant to
work that way?


-- 
-Tim




From duncan at robotcat.demon.co.uk  Sat Apr 30 09:52:51 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 10:52:51 +0100
Subject: [mcclim-devel] interactor-pane scrolls off the bottom
In-Reply-To: <87fyx8k38e.fsf@beer.intern>
Message-ID: <9DF144B6-B95D-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Saturday, April 30, 2005, at 10:45 AM, Tim Daly Jr. wrote:

>
> If you say
>
>     (define-application-frame foo ()
>       ()
>       (:pane (make-pane 'interactor-pane :width 400 :height 300)))
>
>     (clim:run-frame-top-level (clim:make-application-frame 'foo))
>
> You get a window.  Hit RET a few times in that window, and the prompt
> will scroll off the bottom of it, never to return.  Is it meant to
> work that way?
>

Not sure, but quite possibly.

Changing the :pane form to

(:pane (scrolling () (make-pane 'interactor-pane :width 400 :height 
300)))

fixes it for me.

-Duncan


>
> -- 
> -Tim
>
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From duncan at robotcat.demon.co.uk  Sat Apr 30 10:01:54 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 11:01:54 +0100
Subject: [mcclim-devel] interactor-pane scrolls off the bottom
In-Reply-To: <9DF144B6-B95D-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <E160481B-B95E-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On an additional note...

On Saturday, April 30, 2005, at 10:52 AM, Duncan Rose wrote:

>
> On Saturday, April 30, 2005, at 10:45 AM, Tim Daly Jr. wrote:
>
>>
>> If you say
>>
>>     (define-application-frame foo ()
>>       ()
>>       (:pane (make-pane 'interactor-pane :width 400 :height 300)))
>>

(define-application-frame foo ()
   ()
   (:panes (int :interactor :width 400 :height 400))
   (:layouts (default int)))

Provides scroll bars too. I can't see anything in the spec that 
indicates
the behaviour of the :pane form should be different to the behaviour of
:panes + :layouts in combination but it's more than possible I missed
something (I usually do).

-Duncan

>>     (clim:run-frame-top-level (clim:make-application-frame 'foo))
>>
>> You get a window.  Hit RET a few times in that window, and the prompt
>> will scroll off the bottom of it, never to return.  Is it meant to
>> work that way?
>>
>
> Not sure, but quite possibly.
>
> Changing the :pane form to
>
> (:pane (scrolling () (make-pane 'interactor-pane :width 400 :height 
> 300)))
>
> fixes it for me.
>
> -Duncan
>
>
>>
>> -- 
>> -Tim
>>
>>
>> _______________________________________________
>> mcclim-devel mailing list
>> mcclim-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>>
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From tim at tenkan.org  Sat Apr 30 10:30:15 2005
From: tim at tenkan.org (Tim Daly Jr.)
Date: 30 Apr 2005 12:30:15 +0200
Subject: [mcclim-devel] interactor-pane scrolls off the bottom
In-Reply-To: <E1E73C3A-B95F-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
References: <E1E73C3A-B95F-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <87br7wk154.fsf@beer.intern>

Duncan Rose <duncan at robotcat.demon.co.uk> writes:

> Doh. Think / read before responding. In the spec, section 29.4.3 we see
> that CLIM "provides a convenient form for creating composite panes that
> include the CLIM stream pane, scroll bars, labels, and so forth". I
> conclude from that that somewhere the spec allows for the creation of
> stream panes that don't have all this gubbins.
> 
> Going back to your first example, if you do
> 
> (define-application-frame foo ()
>    ()
>    (:pane (make-clim-stream-pane :type 'interactor-pane :width 400
> :height 300)))
> 
> that works too.
> 
> -Duncan
> 
> ps. last post on this from me, promise. :-/

Hey, thanks a lot for looking at it! :) From the sounds of it, this
leans more towards feature than bug.  

I asked because this feature shows up in closure's interactor pane.  I
disabled the feature there by saying ":scroll-bars t".  There was just
a long thread here about scroll bars, but all subtlety is lost on me.


-- 
-Tim



From duncan at robotcat.demon.co.uk  Sat Apr 30 10:09:04 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 11:09:04 +0100
Subject: [mcclim-devel] interactor-pane scrolls off the bottom
In-Reply-To: <E160481B-B95E-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <E1E73C3A-B95F-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


Doh. Think / read before responding. In the spec, section 29.4.3 we see
that CLIM "provides a convenient form for creating composite panes that
include the CLIM stream pane, scroll bars, labels, and so forth". I
conclude from that that somewhere the spec allows for the creation of
stream panes that don't have all this gubbins.

Going back to your first example, if you do

(define-application-frame foo ()
   ()
   (:pane (make-clim-stream-pane :type 'interactor-pane :width 400 
:height 300)))

that works too.

-Duncan

ps. last post on this from me, promise. :-/


On Saturday, April 30, 2005, at 11:01 AM, Duncan Rose wrote:

>
> On an additional note...
>
> On Saturday, April 30, 2005, at 10:52 AM, Duncan Rose wrote:
>
>>
>> On Saturday, April 30, 2005, at 10:45 AM, Tim Daly Jr. wrote:
>>
>>>
>>> If you say
>>>
>>>     (define-application-frame foo ()
>>>       ()
>>>       (:pane (make-pane 'interactor-pane :width 400 :height 300)))
>>>
>
> (define-application-frame foo ()
>   ()
>   (:panes (int :interactor :width 400 :height 400))
>   (:layouts (default int)))
>
> Provides scroll bars too. I can't see anything in the spec that 
> indicates
> the behaviour of the :pane form should be different to the behaviour of
> :panes + :layouts in combination but it's more than possible I missed
> something (I usually do).
>
> -Duncan
>
>>>     (clim:run-frame-top-level (clim:make-application-frame 'foo))
>>>
>>> You get a window.  Hit RET a few times in that window, and the prompt
>>> will scroll off the bottom of it, never to return.  Is it meant to
>>> work that way?
>>>
>>
>> Not sure, but quite possibly.
>>
>> Changing the :pane form to
>>
>> (:pane (scrolling () (make-pane 'interactor-pane :width 400 :height 
>> 300)))
>>
>> fixes it for me.
>>
>> -Duncan
>>
>>
>>>
>>> -- 
>>> -Tim
>>>
>>>
>>> _______________________________________________
>>> mcclim-devel mailing list
>>> mcclim-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>>>
>>
>> _______________________________________________
>> mcclim-devel mailing list
>> mcclim-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>>
>



From pw at snoopy.mv.com  Sat Apr 30 13:02:49 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Sat, 30 Apr 2005 09:02:49 -0400
Subject: [mcclim-devel] Command translator question
References: <68D6EE3A-B955-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <003501c54d84$e9aa2170$0201a8c0@moby>


----- Original Message ----- 
From: "Duncan Rose" <duncan at robotcat.demon.co.uk>
To: <mcclim-devel at common-lisp.net>
Sent: Saturday, April 30, 2005 4:54 AM
Subject: [mcclim-devel] Command translator question


|
| I'm trying to define a presentation command translator which will
| invoke 'describe presentation' on specific types. Unfortunately it
| doesn't work (or at least, works in a way that I'm not expecting so if
| it's working it's not doing what I want ;-)
|
| Looking at the translators defined in the Listener and in
| builtin-commands.lisp hasn't helped. Here's the translator:
|
| (define-presentation-to-command-translator port-select-to-command  ;
| name
|    (t                     ; from-type
|     com-describe          ; command-name - maybe
| com-describe-presentation?
|     global-command-table  ; command table containing command
|     :gesture :select      ; activate on :select (left-button click)
|     ;; :tester ...
|     :documentation
|     "Invoke the 'describe presentation' command on the selected
| presentation"
|     :pointer-documentation ((object stream) (format stream "Describe ~A"
| object))
|     :menu t               ; command should appear in popped-up menus
|     ;; :priority ...
|     :echo nil)            ; don't echo the command when it is invoked
|    ;; arglist must be a subset (using string-equal) of:
|    ;;    (object presentation context-type frame event window x y)
|    (object)
|    ;; body of translator; returns a list of the arguments to the command
|    ;; named by command-name.
|    (list object))
|
| In case I was providing the wrong 'from-type' I changed it to T (all
| types, I hope). I've written this using the Beagle back end but it
| doesn't work for me when run under CLX either...
|
| Any suggestions would be appreciated, I'm obviously missing something...

Well, you have not defined COM-DESCRIBE in the attached glimpse.lisp.
I have never tried using the global command table in translators so I can't
say
for sure that it should work. I have always used the frame command table for
translators.

Just a nit, but I don't ever recall seeing the idiom (setf  x (push thing
x)) used
elsewhere, just (push thing x) will do.

Another nit, you should avoid using unxported CLIMI features.
MAP-OVER-PORTS instead of  CLIMI::*ALL-PORTS*
MAP-OVER-GRAFTS instead of CLIMI::PORT-GRAFTS
would make it possible for me to try this code in a "classic CLIM".

Paul





From amoroso at mclink.it  Sat Apr 30 14:17:06 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sat, 30 Apr 2005 16:17:06 +0200
Subject: [mcclim-devel] Command translator question
References: <68D6EE3A-B955-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <87wtqktkm5.fsf@plato.moon.paoloamoroso.it>

Duncan Rose <duncan at robotcat.demon.co.uk> writes:

> I'm trying to define a presentation command translator which will
> invoke 'describe presentation' on specific types. Unfortunately it
> doesn't work (or at least, works in a way that I'm not expecting so if

The problem seems related more to the presentations than the
translators, but I can't isolate it.

Concerning your comment in the Glimpse code:

  ;;; ::FIXME:: if :graph is specified here, we have problems because the graph
  ;;;           doesn't fit on the pane, but the scroll bar updates and pane
  ;;; resizing DON'T HAPPEN! At least when we output text, the pane is sized so
  ;;; it can be scrolled!

This is probably a known issue:

  http://mcclim.cliki.net/Bug#table-formatting-scrolling

with workarounds:

  http://common-lisp.net/pipermail/mcclim-devel/2004-December/003567.html
  http://common-lisp.net/pipermail/mcclim-devel/2004-December/003573.html


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


From pw at snoopy.mv.com  Sat Apr 30 14:48:52 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Sat, 30 Apr 2005 10:48:52 -0400
Subject: [mcclim-devel] Command translator question
References: <68D6EE3A-B955-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<003501c54d84$e9aa2170$0201a8c0@moby>
Message-ID: <000701c54d93$ba521540$0201a8c0@moby>

| | Any suggestions would be appreciated, I'm obviously missing something...
|
| Well, you have not defined COM-DESCRIBE in the attached glimpse.lisp.
| I have never tried using the global command table in translators so I
can't
| say
| for sure that it should work. I have always used the frame command table
for
| translators.

Seems like COM-DESCRIBE is in McCLIM but not Lispworks CLIM.
I defined that, and worked around the CLIMI internal stuff using CLIM
MAP-OVER-x
functions. Having done that and a bit more hacking (below) your code worked,
meaning that command "Show Sheet Hierarchy" displayed a tree of sheet
objects
that were mouse sensitive for COM-DESCRIBE.

Some other things:

(find-pane-named *application-frame* 'app) returned a SPACING-PANE.
I had to use GET-FRAME-PANE instead.

Sometimes SHEET-CHILDREN popped a NO-APPLICABLE-METHOD
for objects for which SHEETP returned T. The only way I could find to
proceed
was to define dummy methods for classes
  WIN32-LIB-CLIM::WIN32- TOP-LEVEL-MENU
  WIN32-LIB-CLIM::WIN32-SCROLLBAR-PANE
  WIN32-LIB-CLIM:: WIN32-POINTER-DOCUMENTATION-PANE

Obviously these won't be a problem in McCLIM but it does indicate probing
too low into the implementation might be problematic.

Paul




From rpgoldman at real-time.com  Sat Apr 30 15:04:13 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Sat, 30 Apr 2005 10:04:13 -0500
Subject: [mcclim-devel] [really display sizing] Re: Command translator
	question
In-Reply-To: <87wtqktkm5.fsf@plato.moon.paoloamoroso.it>
References: <68D6EE3A-B955-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<87wtqktkm5.fsf@plato.moon.paoloamoroso.it>
Message-ID: <17011.40557.98552.373288@gargle.gargle.HOWL>

>>>>> "PA" == Paolo Amoroso <amoroso at mclink.it> writes:

    PA> Duncan Rose <duncan at robotcat.demon.co.uk> writes:
    >> I'm trying to define a presentation command translator which will
    >> invoke 'describe presentation' on specific types. Unfortunately it
    >> doesn't work (or at least, works in a way that I'm not expecting so if

    PA> The problem seems related more to the presentations than the
    PA> translators, but I can't isolate it.

    PA> Concerning your comment in the Glimpse code:

    PA>   ;;; ::FIXME:: if :graph is specified here, we have problems because the graph
    PA>   ;;;           doesn't fit on the pane, but the scroll bar updates and pane
    PA>   ;;; resizing DON'T HAPPEN! At least when we output text, the pane is sized so
    PA>   ;;; it can be scrolled!

    PA> This is probably a known issue:

    PA>   http://mcclim.cliki.net/Bug#table-formatting-scrolling

I just yesterday had a long conversation on #lisp with Andy H about
this, which was very helpful.  At least for format-graph-from-roots, I
needed to explicitly call

change-space-requirements

We couldn't determine (well, Andy couldn't, and my attempt was
cursory) whether the spec required format-graph-from-roots to change
its stream's space requirements or not.

Best,
R


From moore at bricoworks.com  Sat Apr 30 15:30:41 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Sat, 30 Apr 2005 17:30:41 +0200
Subject: [mcclim-devel] Command translator question
In-Reply-To: <68D6EE3A-B955-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
References: <68D6EE3A-B955-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <f34c787fe9bdfe62bfc3d5c1928ae3b2@bricoworks.com>

Does this work if you give the translator a high priority, like 100? 
There might be some weirdness with the default translator in the global 
command table.

Tim
On Apr 30, 2005, at 10:54 AM, Duncan Rose wrote:

>
> I'm trying to define a presentation command translator which will 
> invoke 'describe presentation' on specific types. Unfortunately it 
> doesn't work (or at least, works in a way that I'm not expecting so if 
> it's working it's not doing what I want ;-)
>
> Looking at the translators defined in the Listener and in 
> builtin-commands.lisp hasn't helped. Here's the translator:
>
> (define-presentation-to-command-translator port-select-to-command  ; 
> name
>   (t                     ; from-type
>    com-describe          ; command-name - maybe 
> com-describe-presentation?
>    global-command-table  ; command table containing command
>    :gesture :select      ; activate on :select (left-button click)
>    ;; :tester ...
>    :documentation
>    "Invoke the 'describe presentation' command on the selected 
> presentation"
>    :pointer-documentation ((object stream) (format stream "Describe 
> ~A" object))
>    :menu t               ; command should appear in popped-up menus
>    ;; :priority ...
>    :echo nil)            ; don't echo the command when it is invoked
>   ;; arglist must be a subset (using string-equal) of:
>   ;;    (object presentation context-type frame event window x y)
>   (object)
>   ;; body of translator; returns a list of the arguments to the command
>   ;; named by command-name.
>   (list object))
>
> In case I was providing the wrong 'from-type' I changed it to T (all 
> types, I hope). I've written this using the Beagle back end but it 
> doesn't work for me when run under CLX either...
>
> Any suggestions would be appreciated, I'm obviously missing 
> something...
>
> I've attached the complete code for context in case it's helpful.
>
> -Duncan
>
> <glimpse.lisp>_______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From duncan at robotcat.demon.co.uk  Sat Apr 30 15:55:09 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 16:55:09 +0100
Subject: [mcclim-devel] Command translator question
In-Reply-To: <f34c787fe9bdfe62bfc3d5c1928ae3b2@bricoworks.com>
Message-ID: <3A6EBE5F-B990-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Saturday, April 30, 2005, at 04:30 PM, Timothy Moore wrote:

> Does this work if you give the translator a high priority, like 100? 
> There might be some weirdness with the default translator in the 
> global command table.
>

Unfortunately changing the priority seems to make no difference.

-Duncan


> Tim
> On Apr 30, 2005, at 10:54 AM, Duncan Rose wrote:
>
>>
>> I'm trying to define a presentation command translator which will 
>> invoke 'describe presentation' on specific types. Unfortunately it 
>> doesn't work (or at least, works in a way that I'm not expecting so 
>> if it's working it's not doing what I want ;-)
>>
>> Looking at the translators defined in the Listener and in 
>> builtin-commands.lisp hasn't helped. Here's the translator:
>>
>> (define-presentation-to-command-translator port-select-to-command  ; 
>> name
>>   (t                     ; from-type
>>    com-describe          ; command-name - maybe 
>> com-describe-presentation?
>>    global-command-table  ; command table containing command
>>    :gesture :select      ; activate on :select (left-button click)
>>    ;; :tester ...
>>    :documentation
>>    "Invoke the 'describe presentation' command on the selected 
>> presentation"
>>    :pointer-documentation ((object stream) (format stream "Describe 
>> ~A" object))
>>    :menu t               ; command should appear in popped-up menus
>>    ;; :priority ...
>>    :echo nil)            ; don't echo the command when it is invoked
>>   ;; arglist must be a subset (using string-equal) of:
>>   ;;    (object presentation context-type frame event window x y)
>>   (object)
>>   ;; body of translator; returns a list of the arguments to the 
>> command
>>   ;; named by command-name.
>>   (list object))
>>
>> In case I was providing the wrong 'from-type' I changed it to T (all 
>> types, I hope). I've written this using the Beagle back end but it 
>> doesn't work for me when run under CLX either...
>>
>> Any suggestions would be appreciated, I'm obviously missing 
>> something...
>>
>> I've attached the complete code for context in case it's helpful.
>>
>> -Duncan
>>
>> <glimpse.lisp>_______________________________________________
>> mcclim-devel mailing list
>> mcclim-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From duncan at robotcat.demon.co.uk  Sat Apr 30 16:01:16 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 17:01:16 +0100
Subject: [mcclim-devel] Command translator question
In-Reply-To: <87wtqktkm5.fsf@plato.moon.paoloamoroso.it>
Message-ID: <15A0E328-B991-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


Yes, this fixes it. I might dig at this a little deeper some time, it
doesn't feel quite right to have to manually update space requirements
on a sheet that is a scroller viewport; but then, with the work
around, it's no big deal.

Thanks to 'R' (rpgoldman) for pointing this out too.

-Duncan


On Saturday, April 30, 2005, at 03:17 PM, Paolo Amoroso wrote:

> Duncan Rose <duncan at robotcat.demon.co.uk> writes:
>
>> I'm trying to define a presentation command translator which will
>> invoke 'describe presentation' on specific types. Unfortunately it
>> doesn't work (or at least, works in a way that I'm not expecting so if
>
> The problem seems related more to the presentations than the
> translators, but I can't isolate it.
>
> Concerning your comment in the Glimpse code:
>
>   ;;; ::FIXME:: if :graph is specified here, we have problems because  
> the graph
>   ;;;           doesn't fit on the pane, but the scroll bar updates  
> and pane
>   ;;; resizing DON'T HAPPEN! At least when we output text, the pane is  
> sized so
>   ;;; it can be scrolled!
>
> This is probably a known issue:
>
>   http://mcclim.cliki.net/Bug#table-formatting-scrolling
>
> with workarounds:
>
>    
> http://common-lisp.net/pipermail/mcclim-devel/2004-December/> 003567.html
>    
> http://common-lisp.net/pipermail/mcclim-devel/2004-December/> 003573.html
>
>
> Paolo
> -- 
> Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From duncan at robotcat.demon.co.uk  Sat Apr 30 16:31:45 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 17:31:45 +0100
Subject: [mcclim-devel] Command translator question
In-Reply-To: <003501c54d84$e9aa2170$0201a8c0@moby>
Message-ID: <57939FA8-B995-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Saturday, April 30, 2005, at 02:02 PM, Paul Werkowski wrote:

>
> ----- Original Message -----
> From: "Duncan Rose" <duncan at robotcat.demon.co.uk>
> To: <mcclim-devel at common-lisp.net>
> Sent: Saturday, April 30, 2005 4:54 AM
> Subject: [mcclim-devel] Command translator question
>
>
> |
> | I'm trying to define a presentation command translator which will
> | invoke 'describe presentation' on specific types. Unfortunately it
> | doesn't work (or at least, works in a way that I'm not expecting so 
> if
> | it's working it's not doing what I want ;-)
> |
> | Looking at the translators defined in the Listener and in
> | builtin-commands.lisp hasn't helped. Here's the translator:
> |
> | (define-presentation-to-command-translator port-select-to-command  ;
> | name
> |    (t                     ; from-type
> |     com-describe          ; command-name - maybe
> | com-describe-presentation?
> |     global-command-table  ; command table containing command
> |     :gesture :select      ; activate on :select (left-button click)
> |     ;; :tester ...
> |     :documentation
> |     "Invoke the 'describe presentation' command on the selected
> | presentation"
> |     :pointer-documentation ((object stream) (format stream "Describe 
> ~A"
> | object))
> |     :menu t               ; command should appear in popped-up menus
> |     ;; :priority ...
> |     :echo nil)            ; don't echo the command when it is invoked
> |    ;; arglist must be a subset (using string-equal) of:
> |    ;;    (object presentation context-type frame event window x y)
> |    (object)
> |    ;; body of translator; returns a list of the arguments to the 
> command
> |    ;; named by command-name.
> |    (list object))
> |
> | In case I was providing the wrong 'from-type' I changed it to T (all
> | types, I hope). I've written this using the Beagle back end but it
> | doesn't work for me when run under CLX either...
> |
> | Any suggestions would be appreciated, I'm obviously missing 
> something...
>
> Well, you have not defined COM-DESCRIBE in the attached glimpse.lisp.
> I have never tried using the global command table in translators so I 
> can't
> say
> for sure that it should work. I have always used the frame command 
> table for
> translators.
>

This might be a safer way of doing it but I know there's a com-describe 
in the global command table and I'd like to use it; however, if that's 
not portable it might be better if I didn't.

I'm thinking at the moment it might be necessary for the command table 
for glimpse (defaults to 'glimpse' I believe) to :inherit-from the 
global command table maybe. There's a note for 
'define-presetation-translator' that the translator will only be 
applicable when the command table provided as an argument in the call 
is one of the command tables from which the application frame's command 
table inherits. I don't know if this is a restriction for 
'define-presentation-to-command-translator' but I'm going to 
investigate this some more.

> Just a nit, but I don't ever recall seeing the idiom (setf  x (push 
> thing
> x)) used
> elsewhere, just (push thing x) will do.
>

When I originally wrote the code I was using LIST I think, and the 
setf's just got left in.

> Another nit, you should avoid using unxported CLIMI features.
> MAP-OVER-PORTS instead of  CLIMI::*ALL-PORTS*
> MAP-OVER-GRAFTS instead of CLIMI::PORT-GRAFTS
> would make it possible for me to try this code in a "classic CLIM".
>

I'll change the code to be more compliant, thanks for pointing that out.

Originally the code was only intended to illustrate that application 
frames all generated a 'raised pane' that contains a 'menu pane' even 
if the application itself didn't use the menus. I then realized I could 
expand it somewhat to show me what was going on in the Beagle back end 
(with mirror regions and transformations etc.) a bit more easily than 
poking with the Listener; so it's currently very much a work in 
progress.

-Duncan


> Paul
>
>
>



From duncan at robotcat.demon.co.uk  Sat Apr 30 16:58:52 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 17:58:52 +0100
Subject: [mcclim-devel] Command translator question
In-Reply-To: <000701c54d93$ba521540$0201a8c0@moby>
Message-ID: <2131D57A-B999-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Saturday, April 30, 2005, at 03:48 PM, Paul Werkowski wrote:

> | | Any suggestions would be appreciated, I'm obviously missing 
> something...
> |
> | Well, you have not defined COM-DESCRIBE in the attached glimpse.lisp.
> | I have never tried using the global command table in translators so I
> can't
> | say
> | for sure that it should work. I have always used the frame command 
> table
> for
> | translators.
>
> Seems like COM-DESCRIBE is in McCLIM but not Lispworks CLIM.

Now you mention it the spec, from what I can remember, is very quiet 
about
what commands are available in any given CLIM implementation. This 
probably
means that for truly portable code, it's not possible to rely on any
commands existing and all should therefore be defined in the application
itself.

That seems like it could be quite a chore...

> I defined that, and worked around the CLIMI internal stuff using CLIM
> MAP-OVER-x
> functions. Having done that and a bit more hacking (below) your code 
> worked,
> meaning that command "Show Sheet Hierarchy" displayed a tree of sheet
> objects
> that were mouse sensitive for COM-DESCRIBE.
>

This is good news, I think. Or maybe not. Hrmmm.

> Some other things:
>
> (find-pane-named *application-frame* 'app) returned a SPACING-PANE.
> I had to use GET-FRAME-PANE instead.

 From the spec:
"
get-frame-pane  frame pane-name  [Generic function]
Returns the named CLIM stream pane in the frame frame whose name is 
pane-name .

find-pane-named  frame pane-name  [Generic function]
Returns the pane in the frame frame whose name is pane-name . This can 
return any type of pane, not just CLIM stream panes.
"

I had assumed (presumably incorrectly for Lispworks CLIM, at least) 
that a pane defined as being :interactor or :application would be, 
well, an interactor or an application pane (which are stream panes). I 
hadn't realized this might not be portable, but have changed the code 
accordingly.

>
> Sometimes SHEET-CHILDREN popped a NO-APPLICABLE-METHOD
> for objects for which SHEETP returned T. The only way I could find to
> proceed
> was to define dummy methods for classes
>   WIN32-LIB-CLIM::WIN32- TOP-LEVEL-MENU
>   WIN32-LIB-CLIM::WIN32-SCROLLBAR-PANE
>   WIN32-LIB-CLIM:: WIN32-POINTER-DOCUMENTATION-PANE
>
> Obviously these won't be a problem in McCLIM but it does indicate 
> probing
> too low into the implementation might be problematic.
>

Ouch... I could check for the method existing on the object, but I 
suspect this is a specification violation on the part of Lispworks... 
the spec is very clear that "All sheet objects must implement or 
inherit methods for each of these generic functions" (section 7.2.1) 
immediately above the description of SHEET-CHILDREN.

This is all very interesting to me, thank you for taking the time to 
investigate it.

-Duncan


> Paul
>
>



From duncan at robotcat.demon.co.uk  Sat Apr 30 17:54:05 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sat, 30 Apr 2005 18:54:05 +0100
Subject: [mcclim-devel] Command translator question
In-Reply-To: <57939FA8-B995-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <D7CE07E9-B9A0-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>

>

--->8--- snipped for brevity --->8---

> I'm thinking at the moment it might be necessary for the command table 
> for glimpse (defaults to 'glimpse' I believe) to :inherit-from the 
> global command table maybe. There's a note for 
> 'define-presetation-translator' that the translator will only be 
> applicable when the command table provided as an argument in the call 
> is one of the command tables from which the application frame's 
> command table inherits. I don't know if this is a restriction for 
> 'define-presentation-to-command-translator' but I'm going to 
> investigate this some more.

--->8--- snipped for brevity --->8---

The note mentioned above is in the Allegro CLIM UG btw, not in the 
spec. (and not in Lispworks UG either) so I don't know if its relevant.

-Duncan