From soemraws at xs4all.nl  Wed Jul  8 10:34:43 2009
From: soemraws at xs4all.nl (Sumant Oemrawsingh)
Date: Wed, 8 Jul 2009 12:34:43 +0200
Subject: [mcclim-devel] :clipping-region woes
Message-ID: <20090708103443.GA12408@pkd.strw.leidenuniv.nl>

Hi guys,

I'm having some problems with clipping regions (or I just don't understand the
concept, which is still entirely possible).

In the clim-listener, in the package clim-user, I do the following:

(with-room-for-graphics (t)
  (draw-rectangle* *standard-output* -10 -10 10 10))

This gives a black, filled rectangle. Great, just as expected. Now, I want to
try to define a clipping region:

(with-room-for-graphics (t)
  (draw-rectangle* *standard-output* -10 -10 10 10
                   :clipping-region (make-rectangle* -5 -5 5 5)))

What I expect is that it displays a smaller rectangle, namely the rectangle
with side 20 clipped down to a side of 10. However, I don't see anything.

So, I try the following:

(with-room-for-graphics (t)
  (draw-rectangle* *standard-output* -10 -10 10 10
                   :clipping-region (make-rectangle* -20 -20 20 20)))

Since the clipping region is _larger_ than the actual drawing, I expect to see
the same as in the first sexp, where I didn't define any clipping region.
Nevertheless, I see... NOTHING!

Is this a bug, a feature, or am I hopelessly ignorant and should just give up
ever trying to do anything remotely complicated in clim?

Thanks,
Sumant
-- 
Sumant Oemrawsingh
soemraws at xs4all.nl



From eadmund42 at gmail.com  Wed Jul  8 15:01:26 2009
From: eadmund42 at gmail.com (Robert Uhl)
Date: Wed, 08 Jul 2009 09:01:26 -0600
Subject: [mcclim-devel] :clipping-region woes
In-Reply-To: <20090708103443.GA12408@pkd.strw.leidenuniv.nl> (Sumant
	Oemrawsingh's message of "Wed\, 8 Jul 2009 12\:34\:43 +0200")
References: <20090708103443.GA12408@pkd.strw.leidenuniv.nl>
Message-ID: <m3vdm3nrqx.fsf@latakia.octopodial-chrome.com>

Sumant Oemrawsingh <soemraws at xs4all.nl> writes:
>
> In the clim-listener, in the package clim-user, I do the following:
>
> (with-room-for-graphics (t)
>   (draw-rectangle* *standard-output* -10 -10 10 10))
>
> This gives a black, filled rectangle. Great, just as expected. Now, I want to
> try to define a clipping region:
>
> (with-room-for-graphics (t)
>   (draw-rectangle* *standard-output* -10 -10 10 10
>                    :clipping-region (make-rectangle* -5 -5 5 5)))
>
> What I expect is that it displays a smaller rectangle, namely the rectangle
> with side 20 clipped down to a side of 10. However, I don't see anything.
>
> So, I try the following:
>
> (with-room-for-graphics (t)
>   (draw-rectangle* *standard-output* -10 -10 10 10
>                    :clipping-region (make-rectangle* -20 -20 20 20)))
>
> Since the clipping region is _larger_ than the actual drawing, I expect to see
> the same as in the first sexp, where I didn't define any clipping region.
> Nevertheless, I see... NOTHING!
>
> Is this a bug, a feature, or am I hopelessly ignorant and should just give up
> ever trying to do anything remotely complicated in clim?

Sorry for the huge quote, but I thought some context would be good.
Looking at <http://www.mikemac.com/mikemac/clim/drawing-options.html>,
it sounds like you're doing the right thing: RECTANGLE is a subclass of
POLYGON which is a subclass of AREA, and that's what :CLIPPING-REGION
expects.

So I suspect it's a bug or unimplemented feature.

-- 
Robert Uhl <http://public.xdi.org/=ruhl>
It's all a conspiracy.  A conspiracy by us elites to shut people out
by giving away all our code under open source licenses.
 --Peter Samuelson in comp.os.linux.development.system



From csr21 at cantab.net  Wed Jul  8 15:39:48 2009
From: csr21 at cantab.net (Christophe Rhodes)
Date: Wed, 08 Jul 2009 16:39:48 +0100
Subject: [mcclim-devel] :clipping-region woes
In-Reply-To: <20090708103443.GA12408@pkd.strw.leidenuniv.nl> (Sumant
	Oemrawsingh's message of "Wed\, 8 Jul 2009 12\:34\:43 +0200")
References: <20090708103443.GA12408@pkd.strw.leidenuniv.nl>
Message-ID: <878wiz9oaj.fsf@cantab.net>

Sumant Oemrawsingh <soemraws at xs4all.nl> writes:

> (with-room-for-graphics (t)
>   (draw-rectangle* *standard-output* -10 -10 10 10
>                    :clipping-region (make-rectangle* -5 -5 5 5)))
>
> What I expect is that it displays a smaller rectangle, namely the rectangle
> with side 20 clipped down to a side of 10. However, I don't see anything.

Without looking at the code, my suspicion is that the
with-room-for-graphics is at fault -- or at least, it's not
transforming the clipping region.

Doing 
  (draw-rectangle* *standard-output* 90 90 100 100 
                   :clipping-region (make-rectangle* 95 95 120 120))
at the Listener gives me a 5-pixel rectangle, as one might expect.

So clipping works at least partially; I don't know exactly what is at
fault.

Cheers,

Christophe



From soemraws at xs4all.nl  Thu Jul  9 12:46:17 2009
From: soemraws at xs4all.nl (Sumant Oemrawsingh)
Date: Thu, 9 Jul 2009 14:46:17 +0200
Subject: [mcclim-devel] :clipping-region woes
In-Reply-To: <878wiz9oaj.fsf@cantab.net>
References: <20090708103443.GA12408@pkd.strw.leidenuniv.nl>
	<878wiz9oaj.fsf@cantab.net>
Message-ID: <20090709124616.GA10191@pkd.strw.leidenuniv.nl>

On Wed, Jul 08, 2009 at 04:39:48PM +0100, Christophe Rhodes wrote:
> Sumant Oemrawsingh <soemraws at xs4all.nl> writes:
> 
> > (with-room-for-graphics (t)
> >   (draw-rectangle* *standard-output* -10 -10 10 10
> >                    :clipping-region (make-rectangle* -5 -5 5 5)))
> >
> > What I expect is that it displays a smaller rectangle, namely the rectangle
> > with side 20 clipped down to a side of 10. However, I don't see anything.
> 
> Without looking at the code, my suspicion is that the
> with-room-for-graphics is at fault -- or at least, it's not
> transforming the clipping region.
> 
> Doing 
>   (draw-rectangle* *standard-output* 90 90 100 100 
>                    :clipping-region (make-rectangle* 95 95 120 120))
> at the Listener gives me a 5-pixel rectangle, as one might expect.
> 
> So clipping works at least partially; I don't know exactly what is at
> fault.
> 
> Cheers,
> 
> Christophe

So it does. Weird... I thought that with-room-for-graphics was just a macro
that encloses the body in a transformation. In that case, how can the clipping
region, which is still created inside the body, fall outside of the
transformation?

So I guess that with-room-for-graphics wrongly deterimines the size of the
graphic after clipping, and just clips the whole thing, or so...

Well, I'm not versed in lisp enough to dive into the actual mcclim source code
(but I'll try anyway), so I don't expect I'll find the problem that fast.


Thanks for the help,
Sumant



From vrsoft at gmail.com  Wed Jul 15 13:40:49 2009
From: vrsoft at gmail.com (Remco Bras)
Date: Wed, 15 Jul 2009 15:40:49 +0200
Subject: [mcclim-devel] Can output records be moved?
In-Reply-To: <20090715122329.4203910416D@zero-desktop.localdomain>
References: <20090715122329.4203910416D@zero-desktop.localdomain>
Message-ID: <20028b570907150640o781fd104j12938986bb655229@mail.gmail.com>

Hello.

Is there a way to move an output record to another position after it
has been created, that is, to modify (output-record-position
some-record)?
Both versions of the user guide mention output-record-set-position,
which appears to be undefined. Similarly, setf*, which they mention
as an alternative, is undefined.

I'm using McClim 0.9.6 on SBCL 1.0.18.



From vrsoft at gmail.com  Wed Jul 15 15:02:05 2009
From: vrsoft at gmail.com (Remco Bras)
Date: Wed, 15 Jul 2009 17:02:05 +0200 (CEST)
Subject: [mcclim-devel]  Can output records be moved?
In-Reply-To: <19037.60516.841846.512791@serveur5.labri.fr>
References: <20090715122329.4203910416D@zero-desktop.localdomain>
	<20028b570907150640o781fd104j12938986bb655229@mail.gmail.com>
	<19037.60516.841846.512791@serveur5.labri.fr>
Message-ID: <20090715150205.E12C410416D@zero-desktop.localdomain>

Robert Strandh writes:
 > You should be able to say 
 > 
 >   (setf (output-record-position ...) (values x y))

That works, thanks.



From strandh at labri.fr  Wed Jul 15 14:49:08 2009
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 15 Jul 2009 16:49:08 +0200
Subject: [mcclim-devel]  Can output records be moved?
In-Reply-To: <20028b570907150640o781fd104j12938986bb655229@mail.gmail.com>
References: <20090715122329.4203910416D@zero-desktop.localdomain>
	<20028b570907150640o781fd104j12938986bb655229@mail.gmail.com>
Message-ID: <19037.60516.841846.512791@serveur5.labri.fr>

Remco Bras writes:
 > 
 > Is there a way to move an output record to another position after it
 > has been created, that is, to modify (output-record-position
 > some-record)?
 > Both versions of the user guide mention output-record-set-position,
 > which appears to be undefined. Similarly, setf*, which they mention
 > as an alternative, is undefined.

You should be able to say 

  (setf (output-record-position ...) (values x y))

-- 
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 sunil.nandihalli at gmail.com  Wed Jul 22 16:16:21 2009
From: sunil.nandihalli at gmail.com (Sunil S Nandihalli)
Date: Wed, 22 Jul 2009 21:46:21 +0530
Subject: [mcclim-devel] having an image icon on push-button
Message-ID: <abfdba800907220916mc7302d3t78f6551616901728@mail.gmail.com>

Hello,
 I was wondering if there is a way to have image-icons on push-buttons..
Regards,
Sunil

-- 
the more you know, the more you realize of how little you know in the
grander scheme of things
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20090722/8769e430/attachment.html>

From evgeny.zubok at tochka.ru  Thu Jul 23 16:41:44 2009
From: evgeny.zubok at tochka.ru (Evgeny M. Zubok)
Date: Thu, 23 Jul 2009 20:41:44 +0400
Subject: [mcclim-devel] having an image icon on push-button
References: <abfdba800907220916mc7302d3t78f6551616901728@mail.gmail.com>
Message-ID: <87my6vgxmf.fsf@tochka.ru>

Sunil S Nandihalli <sunil.nandihalli at gmail.com> writes:

> Hello, I was wondering if there is a way to have image-icons on
> push-buttons..  Regards, Sunil

You may, for example, create a new class picture-button-pane, create
pattern from icon image (for example, XPM) and draw pattern above the
push-button in handle-repaint :after method. In this simple example the
dimension of icon.xpm is 21x21 (icon is attached). Also I hardcoded
width and height of the button in (compose-space...)  to (29x29 px) and
translation to (4,4).

Type (picture-button-demo::run) to run the example.




(defpackage :picture-button-demo
  (:use #:clim-lisp #:clim))

(in-package :picture-button-demo)

(defun run ()
  (run-frame-top-level (make-application-frame 'button-demo)))

(defclass picture-button-pane (push-button-pane)
  ((pattern :accessor pattern :initarg :pattern)))

(define-application-frame button-demo ()
  ()
  (:menu-bar nil)
  (:panes
   (button
    (make-pane
     'picture-button-pane
     :name 'picture-button
     :pattern (climi::make-pattern-from-bitmap-file
	       "/path/to/your/icon.xpm" :format :pixmap-3))))
  (:layouts
   (:main button)))

(defmethod handle-repaint :after ((pane picture-button-pane) region)
  (draw-design pane (pattern pane)
	       :transformation (make-transformation 0 0 0 0 4 4)
	       :clipping-region region))

(defmethod compose-space ((gadget picture-button-pane) &key width height)
  (declare (ignore width height))
  (make-space-requirement :width 29 :height 29
			  :max-height 29 :max-width 29
			  :min-height 29 :min-width 29))



-------------- next part --------------
A non-text attachment was scrubbed...
Name: icon.xpm
Type: image/x-xpixmap
Size: 684 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20090723/fdc61d65/attachment.xpm>

From nikodemus at random-state.net  Sat Jul 25 17:17:25 2009
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Sat, 25 Jul 2009 20:17:25 +0300
Subject: [mcclim-devel] STREAM-FINISH-OUTPUT missing on
	STANDARD-EXTENDED-OUTPUT-STREAM
Message-ID: <633d72b0907251017p293231baxa9331794c3df750@mail.gmail.com>

Attached patch makes life better, making code that relies on
FINISH-OUTPUT to flush streams to work on eg. interactor panes.

Cheers,

 -- Nikodemus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: finish-output.patch
Type: application/octet-stream
Size: 710 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20090725/c25f045f/attachment.obj>

From nikodemus at random-state.net  Sun Jul 26 13:22:30 2009
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Sun, 26 Jul 2009 16:22:30 +0300
Subject: [mcclim-devel] malformed DX declations (two missing unquotes in
	DEFINE-INVOKE-WITH)
Message-ID: <633d72b0907260622j7821ee63mff5c2faa40f3a721@mail.gmail.com>

Patch attached.

Cheers,

 -- Nikodemus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dx-declarations.patch
Type: application/octet-stream
Size: 660 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20090726/66b3bbf5/attachment.obj>

From nikodemus at random-state.net  Wed Jul 29 18:23:14 2009
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Wed, 29 Jul 2009 21:23:14 +0300
Subject: [mcclim-devel] how to subclass a pane in good style?
Message-ID: <633d72b0907291123l1ac4b49aj26b0e7d35a2a53da@mail.gmail.com>

Attached file canvas-pane.lisp is a work-in-progress. clim-patch.lisp
provides MEDIUM-DRAW-PIXELS* it depends on, based on Andy Hefner's
code that he posted a while back.

I use it in my raytracer's CLIM frontend to put up the pretty pictures
as they are drawn, and to provide a selection area on already rendered
images.

There are (currently) three major behaviours that it provides for me:

 (SETF (CANVAS-RGBA CANVAS) <RGBA-AS-UB32>)

   allows me to quickly assign color to a pixel.

 (REPAINT-SHEET CANVAS (CANVAS-DIRTY-REGION CANVAS))

   allows me to refresh the screen during rendering, updating only
   those portions where pixel colors have changed.

 (CANVAS-SELECTION CANVAS)

   gives me the bounding rectangle of the selected area. (A region
   is selected at any time by clicking and dragging on the canvas.)

There may be any number of dubious things in there, but the things
that most confuse me are:

* What to subclass? I currently subclass APPLICATION-PANE. I don't
know if I should subclass something else instead.

* Unintended overriding. I seem to accidentally override the
border-building stuff from APPLICATION-PANE. It is not obvious to me
why this happens, nor do I know how to avoid this should I want to.

* Event handling: to get pointer events I define a method on
DISPATCH-EVENT that calls HANDLE-EVENT. Is this the way it is supposed
to be done?

* Event handling & coordinates: to get coordinates relative to canvas
when the pointer is outside the canvas area during the click-and-drag
selection I transform coordinates through a common ancestor. This
seems a bit awkward -- is there a better way?

Any comments would be most welcome.

Cheers,

 -- Nikodemus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: canvas-pane.lisp
Type: application/octet-stream
Size: 9061 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20090729/9b246b30/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clim-patch.lisp
Type: application/octet-stream
Size: 1797 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20090729/9b246b30/attachment-0001.obj>

From ahefner at gmail.com  Wed Jul 29 20:14:16 2009
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 29 Jul 2009 16:14:16 -0400
Subject: [mcclim-devel] how to subclass a pane in good style?
In-Reply-To: <633d72b0907291123l1ac4b49aj26b0e7d35a2a53da@mail.gmail.com>
References: <633d72b0907291123l1ac4b49aj26b0e7d35a2a53da@mail.gmail.com>
Message-ID: <31ffd3c40907291314n512e53c5ta0a5b357a090ce5e@mail.gmail.com>

On Wed, Jul 29, 2009 at 2:23 PM, Nikodemus
Siivola<nikodemus at random-state.net> wrote:

> There may be any number of dubious things in there, but the things
> that most confuse me are:
>
> * What to subclass? I currently subclass APPLICATION-PANE. I don't
> know if I should subclass something else instead.

Subclassing APPLICATION-PANE is fine. For your purposes, subclassing
BASIC-GADGET (or both) might be better (see below).

> * Unintended overriding. I seem to accidentally override the
> border-building stuff from APPLICATION-PANE. It is not obvious to me
> why this happens, nor do I know how to avoid this should I want to.

Not sure what you're referring to.

> * Event handling: to get pointer events I define a method on
> DISPATCH-EVENT that calls HANDLE-EVENT. Is this the way it is supposed
> to be done?

This works, but may inhibit built-in behaviors of the stream (like
text selection, or wheel scrolling). CLIM's input model is
brain-damaged, and event handlers on stream panes (including
application-pane) usually don't work like you want, because magic
input machinery steals the events and turns drives the input editor,
mouse sensitivity to presentations, etc. Gadgets are excluded from
this idiocy, so I've taken to mixing BASIC-GADGET into my classes when
I want a stream pane with custom event handling. For your purposes,
I'm not sure if you need a full CLIM stream at all, so you might
consider subclassing only BASIC-GADGET.

Also, calling tracking-pointer from an event-handler is.. interesting.
I'm sure it says something good about the CLIM design that this works.
I'd have tried this using separate press/release event handlers,
relying on X's implicit pointer grab, but I fear that doesn't give the
behavior you want when the pointer is out of the window.

> * Event handling & coordinates: to get coordinates relative to canvas
> when the pointer is outside the canvas area during the click-and-drag
> selection I transform coordinates through a common ancestor. This
> seems a bit awkward -- is there a better way?

I can't think of a better way. You could simply the code slightly by
using (graft sheet) as the common ancestor.



From strandh at labri.fr  Fri Jul 31 11:32:52 2009
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 31 Jul 2009 13:32:52 +0200
Subject: [mcclim-devel] STREAM-FINISH-OUTPUT missing
	on	STANDARD-EXTENDED-OUTPUT-STREAM
In-Reply-To: <633d72b0907251017p293231baxa9331794c3df750@mail.gmail.com>
References: <633d72b0907251017p293231baxa9331794c3df750@mail.gmail.com>
Message-ID: <19058.54884.659832.604870@serveur5.labri.fr>

Nikodemus Siivola writes:
 > Attached patch makes life better, making code that relies on
 > FINISH-OUTPUT to flush streams to work on eg. interactor panes.

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 strandh at labri.fr  Fri Jul 31 11:35:38 2009
From: strandh at labri.fr (Robert Strandh)
Date: Fri, 31 Jul 2009 13:35:38 +0200
Subject: [mcclim-devel] malformed DX declations (two missing unquotes
	in	DEFINE-INVOKE-WITH)
In-Reply-To: <633d72b0907260622j7821ee63mff5c2faa40f3a721@mail.gmail.com>
References: <633d72b0907260622j7821ee63mff5c2faa40f3a721@mail.gmail.com>
Message-ID: <19058.55050.228544.68948@serveur5.labri.fr>

Nikodemus Siivola writes:
 > Patch attached.

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