[werner@suse.de: Several problems in KDE/KWin]

[werner@suse.de: Several problems in KDE/KWin]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
From: Werner Fink <werner@suse.de>
To: bug-gnu-emacs@gnu.org
Message-Id: <20071205165421.2869B2F2ED2@magellan.suse.de>
Date: Wed,  5 Dec 2007 17:54:20 +0100 (CET)
Cc: dieter.jurzitza@t-online.de, llunak@novell.com, mszeredi@novell.com
Subject: Several problems in KDE/KWin

Two problems have beem seen:

  Emacs does not keep the "iconic" information in KDE/KWin
  Emacs does not un-maximize in KDE/KWin

When starting emacs in kde in the background iconified like:
 emacs --iconic &
it shows only in the menu-bar of kde but not in the screen (by intent). Now, if
I save the desktop configuration, quit kde and start it again, emacs is startet
- - what is expected - but not iconified - what is not expected.

After maximizing an emacs window, it is not possible to un-maximise it.
It may depend on font size and desktop geometry.  I have these in
Xresources:
 Emacs.font:     10x20
 Emacs.geometry: 80x38
 Size of desktop is 1400x1050.
The symptom is that after maximizing, the "maximize/un-maximize" button stays
in the "maximize" state (one square), intead of going to the "un-maximize"
state (two squares).


In GNU Emacs 22.1.1 (x86_64-suse-linux-gnu, GTK+ Version 2.12.0)
 of 2007-11-10 on reger
Windowing system distributor `The X.Org Foundation', version 11.0.70199902
configured using `configure  '--with-gcc' '--with-pop' '--without-hesiod' '--with-kerberos' '--with-kerberos5' '--with-leim' '--with-xim' '--with-system-malloc' '--prefix=/usr' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--with-x' '--with-sound' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x-toolkit=gtk' '--x-includes=/usr/include' '--x-libraries=/usr/lib64:/usr/share/X11' '--build=x86_64-suse-linux-gnu' 'build_alias=x86_64-suse-linux-gnu' 'CC=gcc' 'CFLAGS=-O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -g -pipe -fno-strict-aliasing 	 -D_GNU_SOURCE 	 -Wno-pointer-sign 	 -Wno-unused-variable 	 -Wno-unused-label  -DSYSTEM_PURESIZE_EXTRA=55000 	 -DSITELOAD_PUR
 ESIZE_EXTRA=10000 ' 'LDFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: de_DE.ISO-8859-1
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: POSIX
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <down-mouse-1> <mouse-movement> 
<mouse-1> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<menu-bar> <help-menu> <report-emacs-bug>

Recent messages:
Loading /usr/share/emacs/22.1/leim/leim-list.el (source)...done
Loading /usr/share/emacs/site-lisp/skk/leim-list.el (source)...done
Loading /usr/share/emacs/site-lisp/egg/leim-list.el (source)...done
uim.el: starting uim-el-helper-agent... done
uim.el: starting uim-el-agent... done
Loading paren...done
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
call-interactively: End of buffer [11 times]
------- End of forwarded message -------

Re: [werner@suse.de: Several problems in KDE/KWin]

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>   Emacs does not un-maximize in KDE/KWin

[...]

> After maximizing an emacs window, it is not possible to un-maximise it.
> It may depend on font size and desktop geometry.  I have these in
> Xresources:
>  Emacs.font:     10x20
>  Emacs.geometry: 80x38
>  Size of desktop is 1400x1050.
> The symptom is that after maximizing, the "maximize/un-maximize" button stays
> in the "maximize" state (one square), intead of going to the "un-maximize"
> state (two squares).

I think the problem is that Emacs cannot be resized stepless, but only
in steps of columns and lines depending on the size of the used font.
So if Emacs is maximized in KDE it's most probably not as big as the
usable space of the desktop is.  I'm not sure, but I think because of
that kwin thinks it's not maximized.

Bye,
Tassilo

Re: [werner@suse.de: Several problems in KDE/KWin]

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>   Emacs does not un-maximize in KDE/KWin
>
> [...]
>
>> After maximizing an emacs window, it is not possible to un-maximise it.
>> It may depend on font size and desktop geometry.  I have these in
>> Xresources:
>>  Emacs.font:     10x20
>>  Emacs.geometry: 80x38
>>  Size of desktop is 1400x1050.
>> The symptom is that after maximizing, the "maximize/un-maximize" button stays
>> in the "maximize" state (one square), intead of going to the "un-maximize"
>> state (two squares).
>
> I think the problem is that Emacs cannot be resized stepless, but only
> in steps of columns and lines depending on the size of the used font.

I don't think so.  Other programs like xterm also resize in steps, but
still can be properly maximized/unmaximized.

> So if Emacs is maximized in KDE it's most probably not as big as the
> usable space of the desktop is.  I'm not sure, but I think because of
> that kwin thinks it's not maximized.

If you try to maximize a second time the frame is actually truely
maximized.  But unmaximizing restores intermediate, nearly maximized
size, not the original one.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [werner@suse.de: Several problems in KDE/KWin]

[Stephen Berman]

On Fri, 07 Dec 2007 20:08:00 +0100 Andreas Schwab <schwab@suse.de> wrote:

> If you try to maximize a second time the frame is actually truely
> maximized.  

This is so if you maximize either vertically (mouse-2) or horizontally
(mouse-3) but not for both dimensions simultaneously (mouse-1).

>             But unmaximizing restores intermediate, nearly maximized
> size, not the original one.

This behavior has varied in the course of Emacs 22 development.  For
further details see
<http://permalink.gmane.org/gmane.emacs.devel/77970>.

Steve Berman

Re: [werner@suse.de: Several problems in KDE/KWin]

[Jan Djärv]

Stephen Berman skrev:
> On Fri, 07 Dec 2007 20:08:00 +0100 Andreas Schwab <schwab@suse.de> wrote:
> 
>> If you try to maximize a second time the frame is actually truely
>> maximized.  
> 
> This is so if you maximize either vertically (mouse-2) or horizontally
> (mouse-3) but not for both dimensions simultaneously (mouse-1).
> 
>>             But unmaximizing restores intermediate, nearly maximized
>> size, not the original one.
> 
> This behavior has varied in the course of Emacs 22 development.  For
> further details see
> <http://permalink.gmane.org/gmane.emacs.devel/77970>.
> 

It is the same root cause as the "describe-{function,variable} shrinks frame
(GTK+/KDE)" problem
(http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01108.html).

I so far figured out that is has to do with wm size hints.  Gtk+ enforces size
hits by itself, and then the window manager also does it.  There is a race
condition in there somewhere, so that Emacs resizes itself one time too many.

But I am working on it.

	Jan D.

Re: [werner@suse.de: Several problems in KDE/KWin]

[Andreas Schwab]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> On Fri, 07 Dec 2007 20:08:00 +0100 Andreas Schwab <schwab@suse.de> wrote:
>
>> If you try to maximize a second time the frame is actually truely
>> maximized.  
>
> This is so if you maximize either vertically (mouse-2) or horizontally
> (mouse-3) but not for both dimensions simultaneously (mouse-1).

I don't see any difference between these three operations.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [werner@suse.de: Several problems in KDE/KWin]

[Stephen Berman]

On Sat, 08 Dec 2007 10:30:04 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Stephen Berman skrev:
>> On Fri, 07 Dec 2007 20:08:00 +0100 Andreas Schwab <schwab@suse.de> wrote:
>> 
>>> If you try to maximize a second time the frame is actually truely
>>> maximized.  
>> 
>> This is so if you maximize either vertically (mouse-2) or horizontally
>> (mouse-3) but not for both dimensions simultaneously (mouse-1).
>> 
>>>             But unmaximizing restores intermediate, nearly maximized
>>> size, not the original one.
>> 
>> This behavior has varied in the course of Emacs 22 development.  For
>> further details see
>> <http://permalink.gmane.org/gmane.emacs.devel/77970>.
>> 
>
> It is the same root cause as the "describe-{function,variable} shrinks
> frame (GTK+/KDE)" problem
> (http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01108.html).

I suspected this was the case.

> I so far figured out that is has to do with wm size hints.  Gtk+
> enforces size hits by itself, and then the window manager also does
> it.  There is a race condition in there somewhere, so that Emacs
> resizes itself one time too many.
>
> But I am working on it.

I am grateful for that and would be glad to help by testing or anything
else I can do.

Steve Berman

Re: [werner@suse.de: Several problems in KDE/KWin]

[Stephen Berman]

On Sat, 08 Dec 2007 10:41:44 +0100 Andreas Schwab <schwab@suse.de> wrote:

> Stephen Berman <Stephen.Berman@gmx.net> writes:
>
>> On Fri, 07 Dec 2007 20:08:00 +0100 Andreas Schwab <schwab@suse.de> wrote:
>>
>>> If you try to maximize a second time the frame is actually truely
>>> maximized.  
>>
>> This is so if you maximize either vertically (mouse-2) or horizontally
>> (mouse-3) but not for both dimensions simultaneously (mouse-1).
>
> I don't see any difference between these three operations.

Interesting.  I see what I wrote with emacs -Q on GNU Emacs 23.0.50.3
(i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2007-11-29 running in KDE
3.5.8-2.2 under openSUSE 10.3.  In particular, if I click the maximize
button in the frame with mouse-1 a second time, the frame expands to
true maximum for a fraction of a second but then snaps back to the
previous not quite maximum size.  With mouse-2 or mouse-3, in contrast,
clicking maximize a second time or more toggles between true and not
quite maximum.  What KDE and OS are you using?

Steve Berman

Re: [werner@suse.de: Several problems in KDE/KWin]

[Andreas Schwab]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> What KDE and OS are you using?

10.3 as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [werner@suse.de: Several problems in KDE/KWin]

[Stephen Berman]

On Sat, 08 Dec 2007 16:40:58 +0100 Andreas Schwab <schwab@suse.de> wrote:

> Stephen Berman <Stephen.Berman@gmx.net> writes:
>
>> What KDE and OS are you using?
>
> 10.3 as well.

There must be something else different between our setups.  Are you
using the gtk-qt engine from kcm_gtk-0.7svn20070827-21.1 with the
default theme (I think QtCurve)?

Steve Berman

Re: [werner@suse.de: Several problems in KDE/KWin]

[Andreas Schwab]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> There must be something else different between our setups.  Are you
> using the gtk-qt engine from kcm_gtk-0.7svn20070827-21.1 with the
> default theme (I think QtCurve)?

Yes.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [werner@suse.de: Several problems in KDE/KWin]

[Stephen Berman]

On Sat, 08 Dec 2007 18:32:12 +0100 Andreas Schwab <schwab@suse.de> wrote:

> Stephen Berman <Stephen.Berman@gmx.net> writes:
>
>> There must be something else different between our setups.  Are you
>> using the gtk-qt engine from kcm_gtk-0.7svn20070827-21.1 with the
>> default theme (I think QtCurve)?
>
> Yes.

I can't think of any other relevant possible difference.  Can you?

Steve Berman

Re: [werner@suse.de: Several problems in KDE/KWin]

[Jan Djärv]

Stephen Berman skrev:
> On Sat, 08 Dec 2007 10:30:04 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> Stephen Berman skrev:
>>> On Fri, 07 Dec 2007 20:08:00 +0100 Andreas Schwab <schwab@suse.de> wrote:
>>>
>>>> If you try to maximize a second time the frame is actually truely
>>>> maximized.  
>>> This is so if you maximize either vertically (mouse-2) or horizontally
>>> (mouse-3) but not for both dimensions simultaneously (mouse-1).
>>>
>>>>             But unmaximizing restores intermediate, nearly maximized
>>>> size, not the original one.
>>> This behavior has varied in the course of Emacs 22 development.  For
>>> further details see
>>> <http://permalink.gmane.org/gmane.emacs.devel/77970>.
>>>
>> It is the same root cause as the "describe-{function,variable} shrinks
>> frame (GTK+/KDE)" problem
>> (http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01108.html).
> 
> I suspected this was the case.
> 
>> I so far figured out that is has to do with wm size hints.  Gtk+
>> enforces size hits by itself, and then the window manager also does
>> it.  There is a race condition in there somewhere, so that Emacs
>> resizes itself one time too many.
>>
>> But I am working on it.
> 
> I am grateful for that and would be glad to help by testing or anything
> else I can do.

Can you test this again with a fresh checkout from CVS HEAD?  I've made
changes that should produce a different behaviour.  But if it is correct or not...

Sorry for taking so long on this bug.

	Jan D.

Re: [werner@suse.de: Several problems in KDE/KWin]

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Can you test this again with a fresh checkout from CVS HEAD?  I've made
> changes that should produce a different behaviour.  But if it is correct or not...

I did not notice any change in behaviour.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [werner@suse.de: Several problems in KDE/KWin]

[Jan Djärv]

Andreas Schwab skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Can you test this again with a fresh checkout from CVS HEAD?  I've made
>> changes that should produce a different behaviour.  But if it is correct or not...
> 
> I did not notice any change in behaviour.
> 

And that behaviour is...?

	Jan D.

Re: [werner@suse.de: Several problems in KDE/KWin]

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Andreas Schwab skrev:
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>
>>> Can you test this again with a fresh checkout from CVS HEAD?  I've made
>>> changes that should produce a different behaviour.  But if it is correct or not...
>>
>> I did not notice any change in behaviour.
>>
>
> And that behaviour is...?

As described in the thread.  The bug still remains.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [werner@suse.de: Several problems in KDE/KWin]

[Jan Djärv]

Andreas Schwab skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Andreas Schwab skrev:
>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>>
>>>> Can you test this again with a fresh checkout from CVS HEAD?  I've made
>>>> changes that should produce a different behaviour.  But if it is correct or not...
>>> I did not notice any change in behaviour.
>>>
>> And that behaviour is...?
> 
> As described in the thread.  The bug still remains.

AFAIK there where two bugs, frame shrinks when tool bar is added/removed, and
maximize with KWin does not really maximize.  Which one did you test?

	Jan D.

Re: [werner@suse.de: Several problems in KDE/KWin]

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> AFAIK there where two bugs, frame shrinks when tool bar is added/removed, and
> maximize with KWin does not really maximize.  Which one did you test?

I don't see any change in behaviour for both cases.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [werner@suse.de: Several problems in KDE/KWin]

[Jan Djärv]

Andreas Schwab skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> AFAIK there where two bugs, frame shrinks when tool bar is added/removed, and
>> maximize with KWin does not really maximize.  Which one did you test?
> 
> I don't see any change in behaviour for both cases.
> 

Ok,

	Jan D.

Re: [werner@suse.de: Several problems in KDE/KWin]

[Stephen Berman]

On Sat, 01 Mar 2008 16:05:54 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Stephen Berman skrev:
>> On Sat, 08 Dec 2007 10:30:04 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
>> 
>>> Stephen Berman skrev:
>>>> On Fri, 07 Dec 2007 20:08:00 +0100 Andreas Schwab <schwab@suse.de> wrote:
>>>>
>>>>> If you try to maximize a second time the frame is actually truely
>>>>> maximized.  
>>>> This is so if you maximize either vertically (mouse-2) or horizontally
>>>> (mouse-3) but not for both dimensions simultaneously (mouse-1).
>>>>
>>>>>             But unmaximizing restores intermediate, nearly maximized
>>>>> size, not the original one.
>>>> This behavior has varied in the course of Emacs 22 development.  For
>>>> further details see
>>>> <http://permalink.gmane.org/gmane.emacs.devel/77970>.
>>>>
>>> It is the same root cause as the "describe-{function,variable} shrinks
>>> frame (GTK+/KDE)" problem
>>> (http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01108.html).
[...]
> Can you test this again with a fresh checkout from CVS HEAD?  I've
> made changes that should produce a different behaviour.  But if it is
> correct or not...

I do notice some differences, but as Andreas Schwab said, the bug(s)
still remain(s).  When I tested this prior to the unicode merge, I just
used the default font for my system with emacs -Q.  Now I have tried a
few different fonts and pixel sizes on the builds I have (using
set-frame-font for the pre-unicode-merge builds), and I find a variety
of behaviors with respect to maximizing and restoring either
horizontally (mouse-3) or vertically (mouse-2).  But I haven't found any
combinations that allows restoring after maximizing with mouse-1 (both
dimensions simultaneously) (and maximizing with mouse-1 is not
"maximal", as previously detailed; this is also the case where
restoration fails in one dimension).  Also, in each case where mouse-3
is restorable but mouse-2 is not (i.e. horizontally but not vertically),
restoration only works if the frame is not vertically maximized.

Here is a summary of the tests I have made (the latest build contains
your changes):

======================================================================
Frame maximization tests in KDE: 
mouse-1 maximizes both vertically and horizontally, mouse-2 only
vertically, mouse-3 only horizontally
+ => restoring from maximized succeeds, - => restoring fails


GNU Emacs 22.1.1 (i586-suse-linux-gnu, GTK+ Version 2.12.0) of
2007-11-24 on dede
-q (-ETL-Fixed-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1):
                              mouse-1 -      mouse-2 -      mouse-3 -
-misc-dejavu sans mono-medium-r-normal--0-0-0-0-m-0-iso8859-15:
                              mouse-1 -      mouse-2 -      mouse-3 +

GNU Emacs 23.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of
2008-01-16 on escher
-Q:                           mouse-1 -      mouse-2 -      mouse-3 -
-misc-dejavu sans mono-medium-r-normal--0-0-0-0-m-0-iso8859-15:
                              mouse-1 -      mouse-2 -      mouse-3 +
-misc-dejavu sans mono-bold-r-normal--0-0-0-0-m-0-iso8859-15:
                              mouse-1 -      mouse-2 -      mouse-3 +
-misc-dejavu sans-condensed-bold-r-semicondensed--0-0-0-0-p-0-iso8859-15:
                              mouse-1 -      mouse-2 +      mouse-3 +
-misc-dejavu sans-condensed-medium-r-semicondensed--0-0-0-0-p-0-iso8859-15:
                              mouse-1 -      mouse-2 +      mouse-3 -

GNU Emacs 23.0.60.7 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of
2008-02-21 on escher
-Q (`C-u C-x =' says
    -Misc-Fixed-Medium-R-Normal--15-140-75-75-C-90-ISO10646-1 but the
    font looks like what on my system is called "Sony Fixed"):
                              mouse-1 -     mouse-2 -      mouse-3 -
-Q -fn "Dejavu Sans Mono-10": mouse-1 -     mouse-2 -      mouse-3 +
-Q -fn "Dejavu Sans Mono-12": mouse-1 -     mouse-2 -      mouse-3 -
-Q -fn "Albany AMT-10":       mouse-1 -     mouse-2 +      mouse-3 -
-Q -fn "Albany AMT-12":       mouse-1 -     mouse-2 -      mouse-3 +
-Q -fn "Times-12":            mouse-1 -     mouse-2 -      mouse-3 -
-Q -fn "Times-14":            mouse-1 -     mouse-2 -      mouse-3 +
-Q -fn "Times-16":            mouse-1 -     mouse-2 -      mouse-3 -

GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of
2008-03-03 on escher
-Q (Sony Fixed? see above):   mouse-1 -     mouse-2 -      mouse-3 -
-Q -fn "Dejavu Sans Mono-10": mouse-1 -     mouse-2 +      mouse-3 +
-Q -fn "Dejavu Sans Mono-12": mouse-1 -     mouse-2 -      mouse-3 -
-Q -fn "Albany AMT-10":       mouse-1 -     mouse-2 -      mouse-3 -
-Q -fn "Albany AMT-12":       mouse-1 -     mouse-2 -      mouse-3 +
-Q -fn "Times-12":            mouse-1 -     mouse-2 -      mouse-3 +
-Q -fn "Times-14":            mouse-1 -     mouse-2 -      mouse-3 -
-Q -fn "Times-16":            mouse-1 -     mouse-2 -      mouse-3 -

The pixel sizes with the Times fonts of the 2008-03-03 build are larger
than the sizes with corresponding fonts of the 2008-02-21 build,
e.g. Times-12 of the former is the same size as Times-14 of the latter.

Steve Berman