From strandh at labri.fr  Mon Dec  7 15:28:41 2009
From: strandh at labri.fr (Robert Strandh)
Date: Mon, 7 Dec 2009 16:28:41 +0100
Subject: [mcclim-devel] Issue tracker on Launchpad
In-Reply-To: <87r5vniv9n.fsf@tochka.ru>
References: <87r5vniv9n.fsf@tochka.ru>
Message-ID: <19229.7977.826589.237506@serveur5.labri.fr>

Hello,

I started an issue tracker for McCLIM on Launchpad.  Here is the URL:

   https://bugs.launchpad.net/mcclim

The initial goal is to clean up the demos:

  * Remove old useless demos.

  * Add reasonable ones to the demodemo that aren't already in there. 

  * Make sure the demos used in demodemo work correctly.

  * Clean up the code of the demos if necessary.

So, if you have any lingering bugs to report, in the demos or
elsewhere, please post them to the issue tracker.

Regards,
-- 
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 wtmarcus at gmail.com  Sun Dec 13 17:04:37 2009
From: wtmarcus at gmail.com (Marcus Eskilsson)
Date: Sun, 13 Dec 2009 18:04:37 +0100
Subject: [mcclim-devel] drawing of RGB-IMAGE-DESIGN
Message-ID: <4B251EA5.6020808@gmail.com>

Hello thar, list!

I have started a lil' work here on some McCLIM based software and I have run
into a bit of an issue.

I'm trying to have a pane with a display-function that displays me an 
image I load
from a PNM, and this fails for me.

Basically I have (excuse the indentation. thunderbird mail client etc.)

(defmethod pane-display (frame stream)
    (draw-design (find-pane-named frame 'foo-pane)
                   (climi::make-rgb-image-design
                        (image::read-image-file "foo.pnm"))))

result is this


There is no applicable method for the generic function
  #<STANDARD-GENERIC-FUNCTION CLIM-INTERNALS::IMAGE-WIDTH (1)>
when called with arguments
  (#2A((12693671 12303027 12697025 12960710 13093066 13618384
        14210776 14343390 14606308 14738150 ...)
       (11902865 11706271 12433848 12633281 13683403 13947084
        13947345 14080471 14670557 14606822 ...)
       (11118502 11445149 11973554 12759733 13222341 13487563
        13683408 13882839 14606045 14738146 ...)
       (8945292 11970725 12169393 12365746 13091006 13422029
        13882580 14276825 14606041 14540249 ...)
       (10723750 11710384 11973812 12564921 13355469 13881037
        14472140 14342101 14538968 14605792 ...)
       (11908536 12499904 13486538 13486792 13552588 13947345
        14473680 14736857 14473433 14538717 ...)
       (12828606 13090233 13421257 13420744 13486791 13749708
        14209746 14342105 14671069 14868192 ...)
       (13024958 13420748 13551822 13422023 13749963 13618378
        14144469 14734804 14473432 14998751 ...)
       (12962251 13422543 13618382 13552330 13422538 13421261
        13949651 14473688 14538969 14473432 ...)
       (13488855 12899034 13030102 13293012 13095121 13292756
        13488336 13357008 13684694 14079703 ...)
       ...)).
   [Condition of type SIMPLE-ERROR]

Backtrace:
  0: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable 
argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION 
CLIM-INTERNALS::IMAGE-WIDTH (1)>)[:EXTERNAL]
  1: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER 
(CLIM-INTERNALS::DRAW-IMAGE-DESIGN-OUTPUT-RECORD)) ..)[:EXTERNAL]
  2: ((LAMBDA (SB-PCL::|.P0.| SB-PCL::|.P1.| SB-PCL::|.P2.| 
SB-PCL::|.P3.|)) #<unavailable argument> #<unavailable argument> 
#<unavailable argument> #<unavailable argument>)
  3: ((LABELS #:G5221) #<CLIM-CLX::CLX-MEDIUM {1003B139A1}>)
  4: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::MEDIUM-DRAW-IMAGE-DESIGN* 
:AROUND (OUTPUT-RECORDING-STREAM T T T)) ..)
  5: ((SB-PCL::FAST-METHOD 
CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL (MEDIUM T T)) 
..)[:EXTERNAL]
  6: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS 
(SHEET T)) ..)[:EXTERNAL]
  7: ((SB-PCL::FAST-METHOD DRAW-DESIGN (T 
CLIM-INTERNALS::RGB-IMAGE-DESIGN)) ..)[:EXTERNAL]




I'm unaware if this is actually a bug or I just should stay the hell 
away from these functions and make the pnm loader behave with 
MAKE-PATTERN-FROM-BITMAP-FILE.



From strandh at labri.fr  Mon Dec 14 07:28:10 2009
From: strandh at labri.fr (Robert Strandh)
Date: Mon, 14 Dec 2009 08:28:10 +0100
Subject: [mcclim-devel]  drawing of RGB-IMAGE-DESIGN
In-Reply-To: <4B251EA5.6020808@gmail.com>
References: <4B251EA5.6020808@gmail.com>
Message-ID: <19237.59658.239100.691131@serveur5.labri.fr>

Hello,

Marcus Eskilsson writes:
 > I have started a lil' work here on some McCLIM based software and I have run
 > into a bit of an issue.
 > 
 > I'm trying to have a pane with a display-function that displays me an 
 > image I load
 > from a PNM, and this fails for me.
 > 
 > Basically I have (excuse the indentation. thunderbird mail client etc.)
 > 
 > (defmethod pane-display (frame stream)
 >     (draw-design (find-pane-named frame 'foo-pane)
 >                    (climi::make-rgb-image-design
 >                         (image::read-image-file "foo.pnm"))))

This is because there are several, mutually incompatible image
extensions in McCLIM.  When you do (image::read-image-file ...) the
raw data is returned, whereas climi::make-rgb-image design requires an
object of type rgb-image which you create by giving it :width,
:height, and :data initargs. 

Regards,
-- 
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 stassats at gmail.com  Wed Dec 16 08:35:54 2009
From: stassats at gmail.com (Stas Boukarev)
Date: Wed, 16 Dec 2009 11:35:54 +0300
Subject: [mcclim-devel] [Patch] not unquoted variable in
	with-output-as-presentation
Message-ID: <87my1j5n9x.fsf@gmail.com>

Patch attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: with-output-as-presentation.diff
Type: text/x-patch
Size: 418 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20091216/f2518bdc/attachment.bin>
-------------- next part --------------

-- 
With Best Regards, Stas.

From evgeny.zubok at tochka.ru  Sat Dec 26 15:53:46 2009
From: evgeny.zubok at tochka.ru (Evgeny M. Zubok)
Date: Sat, 26 Dec 2009 18:53:46 +0300
Subject: [mcclim-devel] How stream-pointer-position should work?
Message-ID: <87637tived.fsf@tochka.ru>


Hello,

If I call stream-pointer-position on the stream without scroller, it
returns an expected position. However, when the stream has a scroller,
the function returns the position inside viewport regardless position of
scrollbars, i. e. from upper left corner of viewport, not from the
stream's origin. I have played with map-sheet-position-to-child and
map-sheet-position-to-parent but faced with the different behaviour of
these functions, which depends on how scrolling declared inside
define-application-frame. To be more presise, it depends on internal
structure of application-pane with scroller: in McCLIM it has also
border-pane as a parent (why?). I think, the programmer shouldn't keep
in mind such implementation details.

So, what is the right behavior of stream-pointer-position if the stream
has a scroller?  Shouldn't it return the real coordinates on stream as
pointer events do?


Specification says:


stream-pointer-position                               [Generic Function]

Arguments: stream &key pointer 

Summary: Returns the current position of the pointing device pointer for
the extended input stream stream as two values, the x and y positions in
the stream's drawing surface coordinate system. If pointer is not
supplied, it defaults to the stream-primary-pointer of the stream.




From evgeny.zubok at tochka.ru  Sun Dec 27 01:14:26 2009
From: evgeny.zubok at tochka.ru (Evgeny M. Zubok)
Date: Sun, 27 Dec 2009 04:14:26 +0300
Subject: [mcclim-devel] How stream-pointer-position should work?
References: <87637tived.fsf@tochka.ru>
Message-ID: <871vihi5fx.fsf@tochka.ru>

"Evgeny M. Zubok" <evgeny.zubok at tochka.ru> writes:

> So, what is the right behavior of stream-pointer-position if the
> stream has a scroller?  Shouldn't it return the real coordinates on
> stream as pointer events do?

I found an answer to my question. I have just found CLIM implementation
from Allegro CL (I only used it with lesstif backend instead motif). 

To test I create a pane 'canvas' with :min-height 2000 :min-width 2000
and layout (scrolling (:height 500 :width 500) ...). In
define-presentation-action for blank-area I call stream-pointer-position
and print string "TEST", starting that point . In Allegro's CLIM
implementation the strings appear where I have pressed pointer button;
in McCLIM they appear only at the first page of canvas, even if I have
pressed button on blank-area on other pages. So, I think, this is bug in
McCLIM.

Sample code:


(defpackage :stream-pointer-position-bug
  (:use :clim-lisp :clim))

(in-package :stream-pointer-position-bug)

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

(define-application-frame main ()
  ()
  (:menu-bar nil)
  (:panes
   (canvas (scrolling (:height 500 :width 500) 
	     (make-pane 'application-pane
			:display-time nil 
			:background +black+ :foreground +white+
			:min-width 2000 :min-height 2000
			:scroll-bars t
			:display-function #'draw-circle
			:name 'canvas
			:output-record (make-instance 
					'standard-tree-output-history)))))
   (:layouts
    (:main canvas)))

(defun draw-circle (frame pane)
  (declare (ignore frame))
  (draw-circle* pane 1500 1500 70 :filled t :ink +yellow+))

(define-presentation-action test
    (blank-area nil main :gesture :select)
    (presentation window)
  (declare (ignore presentation))
  (multiple-value-bind (x y)
      (stream-pointer-position window)
    (draw-text* window "TEST" x y)))