From csr21 at cantab.net  Tue Feb  6 14:17:33 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Tue, 06 Feb 2007 14:17:33 +0000
Subject: [mcclim-devel] Drei and input focus
In-Reply-To: <87y7nqf23c.fsf@cantab.net> (Christophe Rhodes's message of "Fri, 
	26 Jan 2007 11:40:23 +0000")
References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk>
	<87tzyootcq.fsf@sigkill.dk> <874pqnqs53.fsf@cantab.net>
	<31ffd3c40701191322l14d146efpb28019e49c200c2f@mail.gmail.com>
	<871wljhw0w.fsf@cantab.net>
	<31ffd3c40701251024p665ce748u77135b9a831c5753@mail.gmail.com>
	<87y7nqf23c.fsf@cantab.net>
Message-ID: <87tzxz5q0y.fsf@cantab.net>

Christophe Rhodes <csr21 at cantab.net> writes:

> unsupportable API... on that subject, what implications does this have
> for other backends?

I attach a patch which reworks my previous stuff, and implements the
same behaviour (as far as I can tell) for the gtkairo backend as well
as the CLX backend.

* PORT-KEYBOARD-INPUT-FOCUS, (SETF PORT-KEYBOARD-INPUT-FOCUS):
  trampoline to PORT-FRAME-KEYBOARD-INPUT-FOCUS and (SETF ...).  The
  interpretation of this operator is to set the keyboard focus on a
  per-frame basis, and not to interact with any window manager to grab
  the focus from potentially unrelated applications.

* PORT-FRAME-KEYBOARD-INPUT-FOCUS / (SETF ...): per-backend methods,
  specialized on the port, for querying and setting the frame's focus
  sheet.  Implemented in CLX (and Null) backend using
  FRAME-PROPERTIES; in gtkairo backend using gtk_window_get_focus()
  and gtk_widget_grab_focus().

* various editor gadgets: no longer do keyboard handling in
  [dis]armed-callback; handle-event methods for assigning focus.
  frame-pointer-button-press-handler method likewise for
  INTERACTOR-PANEs.

Any comments?

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: focus.diff
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070206/45c7183a/attachment.ksh>
-------------- next part --------------

Cheers,

Christophe

From ch-mcclim at bobobeach.com  Sat Feb 10 18:18:42 2007
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Sat, 10 Feb 2007 10:18:42 -0800
Subject: [mcclim-devel] presentation example from docs
Message-ID: <3F16FCC9-F2C5-4338-8B34-CA2F40EFD7F9@bobobeach.com>

Hi mcclim devels,

Well, I'm finally getting around to learning how to write a mcclim  
app. For a change, I figured i'd read the documentation first this time.

Granted this is a minor gripe but when I run the presentation example  
given in the manual, the manual says I should see that output "the 15  
or The third month" when I click on the shown objects. In fact I get  
"the 15 of THE". Is the manual in error or is something wrong here?

Thanks,

Cyrus



From athas at sigkill.dk  Sat Feb 10 21:12:31 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 10 Feb 2007 22:12:31 +0100
Subject: [mcclim-devel] presentation example from docs
In-Reply-To: <3F16FCC9-F2C5-4338-8B34-CA2F40EFD7F9@bobobeach.com> (Cyrus
	Harmon's message of "Sat, 10 Feb 2007 10:18:42 -0800")
References: <3F16FCC9-F2C5-4338-8B34-CA2F40EFD7F9@bobobeach.com>
Message-ID: <87vei9btts.fsf@lambda.athas.dyndns.dk>

Cyrus Harmon <ch-mcclim at bobobeach.com> writes:

> Granted this is a minor gripe but when I run the presentation example
> given in the manual, the manual says I should see that output "the 15
> or The third month" when I click on the shown objects. In fact I get
> "the 15 of THE". Is the manual in error or is something wrong here?

This is a bug that Goatee is able to handle, but Drei is not. It
happens due to the default present/accept methods for presentation
types (which is quite a kludge in itself) that just invokes print/read
on the objects and try to wing it that way. This works very poorly,
since the presentation of a string will then be "string", but that
can't be read in by the corresponding default accept method, because
it uses `read-token' to get the string, and that removes the quotes
(so it'll be interpreted as a symbol by the reader, but that won't
work well if the string has whitespace in it, this is why you only see
the first word, and in uppercase). Goatee is somehow able to detect
that the result of presenting the object to a string is not acceptable
back in, and thus puts in an "accept extent" (roughly, a reference to
the actual object that is returned instead of attempting to parse the
string). I don't quite know why Goatee detects it, it's probably an
accident. :-)

In any case, the central problem is accepting textual input of
presentation types that do not have accept methods. Bad, bad, bad.

-- 
\  Troels
/\ Henriksen


From athas at sigkill.dk  Sat Feb 10 21:33:30 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 10 Feb 2007 22:33:30 +0100
Subject: [mcclim-devel] presentation example from docs
In-Reply-To: <87vei9btts.fsf@lambda.athas.dyndns.dk> (Troels Henriksen's
	message of "Sat, 10 Feb 2007 22:12:31 +0100")
References: <3F16FCC9-F2C5-4338-8B34-CA2F40EFD7F9@bobobeach.com>
	<87vei9btts.fsf@lambda.athas.dyndns.dk>
Message-ID: <87r6sxbsut.fsf@lambda.athas.dyndns.dk>

Troels Henriksen <athas at sigkill.dk> writes:

> In any case, the central problem is accepting textual input of
> presentation types that do not have accept methods. Bad, bad, bad.

This particular issue could fortunately be fixed rather easily by
using inheritance and fixing the present method for strings. Should
work now in Drei as well as Goatee.

-- 
\  Troels
/\ Henriksen


From ch-mcclim at bobobeach.com  Sat Feb 10 23:18:32 2007
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Sat, 10 Feb 2007 15:18:32 -0800
Subject: [mcclim-devel] while I'm picking minor mcclim nits...
Message-ID: <8F48F884-C1F4-4683-8C20-9A216310E573@bobobeach.com>


This fixes a few compile warnings. Of course, I have no idea what  
this does :) but the changes look like the right thing to do.

Cyrus

--- presentation-defs.lisp	10 Feb 2007 15:11:02 -0800	1.71
+++ presentation-defs.lisp	10 Feb 2007 15:17:12 -0800	
@@ -1121,11 +1121,11 @@
			   &key view
			   (default nil defaultp)
			   (default-type nil default-type-p)
-			   activation-gestures
+			   (activation-gestures nil activationsp)
			   (additional-activation-gestures
			    nil
			    additional-activations-p)
-			   delimiter-gestures
+			   (delimiter-gestures nil delimitersp)
			   (additional-delimiter-gestures
			    nil
			    additional-delimiters-p)
@@ -1136,13 +1136,11 @@
    (with-activation-gestures ((if additional-activations-p
				 additional-activation-gestures
				 activation-gestures)
-			     :override activationsp)
-    (with-delimiter-gestures ((if additional-delimiters-p
+			     :override activationsp)    (with-delimiter-gestures ((if  
additional-delimiters-p
				  additional-delimiter-gestures
				  delimiter-gestures)
			      :override delimitersp)))
-  (when (or (zerop (- end start))
-	    (let ((maybe-end))))
+  (when (or (zerop (- end start)))
      (if defaultp
	(return-from accept-from-string (values default
						(if default-type-p



From ch-mcclim at bobobeach.com  Sat Feb 10 23:30:59 2007
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Sat, 10 Feb 2007 15:30:59 -0800
Subject: [mcclim-devel] presentation example from docs
In-Reply-To: <87vei9btts.fsf@lambda.athas.dyndns.dk>
References: <3F16FCC9-F2C5-4338-8B34-CA2F40EFD7F9@bobobeach.com>
	<87vei9btts.fsf@lambda.athas.dyndns.dk>
Message-ID: <B9633FEE-836E-4547-B2C8-1EDB9BF6B128@bobobeach.com>

Ok, so while this fixes things, it has the unfortunate effect of  
putting the text "The third month" in quotes in the prompt box. Not a  
showstopper, obviously, but not as nice as one would like for a piece  
of expository code.

Also, the arguments prompting thing in general just feels really  
hokey. Lots of little bugs. I imagine they could be cleaned up, but  
this is one of thing that scared me away from mcclim initially and I  
imagine others might feel similarly. Not to be too negative, but I  
want to 1) point it out and 2) learn enough so that I might be able  
to do something about it.

Thanks,

Cyrus

On Feb 10, 2007, at 1:12 PM, Troels Henriksen wrote:

> Cyrus Harmon <ch-mcclim at bobobeach.com> writes:
>
>> Granted this is a minor gripe but when I run the presentation example
>> given in the manual, the manual says I should see that output "the 15
>> or The third month" when I click on the shown objects. In fact I get
>> "the 15 of THE". Is the manual in error or is something wrong here?
>
> This is a bug that Goatee is able to handle, but Drei is not. It
> happens due to the default present/accept methods for presentation
> types (which is quite a kludge in itself) that just invokes print/read
> on the objects and try to wing it that way. This works very poorly,
> since the presentation of a string will then be "string", but that
> can't be read in by the corresponding default accept method, because
> it uses `read-token' to get the string, and that removes the quotes
> (so it'll be interpreted as a symbol by the reader, but that won't
> work well if the string has whitespace in it, this is why you only see
> the first word, and in uppercase). Goatee is somehow able to detect
> that the result of presenting the object to a string is not acceptable
> back in, and thus puts in an "accept extent" (roughly, a reference to
> the actual object that is returned instead of attempting to parse the
> string). I don't quite know why Goatee detects it, it's probably an
> accident. :-)
>
> In any case, the central problem is accepting textual input of
> presentation types that do not have accept methods. Bad, bad, bad.
>
> -- 
> \  Troels
> /\ Henriksen



From athas at sigkill.dk  Sun Feb 11 00:24:24 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Sun, 11 Feb 2007 01:24:24 +0100
Subject: [mcclim-devel] presentation example from docs
In-Reply-To: <B9633FEE-836E-4547-B2C8-1EDB9BF6B128@bobobeach.com> (Cyrus
	Harmon's message of "Sat, 10 Feb 2007 15:30:59 -0800")
References: <3F16FCC9-F2C5-4338-8B34-CA2F40EFD7F9@bobobeach.com>
	<87vei9btts.fsf@lambda.athas.dyndns.dk>
	<B9633FEE-836E-4547-B2C8-1EDB9BF6B128@bobobeach.com>
Message-ID: <87mz3lbkxz.fsf@lambda.athas.dyndns.dk>

Cyrus Harmon <ch-mcclim at bobobeach.com> writes:

> Also, the arguments prompting thing in general just feels really
> hokey. Lots of little bugs. I imagine they could be cleaned up, but
> this is one of thing that scared me away from mcclim initially and I
> imagine others might feel similarly. Not to be too negative, but I
> want to 1) point it out and 2) learn enough so that I might be able
> to do something about it.

Indeed, it's all very brittle. Unfortunately, it's hard to write
something more robust because you're not (theoretically) allowed to
associate any state with the input-editing-stream that cannot be
inferred from the buffer contents. I tried to put a limit on the
foot-shooter ammunition by preventing the user from editing previous
input in Drei, but numerous protests suggest that this might not be a
good idea. :-)

I hope someone can figure out how to write something robust on top of
the input-editing-stream protocol, because from a programmer
perspective, the idea of treating input editing as stream I/O is
pretty cool and neat (and makes writing accept methods quite nice).

-- 
\  Troels
/\ Henriksen


From _deepfire at feelingofgreen.ru  Mon Feb 12 19:58:15 2007
From: _deepfire at feelingofgreen.ru (Samium Gromoff)
Date: Mon, 12 Feb 2007 22:58:15 +0300
Subject: [mcclim-devel] Gtkairo/demodemo bug
In-Reply-To: <mailman.62.1171298804.30612.mcclim-devel@common-lisp.net>
References: <mailman.62.1171298804.30612.mcclim-devel@common-lisp.net>
Message-ID: <877iunno6g.wl@betelheise.deep.net>

When trying out the drawing part of demodemo, with mcclim using gtkairo,
after drawing some lines i decided to draw an ellipse.

This had the following effect:

Attempt to invert the probably singular transformation #<CLIM-INTERNALS::STANDARD-HAIRY-TRANSFORMATION 0 0 0 -2 156 324>.
   [Condition of type CLIM:SINGULAR-TRANSFORMATION]

Restarts:
 0: [USE-VALUE] Supply a transformation to use instead of the inverse.
 1: [ABORT] Return to application command loop
 2: [ABORT] Return to application command loop
 3: [ABORT] Return to SLIME's top level.
 4: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {AFDE919}>)

Backtrace:
  0: ((SB-PCL::FAST-METHOD CLIM:INVERT-TRANSFORMATION
       (CLIM-INTERNALS::STANDARD-TRANSFORMATION))
      #<unavailable argument>
      #<unavailable argument>
      #<CLIM-INTERNALS::STANDARD-HAIRY-TRANSFORMATION 0 0 0 -2 156 324>)
  1: ((SB-PCL::FAST-METHOD CLIM:INVERT-TRANSFORMATION :AROUND
       (CLIM-INTERNALS::CACHED-INVERSE-TRANSFORMATION-MIXIN))
      (#(0) . #())
      #S(SB-PCL::FAST-METHOD-CALL
         :FUNCTION #<FUNCTION #>
         :PV-CELL NIL
         :NEXT-METHOD-CALL NIL
         :ARG-INFO (1))
      #<CLIM-INTERNALS::STANDARD-HAIRY-TRANSFORMATION 0 0 0 -2 156 324>)
  2: (CLIM-GTKAIRO::SYNC-TRANSFORMATION
      #<CLIM-GTKAIRO::CAIRO-MEDIUM {DE8A9B9}>
      #<CLIM-INTERNALS::STANDARD-HAIRY-TRANSFORMATION 0 0 0 -2 156 324>)
  3: ((LAMBDA ()))
  4: ((LAMBDA ()))
  5: (CLIM-GTKAIRO::INVOKE-WITH-GTK #<CLOSURE (LAMBDA #) {DD6018D}>)
  6: ((SB-PCL::FAST-METHOD
       CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL
       (CLIM:MEDIUM #1="#<...>" . #1#))
      #<unused argument>
      #<unused argument>
      #<CLIM-GTKAIRO::CAIRO-MEDIUM {DE8A9B9}>
      #<CLIM-DEMO::CANVAS-PANE CLIM-DEMO::CANVAS {A8BB111}>
      #<CLOSURE (FLET CLIM-INTERNALS::GRAPHICS-OP) {DD59E2D}>
      :INK
      #<CLIM-INTERNALS::NAMED-COLOR "blue"> ..)
  7: ((SB-PCL::FAST-METHOD CLIM:INVOKE-WITH-OUTPUT-RECORDING-OPTIONS
       (CLIM:OUTPUT-RECORDING-STREAM T T T))
      #<unavailable argument>
      #<unavailable argument>
      #<CLIM-DEMO::CANVAS-PANE CLIM-DEMO::CANVAS {A8BB111}>
      #<CLOSURE (FLET #:CONTINUATION160) {DD59B5D}>
      NIL
      T)
  8: ((LAMBDA
          (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
           SB-PCL::.ARG1. SB-PCL::.ARG2. SB-PCL::.ARG3.))
      #<unavailable argument>
      #<unavailable argument>
      #<CLIM-INTERNALS::FRAME-TRACKING-POINTER-STATE {DD56F69}>
      #<CLIM:POINTER-MOTION-EVENT {DD51929}>
      156
      322)
  9: ((FLET CLIM-INTERNALS::DO-TRACKING))
 10: ((LABELS #:G103) #<CLIM-GTKAIRO::CAIRO-MEDIUM {DE8A9B9}>)
 11: ((LAMBDA
          (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL.
           #1="#<...>" . #1#))
      #<unused argument>
      #<unused argument>
      #<CLIM-INTERNALS::FRAME-TRACKING-POINTER-STATE {DD56F69}>
      #<CLIM-DEMO::CLIM-FIG {A8A9AC1}>
      #<CLIM-DEMO::CANVAS-PANE CLIM-DEMO::CANVAS {A8BB111}>
      -308893239
      8)
 12: (CLIM-DEMO::HANDLE-DRAW-OBJECT
      #<CLIM-DEMO::CANVAS-PANE CLIM-DEMO::CANVAS {A8BB111}>
      156
      324)
 13: ((SB-PCL::FAST-METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL
       (CLIM:APPLICATION-FRAME))
      #<unused argument>
      #<unused argument>
      #<CLIM-DEMO::CLIM-FIG {A8A9AC1}>
      :COMMAND-PARSER
      CLIM:COMMAND-LINE-COMMAND-PARSER
      :COMMAND-UNPARSER
      CLIM:COMMAND-LINE-COMMAND-UNPARSER
      :PARTIAL-COMMAND-PARSER ..)
 14: ((SB-PCL::FAST-METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL
       (CLIM:APPLICATION-FRAME))
      #<unavailable argument>
      #<unavailable argument>
      #<CLIM-DEMO::CLIM-FIG {A8A9AC1}>)
 15: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL
       (CLIM:APPLICATION-FRAME))
      #<unused argument>
      #<unused argument>
      #<CLIM-DEMO::CLIM-FIG {A8A9AC1}>)
 16: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND
       (#1="#<...>" . #1#))
      #<unused argument>
      #S(SB-PCL::FAST-METHOD-CALL
         :FUNCTION #<FUNCTION #>
         :PV-CELL NIL
         :NEXT-METHOD-CALL NIL
         :ARG-INFO (1 . T))
      #<CLIM-DEMO::CLIM-FIG {A8A9AC1}>)
 17: ((LAMBDA (&REST IGNORE)))
 18: (CLIM-INTERNALS::INVOKE-CALLBACK
      #<CLIM-GTKAIRO::GTK-BUTTON "(Unnamed Pane)" {DDAED39}>
      #<CLOSURE (LAMBDA #) {DDD0365}>)
 19: (CLIM-EXTENSIONS:SIMPLE-EVENT-LOOP #<CLIM-DEMO::DEMODEMO {DC5B199}>)
 20: (CLIM-EXTENSIONS:SIMPLE-EVENT-LOOP #<CLIM-DEMO::DEMODEMO {DC5B199}>)
 21: ((SB-PCL::FAST-METHOD CLIM:READ-FRAME-COMMAND :AROUND
       (#1="#<...>" . #1#))
      #<unused argument>
      #S(SB-PCL::FAST-METHOD-CALL
         :FUNCTION #<FUNCTION #>
         :PV-CELL NIL
         :NEXT-METHOD-CALL NIL
         :ARG-INFO (1 . T))
      #<CLIM-DEMO::DEMODEMO {DC5B199}>
      :STREAM ..)
 22: ((SB-PCL::FAST-METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL
       (CLIM:APPLICATION-FRAME))
      #<unused argument>
      #<unused argument>
      #<CLIM-DEMO::DEMODEMO {DC5B199}>
      :COMMAND-PARSER
      CLIM:COMMAND-LINE-COMMAND-PARSER
      :COMMAND-UNPARSER
      CLIM:COMMAND-LINE-COMMAND-UNPARSER
      :PARTIAL-COMMAND-PARSER ..)
 23: ((SB-PCL::FAST-METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL
       (CLIM:APPLICATION-FRAME))
      #<unavailable argument>
      #<unavailable argument>
      #<CLIM-DEMO::DEMODEMO {DC5B199}>)
 24: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL
       (CLIM:APPLICATION-FRAME))
      #<unused argument>
      #<unused argument>
      #<CLIM-DEMO::DEMODEMO {DC5B199}>)
 25: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND
       (#1="#<...>" . #1#))
      #<unused argument>
      #S(SB-PCL::FAST-METHOD-CALL
         :FUNCTION #<FUNCTION #>
         :PV-CELL NIL
         :NEXT-METHOD-CALL NIL
         :ARG-INFO (1 . T))
      #<CLIM-DEMO::DEMODEMO {DC5B199}>)
 26: (SB-INT:SIMPLE-EVAL-IN-LEXENV
      (CLIM-DEMO::RUN-TEST 'CLIM-DEMO::DEMODEMO)
      #<NULL-LEXENV>)
 27: (SWANK::EVAL-REGION
      "  (clim-demo::run-test 'clim-demo::demodemo)
     
     
     "
      T)
 28: ((LAMBDA ()))
 29: ((LAMBDA (SWANK-BACKEND::FN)) #<CLOSURE (LAMBDA #) {DBBCE35}>)
 30: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA #) {DBBCE35}>)
 31: (SWANK:LISTENER-EVAL
      "  (clim-demo::run-test 'clim-demo::demodemo)
     
     
     ")
 32: (SB-INT:SIMPLE-EVAL-IN-LEXENV
      (SWANK:LISTENER-EVAL "  (clim-demo::run-test 'clim-demo::demodemo)
     
     
     ")
      #<NULL-LEXENV>)

SBCL is 1.0, McCLIM is very recent CVS. 

regards, Samium Gromoff


From david at lichteblau.com  Mon Feb 12 20:33:43 2007
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 12 Feb 2007 21:33:43 +0100
Subject: [mcclim-devel] Gtkairo/demodemo bug
In-Reply-To: <877iunno6g.wl@betelheise.deep.net>
References: <mailman.62.1171298804.30612.mcclim-devel@common-lisp.net>
	<877iunno6g.wl@betelheise.deep.net>
Message-ID: <20070212203343.GA28127@argon.home.lichteblau.com>

Quoting Samium Gromoff (_deepfire at feelingofgreen.ru):
> When trying out the drawing part of demodemo, with mcclim using gtkairo,
> after drawing some lines i decided to draw an ellipse.

That is bug number 22 from Backends/gtkairo/BUGS.

I am not currently planning to work on the cairo medium, since I would
like to complete the gdk medium first, so feel free to tackle this
yourself...  :-)

For details, see the comment in medium-draw-ellipse*.


(The gdk medium can draw ellipses properly, but it has no support for
indexed-pattern yet, which makes it rather useless.)


d.


From rpgoldman at real-time.com  Tue Feb 13 22:31:28 2007
From: rpgoldman at real-time.com (Robert Goldman)
Date: Tue, 13 Feb 2007 16:31:28 -0600
Subject: [mcclim-devel] request for help with accepting a complex object
Message-ID: <45D23C40.9050405@real-time.com>

I have a complex object of two parameters that I would like to be able
to accept.  I.e., I would like to be able to prompt the user to enter
the two parameters, and I will build an object out of them.  I have been
trying to do this in an interactor window using accepting-values and get
the following error:

GRAPH-MDP(13): (accept 'termination-function :stream pane :prompt
"Termination function:")
Error: No methods applicable for generic function
#<STANDARD-GENERIC-FUNCTION INVOKE-UPDATING-OUTPUT> with args
       (#<STANDARD-INPUT-EDITING-STREAM @ #x9c015cc2>
        #<Closure (FLET CLIM-INTERNALS::INVOKE-ACCEPTING-VALUES
#:UPDATING-OUTPUT-CONTINUATION105288) @ #x9c02ab02>
        CLIM-INTERNALS::ACCEPTING-VALUES-RECORD (NIL) #<Function EQL>
CLIM-INTERNALS::NO-CACHE-VALUE
        #<Function FORCE-UPDATE-CACHE-TEST>)
       of classes (STANDARD-INPUT-EDITING-STREAM FUNCTION SYMBOL CONS
FUNCTION SYMBOL FUNCTION)

I was wondering if anyone could see their way to providing me a hint
about what's wrong.

Thanks,
R


From csr21 at cantab.net  Wed Feb 14 11:26:24 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Wed, 14 Feb 2007 11:26:24 +0000
Subject: [mcclim-devel] reinitializing panes
Message-ID: <87ejotdlpb.fsf@cantab.net>

Hi,

A question came up on #lisp yesterday: essentially, it asked how to
dynamically change the contents of a pane, in a similar way to
changing layouts of a frame.  My intuitive answer was to reinitialize
the pane with a new :contents initarg, which was quickly followed by
an intuitive suspicion that this wouldn't actually work in McCLIM
currently.  (The suspicion was strengthened by the example in the spec
in 29.5.2, which doesn't define any bookkeeping for reinitialization,
and confirmed when I actually tried it...)

So, the first question: should what I suggested work in principle, or
is there a reason why we shouldn't allow it (and what should be
allowed instead?).  The second question: if it should work, is there
anything wrong with the attached implementation, apart from its
cut-and-paste nature?  Is there something in the protocols that I am
not following?  To try it out, run the vbox's toplevel, then issue the
commands Double, followed by Draw.

Comments?

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vbox.lisp
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070214/d2bcb832/attachment.ksh>
-------------- next part --------------

Cheers,

Christophe

From ahefner at gmail.com  Thu Feb 15 00:57:01 2007
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 14 Feb 2007 19:57:01 -0500
Subject: [mcclim-devel] reinitializing panes
In-Reply-To: <87ejotdlpb.fsf@cantab.net>
References: <87ejotdlpb.fsf@cantab.net>
Message-ID: <31ffd3c40702141657m15d418e2id6cc8e4769276c0b@mail.gmail.com>

On 2/14/07, Christophe Rhodes <csr21 at cantab.net> wrote:
> A question came up on #lisp yesterday: essentially, it asked how to
> dynamically change the contents of a pane, in a similar way to
> changing layouts of a frame.

Apologies if I'm sending this twice, as gmail freaked out the first time around.

In the method browser example, I use sheet-adopt-child for this. (setf
sheet-children) isn't in the spec, but seems like it should be the
natural way to change all of the children. McCLIM has such a function,
but it is not useful to user code, because (at least for the box
layout panes) part of the magic is attached to sheet-adopt-child such
that even explicitly following (push new-child (sheet-children
a-box-or-rack-pane)) with (reorder-sheets ..) doesn't make the new
child appear, despite now appearing in the list returned by
sheet-children.

Incidentally, your approach of using reinitialize-instance is an idiom
I was not familiar with.


From _deepfire at feelingofgreen.ru  Sat Feb 17 18:31:52 2007
From: _deepfire at feelingofgreen.ru (Samium Gromoff)
Date: Sat, 17 Feb 2007 21:31:52 +0300
Subject: [mcclim-devel] Two gtkairo bugs: redraw hang in tabdemo,
	pane's :min- not respected 
In-Reply-To: <87ejotdlpb.fsf@cantab.net>
References: <87ejotdlpb.fsf@cantab.net>
Message-ID: <87fy94prdz.wl@betelheise.deep.net>


Hopefully posting gtkairo bugs is not punishable :-)

Both of those are in fresh cvs mcclim, and both of those do not
seem to happen with CLX.

1. Redraw stops in tabdemo when i click the rightmost tab, and then
the "C" tab

2. The following short program illustrates that :min-width/height
is not respected:

(define-application-frame tabdemo ()
    ()
  (:menu-bar tabdemo-menubar)
  (:panes
   (a :text-editor :value "Hello World from page A" :min-height 100 :min-width 100))
  (:layouts
   (default
       (vertically ()
	 (with-tab-layout ('tab-page :name 'tabdemo-layout :height 200)
           ("A" a))))))

(define-tabdemo-command (com-quit-tabdemo :menu t) ()
  (frame-exit *application-frame*))

(make-command-table 'tabdemo-menu :errorp nil
		    :menu '(("later on" :command com-quit-tabdemo)))

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

(defun tabdemo ()
  (run-frame-top-level (make-application-frame 'tabdemo)))

(defun sane-find-pane-named (frame name)
  (find name
	(climi::frame-named-panes frame)
	:key #'pane-name
	:test #'string-equal))

(defun tabdemo-layout ()
  (sane-find-pane-named *application-frame* 'tabdemo-layout))


regards, Samium Gromoff


From _deepfire at feelingofgreen.ru  Sun Feb 18 10:36:30 2007
From: _deepfire at feelingofgreen.ru (Samium Gromoff)
Date: Sun, 18 Feb 2007 13:36:30 +0300
Subject: [mcclim-devel] clim-listener's show-directory and non-ascii
	filenames 
Message-ID: <87k5yfiwgh.wl@betelheise.deep.net>

Here's what i get with CVS mcclim while trying to Show Directory my ~:

c-string encoding error (:external-format :ASCII):
  the character with code 208 cannot be encoded.
   [Condition of type SB-INT:C-STRING-ENCODING-ERROR]

Restarts:
 0: [ABORT] Return to application command loop
 1: [ABORT] Return to SLIME's top level.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {AFC6941}>)

Backtrace:
  0: (SB-INT:C-STRING-ENCODING-ERROR :ASCII 208)
      Locals:
        SB-DEBUG::ARG-0 = 2
        SB-DEBUG::ARG-1 = :ASCII
        SB-DEBUG::ARG-2 = 208
  1: (SB-IMPL::OUTPUT-TO-C-STRING/ASCII
      "/home/deepfire/14 - ??????????????????.mp3")
  2: (SB-UNIX:UNIX-LSTAT "/home/deepfire/14 - ??????????????????.mp3")
  3: (SB-UNIX:UNIX-FILE-KIND
      "/home/deepfire/14 - ??????????????????.mp3"
      T)
  4: (SB-IMPL::%ENUMERATE-FILES
      "/home/deepfire/"
      #P"/home/deepfire/14 - ??????????????????.mp3"
      T
      #<CLOSURE (LAMBDA #) {AAB93E5}>)
  5: (SB-INT:UNIX-NAMESTRING
      #P"/home/deepfire/14 - ??????????????????.mp3"
      T)
  6: (PROBE-FILE "/home/deepfire/14 - ??????????????????.mp3")
  7: ((LAMBDA (SB-IMPL::MATCH))
      "/home/deepfire/14 - ??????????????????.mp3")
  8: (SB-IMPL::%ENUMERATE-FILES
      "/home/deepfire/"
      #P"/home/deepfire/*.*"
      T
      #<CLOSURE (LAMBDA #) {BE12D35}>)
  9: ((LABELS SB-IMPL::DO-DIRECTORY) #P"/home/deepfire/*.*")
 10: (DIRECTORY #P"/home/deepfire/*.*")
 11: ((FLET #:DESTINATION-CONTINUATION5413))
 12: (SB-INT:SIMPLE-EVAL-IN-LEXENV
      (CLIM-LISTENER::COM-SHOW-DIRECTORY #P"/home/deepfire/")
      #<NULL-LEXENV>)
 13: (CLIM-LISTENER::COM-EVAL
      (CLIM-LISTENER::COM-SHOW-DIRECTORY #P"/home/deepfire/"))

regards, Samium Gromoff


From athas at sigkill.dk  Sun Feb 18 14:30:19 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Sun, 18 Feb 2007 15:30:19 +0100
Subject: [mcclim-devel] clim-listener's show-directory and non-ascii
	filenames
In-Reply-To: <87k5yfiwgh.wl@betelheise.deep.net> (Samium Gromoff's message of
	"Sun, 18 Feb 2007 13:36:30 +0300")
References: <87k5yfiwgh.wl@betelheise.deep.net>
Message-ID: <87ps878rno.fsf@lambda.athas.dyndns.dk>

Samium Gromoff <_deepfire at feelingofgreen.ru> writes:

> Here's what i get with CVS mcclim while trying to Show Directory my ~:

Which version of SBCL do you use? Some older versions do not support
non-ASCII pathnames.

-- 
\  Troels
/\ Henriksen


From _deepfire at feelingofgreen.ru  Sun Feb 18 14:48:54 2007
From: _deepfire at feelingofgreen.ru (Samium Gromoff)
Date: Sun, 18 Feb 2007 17:48:54 +0300
Subject: [mcclim-devel] clim-listener's show-directory and non-ascii
	filenames
In-Reply-To: <87ps878rno.fsf@lambda.athas.dyndns.dk>
References: <87k5yfiwgh.wl@betelheise.deep.net>
	<87ps878rno.fsf@lambda.athas.dyndns.dk>
Message-ID: <87irdzikrt.wl@betelheise.deep.net>

At Sun, 18 Feb 2007 15:30:19 +0100,
Troels Henriksen wrote:
> Samium Gromoff <_deepfire at feelingofgreen.ru> writes:
> 
> > Here's what i get with CVS mcclim while trying to Show Directory my ~:
> 
> Which version of SBCL do you use? Some older versions do not support
> non-ASCII pathnames.

SBCL is 1.0 here.

> -- 
> \  Troels
> /\ Henriksen

regards, Samium Gromoff


From perry at piermont.com  Thu Feb 22 03:49:17 2007
From: perry at piermont.com (Perry E. Metzger)
Date: Wed, 21 Feb 2007 22:49:17 -0500
Subject: [mcclim-devel] getting started...
Message-ID: <87lkiqhmwy.fsf@snark.piermont.com>


Pardon the utterly naive newbie question, but I'm brand new to
McClim, have never used ASDF (and barely understand what it is),
etc.

Say I want to get from zero (not even an installed Common Lisp) to
running a McClim demo on my machine (running Ubuntu Linux) in short
order. What do I need to do to get there?

-- 
Perry E. Metzger		perry at piermont.com


From sketerpot at gmail.com  Thu Feb 22 06:50:24 2007
From: sketerpot at gmail.com (Peter Scott)
Date: Thu, 22 Feb 2007 00:50:24 -0600
Subject: [mcclim-devel] getting started...
In-Reply-To: <87lkiqhmwy.fsf@snark.piermont.com>
References: <87lkiqhmwy.fsf@snark.piermont.com>
Message-ID: <7e267a920702212250m35e2b257q44491000bc90b2e3@mail.gmail.com>

On 2/21/07, Perry E. Metzger <perry at piermont.com> wrote:
> Pardon the utterly naive newbie question, but I'm brand new to
> McClim, have never used ASDF (and barely understand what it is),
> etc.

Welcome!

> Say I want to get from zero (not even an installed Common Lisp) to
> running a McClim demo on my machine (running Ubuntu Linux) in short
> order. What do I need to do to get there?

First, install the SBCL lisp compiler. Ubuntu has a package called
"sbcl", and you can install it either through the package manager or
with the command "sudo apt-get install sbcl".

Second, you would be well advised to install emacs and SLIME if you
don't have them already. Both are available in the Ubuntu package
repository, so you can install them the same way you installed SBCL.

Next, you'll need to download McCLIM and set it up. The easist way for
you to do this would probably be to open SBCL and enter the following
lines of Lisp code:

(require :asdf-install)
(asdf-install:install :mcclim)

When it asks you for the installation location, type "2" to install it
in "~/.sbcl". You will probably get some message about PGP keys; type
":c 0" to dismiss the warning and continue anyway.

This will install McCLIM on your system, along with the necessary
dependencies. When you want to get a demo running, here's some Lisp
code that should do it:

(require :mcclim)
(require :clouseau)
(clouseau:inspector #'length)

This will bring up the inspector, inspecting the function LENGTH. It
can inspect other things, too, so go ahead and play around with it.
Instructions for the other demos can be found in
"~/.sbcl/site/mcclim-0.9.4/INSTALL".

Good luck!

-Peter


From brian at mastenbrook.net  Thu Feb 22 13:05:59 2007
From: brian at mastenbrook.net (Brian Mastenbrook)
Date: Thu, 22 Feb 2007 07:05:59 -0600
Subject: [mcclim-devel] getting started...
In-Reply-To: <87lkiqhmwy.fsf@snark.piermont.com>
Message-ID: <C202F157.5231%brian@mastenbrook.net>

On 2/21/07 9:49 PM, "Perry E. Metzger" <perry at piermont.com> wrote:

> 
> Pardon the utterly naive newbie question, but I'm brand new to
> McClim, have never used ASDF (and barely understand what it is),
> etc.
> 
> Say I want to get from zero (not even an installed Common Lisp) to
> running a McClim demo on my machine (running Ubuntu Linux) in short
> order. What do I need to do to get there?

Luke Gorrie wrote a script called "clbuild" for this purpose. You can find
it at:

http://common-lisp.net/~crhodes/clbuild/

(That's Christophe's temporary fork, while Luke is away on work safari :-)

Luke documents the usage here: http://lukego.livejournal.com/2530.html

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




From smustudent1 at yahoo.com  Thu Feb 22 13:14:33 2007
From: smustudent1 at yahoo.com (C Y)
Date: Thu, 22 Feb 2007 08:14:33 -0500
Subject: [mcclim-devel] getting started...
In-Reply-To: <87lkiqhmwy.fsf@snark.piermont.com>
References: <87lkiqhmwy.fsf@snark.piermont.com>
Message-ID: <45DD9739.4070408@yahoo.com>

Perry E. Metzger wrote:
> Pardon the utterly naive newbie question, but I'm brand new to
> McClim, have never used ASDF (and barely understand what it is),
> etc.
> 
> Say I want to get from zero (not even an installed Common Lisp) to
> running a McClim demo on my machine (running Ubuntu Linux) in short
> order. What do I need to do to get there?

It may be a bit dated - haven't checked lately - but you might find this
useful if you want the latest cvs versions of things (first install sbcl
via you OS packaging system):

http://mcclim.cliki.net/GettingStarted


From rpgoldman at real-time.com  Thu Feb 22 13:56:09 2007
From: rpgoldman at real-time.com (Robert Goldman)
Date: Thu, 22 Feb 2007 07:56:09 -0600
Subject: [mcclim-devel] getting started...
In-Reply-To: <45DD9739.4070408@yahoo.com>
References: <87lkiqhmwy.fsf@snark.piermont.com> <45DD9739.4070408@yahoo.com>
Message-ID: <45DDA0F9.6030106@real-time.com>

C Y wrote:
> Perry E. Metzger wrote:
>> Pardon the utterly naive newbie question, but I'm brand new to
>> McClim, have never used ASDF (and barely understand what it is),
>> etc.
>>
>> Say I want to get from zero (not even an installed Common Lisp) to
>> running a McClim demo on my machine (running Ubuntu Linux) in short
>> order. What do I need to do to get there?
> 
> It may be a bit dated - haven't checked lately - but you might find this
> useful if you want the latest cvs versions of things (first install sbcl
> via you OS packaging system):
> 
> http://mcclim.cliki.net/GettingStarted

> 
If it *is* dated --- well, it's a wiki, please fix it!

Also, I would *not* recommend asdf-installing McCLIM.  It's not very
stable, and releases are not that frequent.  I run it out of CVS, but
don't update the working copy that frequently.

Best,
R


From perry at piermont.com  Thu Feb 22 15:01:05 2007
From: perry at piermont.com (Perry E. Metzger)
Date: Thu, 22 Feb 2007 10:01:05 -0500
Subject: [mcclim-devel] getting started...
In-Reply-To: <7e267a920702212250m35e2b257q44491000bc90b2e3@mail.gmail.com>
	(Peter Scott's message of "Thu, 22 Feb 2007 00:50:24 -0600")
References: <87lkiqhmwy.fsf@snark.piermont.com>
	<7e267a920702212250m35e2b257q44491000bc90b2e3@mail.gmail.com>
Message-ID: <87abz6grta.fsf@snark.piermont.com>


"Peter Scott" <sketerpot at gmail.com> writes:
> On 2/21/07, Perry E. Metzger <perry at piermont.com> wrote:
>> Pardon the utterly naive newbie question, but I'm brand new to
>> McClim, have never used ASDF (and barely understand what it is),
>> etc.
>
> Welcome!

Thanks for the assistance.

A few notes:

1) The section of INSTALL that describes demos is very strangely
   formatted - way more than 80 column lines, and if you more the file
   out in an xterm everything you need to type in is more than one
   line so you can't cut and paste the stuff in. That's the only part
   of the file that is messed up in this manner.
2) It would be cool if you could pop up a "master demo window". When
   tcl/tk was still new and exciting, there was a single app you could
   launch that would let you walk through a large set of interesting
   demos.
2) I popped up a Clouseau window, and (being ignorant) tried to do a
   few things like, say, expanding the bottom pane with the usual
   modern method of clicking and dragging on the frame between the
   panes. No dice -- such a thing doesn't work. In the address book
   demo, you can't tab between entry fields.
   I recognize that the UI is very much in the image of the lisp
   machine, but in the intervening 25 years since Genera was state of
   the art the "common expectations" of the naive user community have
   changed -- at the very least, it might be useful if there was a
   short document explaining to a user what the expectations of the UI
   they're using are (though perhaps ultimately it might be valuable
   to make the UI feel a bit more like what people are now used to.)

> Second, you would be well advised to install emacs and SLIME if you
> don't have them already. Both are available in the Ubuntu package
> repository, so you can install them the same way you installed SBCL.

I'm an old Emacs user so that was the first thing I install on any box
I set up. However, I've yet to play much with SLIME -- is there an
intro to SLIME somewhere?

> Next, you'll need to download McCLIM and set it up. The easist way for
> you to do this would probably be to open SBCL and enter the following
> lines of Lisp code:
>
> (require :asdf-install)
> (asdf-install:install :mcclim)

That's rather neat. It downloads and installs mcclim pretty much on
its own. Is there an asdf web page that explains how the whole thing
works and what it can do?


-- 
Perry E. Metzger		perry at piermont.com


From ahefner at gmail.com  Thu Feb 22 16:01:28 2007
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 22 Feb 2007 11:01:28 -0500
Subject: [mcclim-devel] getting started...
In-Reply-To: <87abz6grta.fsf@snark.piermont.com>
References: <87lkiqhmwy.fsf@snark.piermont.com>
	<7e267a920702212250m35e2b257q44491000bc90b2e3@mail.gmail.com>
	<87abz6grta.fsf@snark.piermont.com>
Message-ID: <31ffd3c40702220801j338f4062t2794c168e2807128@mail.gmail.com>

On 2/22/07, Perry E. Metzger <perry at piermont.com> wrote:

> 2) It would be cool if you could pop up a "master demo window". When
>    tcl/tk was still new and exciting, there was a single app you could
>    launch that would let you walk through a large set of interesting
>    demos.

There is the "demodemo", though it applies only to things in the
clim-examples system (and not Clouseau, the listener, etc). After
executing (asdf:oos 'asdf:load-op :clim-examples), it will print a
message advising you to run (clim-examples::demodemo). Most of them
aren't particularly interesting, however :). As have others, I would
recommend running the CVS version.


From david at lichteblau.com  Thu Feb 22 16:42:58 2007
From: david at lichteblau.com (David Lichteblau)
Date: Thu, 22 Feb 2007 17:42:58 +0100
Subject: [mcclim-devel] getting started...
In-Reply-To: <87abz6grta.fsf@snark.piermont.com>
References: <87lkiqhmwy.fsf@snark.piermont.com>
	<7e267a920702212250m35e2b257q44491000bc90b2e3@mail.gmail.com>
	<87abz6grta.fsf@snark.piermont.com>
Message-ID: <20070222164258.GA17457@argon.home.lichteblau.com>

Quoting Perry E. Metzger (perry at piermont.com):
> 2) I popped up a Clouseau window, and (being ignorant) tried to do a
>    few things like, say, expanding the bottom pane with the usual
>    modern method of clicking and dragging on the frame between the
>    panes. No dice -- such a thing doesn't work. In the address book
>    demo, you can't tab between entry fields.

It is probably a good idea to focus on specific applications and demos
to make sure that they work well.  (And separate them from those without
practical use or visual appeal.)

Clouseau seems like one application worth that attention.  Perhaps you
would like to submit a patch adding a BOX-ADJUSTER between application
pane and interactor?

In contrast, the address book is a classic demo that typifies
"traditional" CLIM applications, but nobody actually uses it to manage
their contacts, so it receives no attention at all.

>    I recognize that the UI is very much in the image of the lisp
>    machine, but in the intervening 25 years since Genera was state of
>    the art the "common expectations" of the naive user community have
>    changed -- at the very least, it might be useful if there was a
>    short document explaining to a user what the expectations of the UI
>    they're using are (though perhaps ultimately it might be valuable
>    to make the UI feel a bit more like what people are now used to.)

It is probably easier to take those parts of CLIM that work like a
normal toolkit and make them perfect than to take exotic CLIMy features
and turn them into something every user will be familiar with
immediately.

Take the address book as an example.  Even with the Gtkairo backend,
menus and scroll bars are implemented as native widgets, but overall,
the application still does not look like other GUI applications today.

So if you wanted to write an address book example that looks and feels
more modern, I would suggest building it out of gadgets.  Get rid of the
interactor.  Use list panes and buttons, perhaps even add a button bar.

(Alternatively, you could take the ESA approach and build something with
a look and feel familiar to Emacs users.)

Of course, it is also great to see improvements in the area of the more
traditional features.  Drei seems like one such step forward.  Perhaps
accepting-values as used for the input fields you mentioned could also
use a face lift.


d.


From bill at volersystems.com  Fri Feb 23 00:45:56 2007
From: bill at volersystems.com (Bill Sauer)
Date: Thu, 22 Feb 2007 16:45:56 -0800
Subject: [mcclim-devel] window functions
Message-ID: <00f401c756e4$03054e00$6401a8c0@Work2K>

The CLIM user manual indicates that the following functions are available...

(window-label window)
(window-parent window)
(window-children window)
(window-inside-height window)
(window-inside-width window)

etc...

These don't seem to exist in MCCLIM.  The question is are there plans to implement them in the future or are there other functions which replaced them.

Thanks for the help
Bill Sauer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070222/ca884ca2/attachment.html>

From athas at sigkill.dk  Fri Feb 23 08:34:25 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 23 Feb 2007 09:34:25 +0100
Subject: [mcclim-devel] window functions
In-Reply-To: <00f401c756e4$03054e00$6401a8c0@Work2K> (Bill Sauer's message of
	"Thu, 22 Feb 2007 16:45:56 -0800")
References: <00f401c756e4$03054e00$6401a8c0@Work2K>
Message-ID: <877iu9mfvy.fsf@lambda.athas.dyndns.dk>

"Bill Sauer" <bill at volersystems.com> writes:

> These don't seem to exist in MCCLIM.  The question is are there
> plans to implement them in the future or are there other functions
> which replaced them.

Are these only found in CLIM 2.2 (ie. the Franz documentation)? If so,
there has not yet been a dedicated effort to implement them, but I
guess you can say that there are plans to change that. Many CLIM 2.2
functions tend to be rather easy to implement because they are fairly
high-level, so if you want to give it a shot, patches would be
welcome. Otherwise, they should still be implemented at some point.

-- 
\  Troels
/\ Henriksen


From ahefner at gmail.com  Fri Feb 23 20:13:17 2007
From: ahefner at gmail.com (Andy Hefner)
Date: Fri, 23 Feb 2007 15:13:17 -0500
Subject: [mcclim-devel] window functions
In-Reply-To: <00f401c756e4$03054e00$6401a8c0@Work2K>
References: <00f401c756e4$03054e00$6401a8c0@Work2K>
Message-ID: <31ffd3c40702231213k25d91c24ne7c57619214ce468@mail.gmail.com>

On 2/22/07, Bill Sauer <bill at volersystems.com> wrote:
>
>
> The CLIM user manual indicates that the following functions are available...
>
> (window-label window)

Interesting, this occurs in the Lispworks CLIM manual but not the ACL
CLIM manual (or the CLIM 2.0 spec). An equivalent expression might be
(and (typep window 'labelled-gadget-mixin) (gadget-label window)).

> (window-parent window)
> (window-children window)

Window-parent and window-children are identical to sheet-parent and
sheet-children. The ACL CLIM manual mentions these are provided for
compatibility with CLIM 1.1.

> (window-inside-height window)
> (window-inside-width window)

CLIM 2.0 (and McCLIM) provides pane-viewport-region, which allows you
do these things in a more general fashion by operations on the
rectangle representing the viewable region of a window, for example
(bounding-rectangle-width (pane-viewport-region window)) or
(with-bounding-rectangle* (x1 y1 x2 y2) (pane-viewport-region window)
...).

> These don't seem to exist in MCCLIM.  The question is are there plans to
> implement them in the future or are there other functions which replaced
> them.

I don't plan to implement them (despite the effort being roughly
equivalent to writing this email), but I wouldn't turn away a
reasonable patch.


From bill at volersystems.com  Fri Feb 23 22:31:01 2007
From: bill at volersystems.com (Bill Sauer)
Date: Fri, 23 Feb 2007 14:31:01 -0800
Subject: [mcclim-devel] window functions
References: <00f401c756e4$03054e00$6401a8c0@Work2K>
	<31ffd3c40702231213k25d91c24ne7c57619214ce468@mail.gmail.com>
Message-ID: <001001c7579a$4d063120$6401a8c0@Work2K>

Hi Andy,

Thank you for the help.  I'm not enough of a CLIM user much less an expert
to volunter an patch.  I think the pane-viewport-region will work just fine
for now.

----- Original Message ----- 
From: "Andy Hefner" <ahefner at gmail.com>
To: "Bill Sauer" <bill at volersystems.com>
Cc: <mcclim-devel at common-lisp.net>
Sent: Friday, February 23, 2007 12:13 PM
Subject: Re: [mcclim-devel] window functions


> On 2/22/07, Bill Sauer <bill at volersystems.com> wrote:
> >
> >
> > The CLIM user manual indicates that the following functions are
available...
> >
> > (window-label window)
>
> Interesting, this occurs in the Lispworks CLIM manual but not the ACL
> CLIM manual (or the CLIM 2.0 spec). An equivalent expression might be
> (and (typep window 'labelled-gadget-mixin) (gadget-label window)).
>
> > (window-parent window)
> > (window-children window)
>
> Window-parent and window-children are identical to sheet-parent and
> sheet-children. The ACL CLIM manual mentions these are provided for
> compatibility with CLIM 1.1.
>
> > (window-inside-height window)
> > (window-inside-width window)
>
> CLIM 2.0 (and McCLIM) provides pane-viewport-region, which allows you
> do these things in a more general fashion by operations on the
> rectangle representing the viewable region of a window, for example
> (bounding-rectangle-width (pane-viewport-region window)) or
> (with-bounding-rectangle* (x1 y1 x2 y2) (pane-viewport-region window)
> ...).
>
> > These don't seem to exist in MCCLIM.  The question is are there plans to
> > implement them in the future or are there other functions which replaced
> > them.
>
> I don't plan to implement them (despite the effort being roughly
> equivalent to writing this email), but I wouldn't turn away a
> reasonable patch.
>