From stassats at gmail.com  Wed Apr 15 17:20:31 2009
From: stassats at gmail.com (Stas Boukarev)
Date: Wed, 15 Apr 2009 21:20:31 +0400
Subject: [mcclim-devel] dragging-output and patterns
Message-ID: <87y6u1bzq8.fsf@gmail.com>


The attached file demonstrates the following behaviour:
* When dragging over a pattern, pattern becomes distorted.
* When dragging over a circle it is ok.

And sometimes I get the following error, backtrace shows that it's signaled while
doing DRAG-OUTPUT-RECORD:
There is no applicable method for the generic function:
  #<STANDARD-GENERIC-FUNCTION SHEET-NATIVE-TRANSFORMATION #x300041532E4F>
when called with arguments:
  (NIL)

With gtkairo pattern doesn't become distorted.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: drag-test.lisp
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20090415/7d848e55/attachment.ksh>
-------------- next part --------------


-- 
With best regards, Stas.

From stassats at gmail.com  Thu Apr 16 01:51:26 2009
From: stassats at gmail.com (Stas Boukarev)
Date: Thu, 16 Apr 2009 05:51:26 +0400
Subject: [mcclim-devel] dragging-output and patterns
In-Reply-To: <87y6u1bzq8.fsf@gmail.com>
References: <87y6u1bzq8.fsf@gmail.com>
Message-ID: <9f0fec110904151851o47a98955lac776e814d503363@mail.gmail.com>

On Wed, Apr 15, 2009 at 9:20 PM, Stas Boukarev <stassats at gmail.com> wrote:
>
> The attached file demonstrates the following behaviour:
> * When dragging over a pattern, pattern becomes distorted.
> * When dragging over a circle it is ok.
>
> And sometimes I get the following error, backtrace shows that it's signaled while
> doing DRAG-OUTPUT-RECORD:
> There is no applicable method for the generic function:
> ?#<STANDARD-GENERIC-FUNCTION SHEET-NATIVE-TRANSFORMATION #x300041532E4F>
> when called with arguments:
> ?(NIL)
And that's because it's getting called with the result of
`port-pointer-sheet' function, which sometimes returns nil. And I also
found the following commentary: "XXX Should we rely on
port-pointer-sheet being correct? -- moore"

-- 
With best regards, Stas.



From csr21 at cantab.net  Mon Apr 20 09:55:45 2009
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 20 Apr 2009 10:55:45 +0100
Subject: [mcclim-devel] Fix crash
In-Reply-To: <877i37tvwh.fsf@trurl.pps.jussieu.fr> (Juliusz Chroboczek's
	message of "Mon\, 02 Mar 2009 23\:14\:22 +0100")
References: <877i37tvwh.fsf@trurl.pps.jussieu.fr>
Message-ID: <878wlvmyxq.fsf@cantab.net>

[ It appears that this mail, and three others like it, didn't make it
  to mcclim-devel, and I didn't realise this until today... ]

This fix seems uncontroversial, so I have merged it; thank you.  I've
never run into this problem myself; do you remember how you triggered
it?

Thanks,

Christophe

Juliusz Chroboczek <jch at pps.jussieu.fr> writes:

> Index: stream-input.lisp
> ===================================================================
> RCS file: /project/mcclim/cvsroot/mcclim/stream-input.lisp,v
> retrieving revision 1.54
> diff -u -r1.54 stream-input.lisp
> --- stream-input.lisp   1 May 2008 21:45:23 -0000       1.54
> +++ stream-input.lisp   2 Mar 2009 22:12:58 -0000
> @@ -215,7 +215,7 @@
>  ;;; Do streams care about any other events?
>  (defun handle-non-stream-event (buffer)
>    (let* ((event (event-queue-peek buffer))
> -        (sheet (event-sheet event)))
> +        (sheet (and event (event-sheet event))))
>      (if (and event
>              (or (and (gadgetp sheet)
>                        (gadget-active-p sheet))



From csr21 at cantab.net  Mon Apr 20 09:56:58 2009
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 20 Apr 2009 10:56:58 +0100
Subject: [mcclim-devel] Set save-unders for transient windows
In-Reply-To: <87fxhvtyxi.fsf@trurl.pps.jussieu.fr> (Juliusz Chroboczek's
	message of "Mon\, 02 Mar 2009 22\:08\:57 +0100")
References: <87fxhvtyxi.fsf@trurl.pps.jussieu.fr>
Message-ID: <871vrnmyvp.fsf@cantab.net>

Juliusz Chroboczek <jch at pps.jussieu.fr> writes:

> Minimises redraws.

So it does.  Thank you.

Best,

Christophe

> Index: Backends/CLX/port.lisp
> ===================================================================
> RCS file: /project/mcclim/cvsroot/mcclim/Backends/CLX/port.lisp,v
> retrieving revision 1.137
> diff -u -r1.137 port.lisp
> --- Backends/CLX/port.lisp	18 Feb 2009 17:34:44 -0000	1.137
> +++ Backends/CLX/port.lisp	2 Mar 2009 21:07:05 -0000
> @@ -363,6 +367,7 @@
>  				(override-redirect :off)
>  				(map t)
>  				(backing-store :not-useful)
> +                                (save-under :off)
>  				(event-mask `(:exposure 
>  					      :key-press :key-release
>  					      :button-press :button-release
> @@ -412,6 +417,7 @@
>                      :border border
>                      :override-redirect override-redirect
>                      :backing-store backing-store
> +                    :save-under save-under
>                      :gravity :north-west
>                      ;; Evil Hack -- but helps enormously (Has anybody
>                      ;; a good idea how to sneak the concept of
> @@ -456,6 +462,7 @@
>  (defmethod realize-mirror ((port clx-port) (sheet unmanaged-top-level-sheet-pane))
>    (realize-mirror-aux port sheet
>  		      :override-redirect :on
> +                      :save-under :on
>  		      :map nil
>  		      :event-mask '(:structure-notify)))
>  



From csr21 at cantab.net  Mon Apr 20 10:18:13 2009
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 20 Apr 2009 11:18:13 +0100
Subject: [mcclim-devel] [PATCH] cooperate with window manager
In-Reply-To: <87iqmrtz16.fsf@trurl.pps.jussieu.fr> (Juliusz Chroboczek's
	message of "Mon\, 02 Mar 2009 22\:06\:45 +0100")
References: <87iqmrtz16.fsf@trurl.pps.jussieu.fr>
Message-ID: <87ws9fljbu.fsf@cantab.net>

Juliusz Chroboczek <jch at pps.jussieu.fr> writes:

> The attached patch makes the CLX backend cooperate better with X11 window
> managers by marking frames as top-level windows.

Thank you; I've merged this, but I have some questions...

> Index: Backends/CLX/port.lisp
> ===================================================================
> RCS file: /project/mcclim/cvsroot/mcclim/Backends/CLX/port.lisp,v
> retrieving revision 1.137
> diff -u -r1.137 port.lisp
> --- Backends/CLX/port.lisp	18 Feb 2009 17:34:44 -0000	1.137
> +++ Backends/CLX/port.lisp	2 Mar 2009 21:03:36 -0000
> @@ -456,7 +462,14 @@
>        (setf (xlib:wm-hints window) (xlib:make-wm-hints :input :on))
>        (setf (xlib:wm-name window) (frame-pretty-name frame))
>        (setf (xlib:wm-icon-name window) (frame-pretty-name frame))
> -      (setf (xlib:wm-protocols window) `(:wm_delete_window)))))
> +      (xlib:set-wm-class
> +       window
> +       (string-downcase (frame-name frame))
> +       (string-capitalize (string-downcase (frame-name frame))))

This WM_CLASS is the same thing as is looked up in the Xresources
database, isn't it?  Does it have any other effect?  Do window
managers group windows by either of these names?

> +      (setf (xlib:wm-protocols window) `(:wm_delete_window))
> +      (xlib:change-property window
> +                            :WM_CLIENT_LEADER (list (xlib:window-id window))
> +                            :WINDOW 32))))

Here, we make each window its own leader, right?  What effect would
this have on multiple windows opened by a single client (such as those
opened with open-window-stream)?  Would it be better to have those
child windows have their WM_CLIENT_LEADER be the parent application
frame?

Best,

Christophe



From csr21 at cantab.net  Mon Apr 20 10:22:05 2009
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 20 Apr 2009 11:22:05 +0100
Subject: [mcclim-devel] Use Unicode fonts when available
In-Reply-To: <87d4cztypk.fsf@trurl.pps.jussieu.fr> (Juliusz Chroboczek's
	message of "Mon\, 02 Mar 2009 22\:13\:43 +0100")
References: <87d4cztypk.fsf@trurl.pps.jussieu.fr>
Message-ID: <87prf7lj5e.fsf@cantab.net>

Juliusz Chroboczek <jch at pps.jussieu.fr> writes:

> Don't leave the choice of font encoding to the server, as this is highly
> unreliable.  Try fonts as iso10646-1 if the server supports that, fall-back
> to iso8859-1.  If that's still not available, choose any font at all.
>
> iso10646-1 is only tried when (> char-code-limit #x100).

Thank you; this patch looks uncontroversial, and I've merged it as-is.

Best,

Christophe

> diff -u -r1.137 port.lisp
> --- Backends/CLX/port.lisp	18 Feb 2009 17:34:44 -0000	1.137
> +++ Backends/CLX/port.lisp	2 Mar 2009 21:07:05 -0000
> @@ -970,8 +984,6 @@
>        :italic-bold         "bold-i")) ))
>  
>  (defun open-font (display font-name)
> -
> -
>    (let ((fonts (xlib:list-font-names display font-name :max-fonts 1)))
>      (if fonts
>  	(xlib:open-font display (first fonts))
> @@ -1003,13 +1015,20 @@
>                     (size-number (if (numberp size)
>                                      (round size)
>                                      (or (getf *clx-text-sizes* size)
> -                                        (getf *clx-text-sizes* :normal))))
> -                   (font-name (format nil "-~A-~A-*-*-~D-*-*-*-*-*-*-*"
> -                                      family-name face-name size-number)))
> -              (setf (gethash text-style table)
> -                    (cons font-name
> -                          (open-font (clx-port-display port) font-name)))
> -              font-name))))))
> +                                        (getf *clx-text-sizes* :normal)))))
> +              (flet ((try (encoding)
> +                       (let* ((fn (format nil "-~A-~A-*-*-~D-*-*-*-*-*-~A"
> +                                          family-name face-name size-number
> +                                          encoding))
> +                              (font (open-font (clx-port-display port) fn)))
> +                         (and font (cons fn font)))))
> +                (let ((fn-font
> +                       (or
> +                        (and (> char-code-limit #x100) (try "iso10646-1"))
> +                        (try "iso8859-1")
> +                        (try "*-*"))))
> +                  (setf (gethash text-style table) fn-font)
> +                  (car fn-font)))))))))
>  
>  (defmethod (setf text-style-mapping) (font-name (port clx-port)
>                                        (text-style text-style)
> diff -u -r1.89 medium.lisp
> --- Backends/CLX/medium.lisp    9 Nov 2008 19:55:38 -0000       1.89
> +++ Backends/CLX/medium.lisp    2 Mar 2009 21:11:31 -0000
> @@ -945,8 +1020,8 @@
>  ;;; is by no means a proper solution to the problem of
>  ;;; internationalization, because fonts tend not to have a complete
>  ;;; coverage of the entirety of the Unicode space, even assuming that
> -;;; the underlying lisp supports it (as of 2006-02-06, only the case
> -;;; for SBCL and CLISP); instead, the translation function is meant to
> +;;; the underlying lisp supports it (this is the case at least for SBCL,
> +;;; CLISP and CCL); instead, the translation function is meant to
>  ;;; handle font sets by requesting the X server change fonts in the
>  ;;; middle of rendering strings.  However, the below stands a chance
>  ;;; of working when using ISO-8859-1-encoded fonts, and will tend to



From csr21 at cantab.net  Mon Apr 20 17:51:31 2009
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 20 Apr 2009 18:51:31 +0100
Subject: [mcclim-devel] [PATCH] cooperate with window manager
In-Reply-To: <7i3ac3if3b.fsf@lanthane.pps.jussieu.fr> (Juliusz Chroboczek's
	message of "Mon\, 20 Apr 2009 16\:18\:00 +0200")
References: <87iqmrtz16.fsf@trurl.pps.jussieu.fr> <87ws9fljbu.fsf@cantab.net>
	<7i3ac3if3b.fsf@lanthane.pps.jussieu.fr>
Message-ID: <87vdozi57g.fsf@cantab.net>

Juliusz Chroboczek <Juliusz.Chroboczek at pps.jussieu.fr> writes:

> Hi Christophe,
>
> Could you please whitelist the addresses
>
>   jch at pps.jussieu.fr
>   Juliusz.Chroboczek at pps.jussieu.fr
>
> for the mcclim list?

Done.  Thanks for the discussion below, left untrimmed so that it
shows up in the list archives.

Best,

Christophe

>> This WM_CLASS is the same thing as is looked up in the Xresources
>> database, isn't it?
>
> Yes.
>
>> Does it have any other effect?  Do window managers group windows by
>> either of these names?
>
> In principle, no.  If you run two Emacs instances, both have the same
> class name, and you don't expect the window manager to group them.
>
>>> +      (setf (xlib:wm-protocols window) `(:wm_delete_window))
>>> +      (xlib:change-property window
>>> +                            :WM_CLIENT_LEADER (list (xlib:window-id window))
>>> +                            :WINDOW 32))))
>
>> Here, we make each window its own leader, right?
>
> Yep.
>
>> What effect would this have on multiple windows opened by a single
>> client (such as those opened with open-window-stream)?
>
> The window manager would treat them as belonging to distinct
> applications.  In particular, if a window manager that only makes
> a single icon for an application will create multiple icons.
>
>> Would it be better to have those child windows have their
>> WM_CLIENT_LEADER be the parent application frame?
>
> It definitely would.  My patch does the strict minimum to ensure that
> every app has at least one icon in the window manager that I use.
>
> Regards,
>
>                                         Juliusz



From Juliusz.Chroboczek at pps.jussieu.fr  Mon Apr 20 18:11:14 2009
From: Juliusz.Chroboczek at pps.jussieu.fr (Juliusz Chroboczek)
Date: Mon, 20 Apr 2009 20:11:14 +0200
Subject: [mcclim-devel] Fix crash
In-Reply-To: <878wlvmyxq.fsf@cantab.net> (Christophe Rhodes's message of "Mon\,
	20 Apr 2009 10\:55\:45 +0100")
References: <877i37tvwh.fsf@trurl.pps.jussieu.fr> <878wlvmyxq.fsf@cantab.net>
Message-ID: <7iiqkzfb5p.fsf@lanthane.pps.jussieu.fr>

> This fix seems uncontroversial, so I have merged it; thank you.  I've
> never run into this problem myself; do you remember how you triggered
> it?

Sorry, I don't remember.  It's been quite some time...

                                        Juliusz



From Juliusz.Chroboczek at pps.jussieu.fr  Mon Apr 20 14:18:00 2009
From: Juliusz.Chroboczek at pps.jussieu.fr (Juliusz Chroboczek)
Date: Mon, 20 Apr 2009 16:18:00 +0200
Subject: [mcclim-devel] [PATCH] cooperate with window manager
In-Reply-To: <87ws9fljbu.fsf@cantab.net> (Christophe Rhodes's message of "Mon\,
	20 Apr 2009 11\:18\:13 +0100")
References: <87iqmrtz16.fsf@trurl.pps.jussieu.fr> <87ws9fljbu.fsf@cantab.net>
Message-ID: <7i3ac3if3b.fsf@lanthane.pps.jussieu.fr>

Hi Christophe,

Could you please whitelist the addresses

  jch at pps.jussieu.fr
  Juliusz.Chroboczek at pps.jussieu.fr

for the mcclim list?

> This WM_CLASS is the same thing as is looked up in the Xresources
> database, isn't it?

Yes.

> Does it have any other effect?  Do window managers group windows by
> either of these names?

In principle, no.  If you run two Emacs instances, both have the same
class name, and you don't expect the window manager to group them.

>> +      (setf (xlib:wm-protocols window) `(:wm_delete_window))
>> +      (xlib:change-property window
>> +                            :WM_CLIENT_LEADER (list (xlib:window-id window))
>> +                            :WINDOW 32))))

> Here, we make each window its own leader, right?

Yep.

> What effect would this have on multiple windows opened by a single
> client (such as those opened with open-window-stream)?

The window manager would treat them as belonging to distinct
applications.  In particular, if a window manager that only makes
a single icon for an application will create multiple icons.

> Would it be better to have those child windows have their
> WM_CLIENT_LEADER be the parent application frame?

It definitely would.  My patch does the strict minimum to ensure that
every app has at least one icon in the window manager that I use.

Regards,

                                        Juliusz




From nikodemus at random-state.net  Thu Apr 30 11:14:40 2009
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Thu, 30 Apr 2009 14:14:40 +0300
Subject: [mcclim-devel] patch: eliminate undefined variable warnings from
	the build
Message-ID: <633d72b0904300414k6c01879cobbeb702e0188fab0@mail.gmail.com>

Cheers,

 -- Nikodemus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eliminate-undefined-variable-warnings.patch
Type: application/octet-stream
Size: 11782 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20090430/ca2a55b2/attachment.obj>