describe-{function,variable} shrinks frame (GTK+/KDE)

describe-{function,variable} shrinks frame (GTK+/KDE)

[Stephen Berman]

With GNU Emacs 23.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of
2007-11-13 on escher under KDE using gtk-qt engine I observe the
followin (I have not been able to reproduce this with the same Emacs
build under GNOME or twm):

1. emacs -Q ; M-: (frame-height) => 40
2. C-h i
3. C-h f RET webjump RET ; M-: (frame-height) => 40
4. C-x 1
5. C-h v RET kannada-consonant RET ; M-: (frame-height) => 39

This recipe isn't completely reliable: what seems to be constant are the
prior invocation of Info and unsplitting the windows between the
describe-* calls; otherwise, sometimes the shrinkage happens after the
first call to describe-{function,variable}, sometimes it takes several
iterations of steps 2.-5.  The function/variable names are examples,
probably any will do.  Once the shrinkage begins, it progresses with
subsequent describe-* calls.

I only noticed this recently.  My first suspicion was the changes to
help.el et al on 2007-11-06 (with-help-window etc.).  But then I tried a
build from 2007-09-23 I had saved and reproduced it with that, to my
surprise (I don't know how I could have failed to notice this behavior
before).  The latest build I still have prior to that is from
2007-08-24, just before the multi-tty merge: with this build I could not
induce the shrinkage.

Steve Berman

Re: describe-{function,variable} shrinks frame (GTK+/KDE)

[martin rudalics]

 > This recipe isn't completely reliable: what seems to be constant are the
 > prior invocation of Info and unsplitting the windows between the
 > describe-* calls; otherwise, sometimes the shrinkage happens after the
 > first call to describe-{function,variable}, sometimes it takes several
 > iterations of steps 2.-5.  The function/variable names are examples,
 > probably any will do.  Once the shrinkage begins, it progresses with
 > subsequent describe-* calls.

Leaving an Emacs frame for some time unattended with

(defun foo ()
   (interactive)
   (while t
     (split-window)
     (when (zerop (logand (random) 1))
       (other-window 1))
     (sit-for 0.5)
     (if (zerop (logand (random) 1))
	(delete-window)
       (delete-other-windows))
     (sit-for 0.5)))

doesn't show the behavior (just to rule out more trivial causes like
window splitting / deleting)?

Re: describe-{function,variable} shrinks frame (GTK+/KDE)

[Stephen Berman]

On Sat, 17 Nov 2007 10:16:17 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> This recipe isn't completely reliable: what seems to be constant are the
>> prior invocation of Info and unsplitting the windows between the
>> describe-* calls; otherwise, sometimes the shrinkage happens after the
>> first call to describe-{function,variable}, sometimes it takes several
>> iterations of steps 2.-5.  The function/variable names are examples,
>> probably any will do.  Once the shrinkage begins, it progresses with
>> subsequent describe-* calls.
>
> Leaving an Emacs frame for some time unattended with
>
> (defun foo ()
>   (interactive)
>   (while t
>     (split-window)
>     (when (zerop (logand (random) 1))
>       (other-window 1))
>     (sit-for 0.5)
>     (if (zerop (logand (random) 1))
> 	(delete-window)
>       (delete-other-windows))
>     (sit-for 0.5)))
>
> doesn't show the behavior (just to rule out more trivial causes like
> window splitting / deleting)?

No, this does not change frame-height.  In fact, I had already manually
tried repeatedly splitting and unspitting and did not see any problem.
But your test gave me an idea to try and reproduce the behavior I
observed programmatically.  I started Emacs with -Q and evalled the
following functions:

(defun srb-randsym ()
  "Return a random Emacs lisp symbol."
  (random t)
  (let* ((rnum (random (length obarray)))
	 (elt (aref obarray rnum)))
    elt))

(defun srb-shrink-test-0 ()
  "Call Info, then repeatedly call describe-function or
describe-variable on a random elisp function or variable, deleting
the Help buffer in between.  If the frame height changes, stop."
  (interactive)
  (info)
  (let ((ht (frame-height))
	elt)
    (message "frame height: %d" ht)
    (sit-for 0.5)
    (setq elt (srb-randsym))
    (while (not (or (functionp elt) (boundp elt)))
      (setq elt (srb-randsym)))
    (cond ((functionp elt) 
	   (describe-function elt))
	  ((boundp elt) 
	   (describe-variable elt))
	  (t 'ignore))
    (sit-for 0.5)
    (delete-other-windows)
    (sit-for 0.5)
    (if (= ht (frame-height))
	(srb-shrink-test-0)
      (message "frame height: %d" (frame-height)))))

I invoked srb-shrink-test-0 and let it run though many iterations, but
frame-height remained unchanged.  Then I evalled the following function,
which differs from the above only in calling
describe-{function,variable} interactively:

(defun srb-shrink-test-1 ()
  "Call Info, then repeatedly call describe-function or
describe-variable interactively, deleting the Help buffer in
between.  If the frame height changes, stop."
  (interactive)
  (info)
  (let ((ht (frame-height))
	elt)
    (message "frame height: %d" ht)
    (sit-for 0.5)
    (setq elt (srb-randsym))
    (while (not (or (functionp elt) (boundp elt)))
      (setq elt (srb-randsym)))
    (cond ((functionp elt) 
	   (call-interactively 'describe-function))
	  ((boundp elt) 
	   (call-interactively 'describe-variable))
	  (t 'ignore))
    (sit-for 0.5)
    (delete-other-windows)
    (sit-for 0.5)
    (if (= ht (frame-height))
	(srb-shrink-test-1)
      (message "frame height: %d" (frame-height)))))

I invoked this and frame-height diminished by one line after the first
interactive call.  I have repeated this many times and every time
frame-height has shrunk, whereas with srb-shrink-test-0 it has never
shrunk.  It seems that call-interactively is somehow involved in
shrinking frame-height.  I looked at the source code but found nothing
suggestive; but it is a very long and complex function, and I don't know
what to look for.  It doesn't help that this problem seems to be
restricted to GTK+ builds running under gtk-qt.

Steve Berman

Re: describe-{function,variable} shrinks frame (GTK+/KDE)

[martin rudalics]

 > I invoked this and frame-height diminished by one line after the first
 > interactive call.

That is after the sit-for and before the `delete-other-windows'

      (sit-for 0.5)
      (delete-other-windows)

your frame has got smaller by one line?  The fact that it gets smaller
by _one_ line and Info is involved might relate this to the header line.
Unfortunately, it seems impossible to turn that line off by setting
`Info-use-header-line', so I don't know how to test this.  You could try
with a non-Info buffer displaying a header-line.

 > I have repeated this many times and every time
 > frame-height has shrunk, whereas with srb-shrink-test-0 it has never
 > shrunk.  It seems that call-interactively is somehow involved in
 > shrinking frame-height.  I looked at the source code but found nothing
 > suggestive; but it is a very long and complex function, and I don't know
 > what to look for.  It doesn't help that this problem seems to be
 > restricted to GTK+ builds running under gtk-qt.

Maybe it's related to the KDE frame resizing problem you mentioned
earlier (I suppose you still get that after the merge).  Does changing
the font and/or changing the Info faces affect the behavior?

Re: describe-{function,variable} shrinks frame (GTK+/KDE)

[Stephen Berman]

On Sun, 18 Nov 2007 10:33:32 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> I invoked this and frame-height diminished by one line after the first
>> interactive call.
>
> That is after the sit-for and before the `delete-other-windows'
>
>      (sit-for 0.5)
>      (delete-other-windows)
>
> your frame has got smaller by one line?  

By stepping through srb-shrink-test-1 with edebug, I have seen the
reduction in frame-height occur in two places (on two different
invocations of srb-shrink-test-1 after emacs -Q): as above, after the
(sit-for 0.5) that immediately precedes (delete-other-windows), but also
after the (sit-for 0.5) that follows (delete-other-windows).

>                                          The fact that it gets smaller
> by _one_ line and Info is involved might relate this to the header line.
> Unfortunately, it seems impossible to turn that line off by setting
> `Info-use-header-line', so I don't know how to test this.  

I loaded the info library, did `M-x customize-variable RET
Info-use-header-line RET', clicked it to off with toggle button and set
it for the current session.  Then I invoked srb-shrink-test-1 and the
Info buffer came up without a header line (C-h v header-line-format in
that buffer said its value is nil).  Did you do the same thing and get a
different result, or did you do something else?  

Anyway, even without the Info header line, frame-height got reduced by
one line just as with the header line.  I also tried just loading info
and running srb-shrink-test-1 with the line (info) commented out: in
this case, frame-height did not change.

>                                                            You could try
> with a non-Info buffer displaying a header-line.

I tried variants of srb-shrink-test-1, respectively replacing (info)
with (ruler-mode 1), (tabbar-mode 1) (tabbar.el is an external library
that sets up a tabbed header line), and (setq header-line-format
"TEST"), but in each case frame-height did not change.  It seems that
the header line is not relevant, but invoking info is.

>> I have repeated this many times and every time
>> frame-height has shrunk, whereas with srb-shrink-test-0 it has never
>> shrunk.  It seems that call-interactively is somehow involved in
>> shrinking frame-height.  I looked at the source code but found nothing
>> suggestive; but it is a very long and complex function, and I don't know
>> what to look for.  It doesn't help that this problem seems to be
>> restricted to GTK+ builds running under gtk-qt.
>
> Maybe it's related to the KDE frame resizing problem you mentioned
> earlier 

I strongly suspect this is the case.  Unfortunately, I know nothing
about the gtk-qt engine and it seems that none of the core Emacs
developers uses it.

>         (I suppose you still get that after the merge).  

Yes, unfortunately.

>                                                          Does changing
> the font and/or changing the Info faces affect the behavior?

The frame-height reduction happens both with -Q as well as with my
personal settings, which use a different font.  I also tried it after
setting all the oversized Info faces to default and still got the
frame-height reduction.

Steve Berman

Re: describe-{function,variable} shrinks frame (GTK+/KDE)

[martin rudalics]

 > By stepping through srb-shrink-test-1 with edebug, I have seen the
 > reduction in frame-height occur in two places (on two different
 > invocations of srb-shrink-test-1 after emacs -Q): as above, after the
 > (sit-for 0.5) that immediately precedes (delete-other-windows), but also
 > after the (sit-for 0.5) that follows (delete-other-windows).

I still don't understand.  Does it shrink after describe-... _and_ after
`delete-other-windows'?

 >>Unfortunately, it seems impossible to turn that line off by setting
 >>`Info-use-header-line', so I don't know how to test this.
 >
 >
 > I loaded the info library, did `M-x customize-variable RET
 > Info-use-header-line RET', clicked it to off with toggle button and set
 > it for the current session.  Then I invoked srb-shrink-test-1 and the
 > Info buffer came up without a header line (C-h v header-line-format in
 > that buffer said its value is nil).  Did you do the same thing and get a
 > different result, or did you do something else?

I did the same thing and apparently got the same result but
misinterpreted it.

 > It seems that
 > the header line is not relevant, but invoking info is.

It's nonetheless interesting that it always shrinks by one line.  Could
you try with a very high frame (one that doesn't fit on your screen)?
Also, can you repeat it with info and `split-window' alone, that is,
without calling describe-... ?

Re: describe-{function,variable} shrinks frame (GTK+/KDE)

[Stephen Berman]

On Sun, 18 Nov 2007 23:21:27 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> By stepping through srb-shrink-test-1 with edebug, I have seen the
>> reduction in frame-height occur in two places (on two different
>> invocations of srb-shrink-test-1 after emacs -Q): as above, after the
>> (sit-for 0.5) that immediately precedes (delete-other-windows), but also
>> after the (sit-for 0.5) that follows (delete-other-windows).
>
> I still don't understand.  Does it shrink after describe-... _and_ after
> `delete-other-windows'?

Sorry, my explanation was rather convoluted.  Here is srb-shrink-test-1:

     1	(defun srb-shrink-test-1 ()
     2	  "Call Info, then repeatedly call describe-function or
     3	describe-variable interactively, deleting the Help buffer in
     4	between.  If the frame height changes, stop."
     5	  (interactive)
     6	  (info)
     7	  (let ((ht (frame-height))
     8		elt)
     9	    (message "frame height: %d" ht)
    10	    (sit-for 0.5)
    11	    (setq elt (srb-randsym))
    12	    (while (not (or (functionp elt) (boundp elt)))
    13	      (setq elt (srb-randsym)))
    14	    (cond ((functionp elt) 
    15		   (call-interactively 'describe-function))
    16		  ((boundp elt) 
    17		   (call-interactively 'describe-variable))
    18		  (t 'ignore))
    19	    (sit-for 0.5)
    20	    (delete-other-windows)
    21	    (sit-for 0.5)
    22	    (if (= ht (frame-height))
    23		(srb-shrink-test-1)
    24	      (message "frame height: %d" (frame-height)))))

What I meant is that, on distinct invocations of srb-shrink-test-1 after
emacs -Q, the point at which frame-height shrank was different: on one
invocation between lines 19 and 20, on another invocation between lines
21 and 22.  

Since my last post I have tested further, and have also seen the
shrinkage occur between lines 10 and 11, i.e. before calling describe-*.
In this case there was, within the same invocation of srb-shrink-test-1,
a further shrinkage between line 21 and 22, and a third shrinkage at the
end of srb-shrink-test-1, after the last message.  In other words,
before invoking srb-shrink-test-1, frame-height was 40, afterwards it
was 37.  (In the same test, I continued calling srb-shrink-test-1: after
the next call, frame height was 35, then (another invocation) 34, then
(another invocation) 34 again, then (same invocation with recursive
call) 33, then (another invocation) 33, then (same invocation with
recursive call) 32, then I stopped.)

I have also tried several other variants.  In view of the observations
in the preceding paragraph, I tried just calling info and sit-for but no
describe-*.  With this I got no frame-height reduction just by calling
the function, but when stepping through it with edebung, frame-height
shrank right after sit-for.  I also tried a version with no calls to
sit-for (but with calls to describe-*), sometimes getting a reduction in
frame-height, sometimes not.  I haven't been able to get a fix on the
behavior here.

I also found another conditioning element besides Info: namely,
emacs-w3m.  That, replacing in srb-shrink-test-1 (info) by (require
'w3m) and (w3m), I also observed shrinkage in frame-height.  Like Info,
emacs-w3m also has a customizable variable w3m-use-header-line; but
after toggling it off, setting for the current session, and then
starting w3m, the header line was still present.

>>>Unfortunately, it seems impossible to turn that line off by setting
>>>`Info-use-header-line', so I don't know how to test this.
>>
>>
>> I loaded the info library, did `M-x customize-variable RET
>> Info-use-header-line RET', clicked it to off with toggle button and set
>> it for the current session.  Then I invoked srb-shrink-test-1 and the
>> Info buffer came up without a header line (C-h v header-line-format in
>> that buffer said its value is nil).  Did you do the same thing and get a
>> different result, or did you do something else?
>
> I did the same thing and apparently got the same result but
> misinterpreted it.
>
>> It seems that
>> the header line is not relevant, but invoking info is.
>
> It's nonetheless interesting that it always shrinks by one line.  Could
> you try with a very high frame (one that doesn't fit on your screen)?

I could not get the height (or the width) to exceed the accessible
screen dimenions (either by modifying frame-parameters or by using the
-g command line option).  I don't know if this is dues to KDE or GTK+.
However, with (modify-frame-parameters frame '((fullscreen . fullboth)))
I did get a borderless Emacs frame filling the screen, and calling
srb-shrink-test-1 with this frame, I could not get a reduction in
frame-height. 

> Also, can you repeat it with info and `split-window' alone, that is,
> without calling describe-... ?

This behaved like the variant I mentioned above with just info and
sit-for: there was no frame-height reduction when just calling the
function, but there was a reduction when stepping through with edebug;
again, after sit-for, i.e. before split-window.  Note, however, that
when debugging with edebug, the frame is in fact split vertically, so
maybe that provides the necessary condition (but that doesn't explain
why I did not get the reduction here outside of edebug...).

So far, the more I've tested, the muddier the water has become, and I
think I've failed to achieve real insight into what's going on.

Steve Berman 

GTK+/KDE frame shrinking has to do with tool bar (was Re: describe-{function, variable} shrinks frame (GTK+/KDE))

[Stephen Berman]

On Mon, 19 Nov 2007 14:53:27 +0100 Stephen Berman
<Stephen.Berman@gmx.net> wrote: 

> So far, the more I've tested, the muddier the water has become, and I
> think I've failed to achieve real insight into what's going on.

I think I've hit upon a bit of insight.  I think the reduction in
frame-height is conditioned by (or at least related to) the presence of
a tool bar containing at least one icon that does not belong to the
theme currently used by the gtk-qt engine.  Both the Info and w3m tool
bar are cases in point.  In addition, when I start Emacs with -Q -D,
i.e. without a tool bar, then I do not get the frame-height reduction
with the functions I defined (which do induce the frame-height reduction
with -Q, where there is a tool bar).  I've also come up with a test case
that involves neither Info, w3m, nor describe-*.  I start emacs -Q and
evaluate the following:

(defvar srb-tool-bar-map
  (let ((tool-bar-map (make-sparse-keymap)))
    (tool-bar-add-item "prev-node" 'ignore 'ignore :help "Do nothing")
    tool-bar-map))

(defun srb-mode ()
  (interactive)
  (kill-all-local-variables)
  (setq major-mode 'srb-mode)
  (setq mode-name "srb")
  (set (make-local-variable 'tool-bar-map) srb-tool-bar-map))

(defun srb-shrink-test ()
  (interactive)
  (message "frame height: %d" (frame-height))
  (with-current-buffer (get-buffer-create "*srb-shrink-test 1*")
    (srb-mode))
  (pop-to-buffer "*srb-shrink-test 2*")
  (sit-for 0.5)
  (delete-window)
  (switch-to-buffer "*srb-shrink-test 1*")
  (sit-for 0.5)
  (message "frame height: %d" (frame-height)))

When I invoke srb-shrink-test after emacs -Q, the first message is
"frame height: 40", the second is "frame height: 39".  Stepping through
with edebug, I see the reduction occur after the second sit-for.  If I
delete any line in srb-shrink-test or change the order, there is no
frame-height reduction.

If I am correct in implicating non-theme icons, then I would expect the
turning point for getting the frame-height reduction to be this change:

2007-09-02  Jan Djärv  <jan.h.d@swipnet.se>

	* term/x-win.el (x-gtk-stock-map): Map diropen to system-file-manager.
	(icon-map-list): New variable.
	(x-gtk-map-stock): Use icon-map-list.

Prior to this, diropen was mapped to a non-theme icon.  And indeed,
srb-shrink-test does not reduce frame-height on a GTK+ build from
2007-08-29 (immediately post-multi-tty-merge), nor does my test
involving Info, posted previously in this thread.  Strangely, however,
my test involving w3m does show frame-height reduction.  I don't know if
this means I'm wrong to suspect non-theme icons or if the w3m tool bar
has other properties that cause the frame-height reduction (it contains
no icons from the current gtk-qt theme).  In any case, as I mentioned
earlier in this thread, on a pre-multi-tty build from 2007-08-24, I do
not get any frame-height reduction, whether with srb-shrink-test, with
the test involving Info, or even with the test involving w3m.  (Jan
D. added support for themed icons on 2007-08-28, one day before the
multi-tty merge, but as noted, that did not include a themed icon for
diropen.)

Regardless of whether, or how much, the frame-height reduction is due to
non-theme icons, there is another related frame-height problem that I've
seen only under the gtk-qt engine on KDE.  Namely, tool bars that
contain non-theme icons, including the Info, w3m, and Gnus tool bars,
are slightly taller (by one or two pixels) than tool bars containing
only themed icons (e.g. those in Text and Fundamental mode).  As a
consequence, whenever I switch between buffers with differently high
tool bars, the entire frame changes in height by that much.  This is
particularly disconcerting when I use the minibuffer (Fundamental mode)
or have split windows.

I presume that none of the core Emacs developers uses the gtk-qt engine
(do any of you regularly use KDE?) and can therefore understand that
Emacs problems involving it are not a high priority, but if anyone has
any suggestions I would be grateful.  (Unfortunately, I know nothing
about either the gtk-qt or the Gtk+ source code.  But the problems I
mentioned here, as well as in earlier posts about frame maximization, I
have seen only with Emacs but with no other Gtk+ apps in KDE, which
presumably also use the gtk-qt engine.)

Steve Berman 

Re: GTK+/KDE frame shrinking has to do with tool bar (was Re: describe-{function, variable} shrinks frame (GTK+/KDE))

[martin rudalics]

I can't tell because I don't use the toolbar.  But I think Emacs should
stick to the following simple rule: Whatever a user does with the
toolbar (toggle it, change the theme, ...) the height of the frame must
remain unaffected as long as it is larger than that of the toolbar.

Re: GTK+/KDE frame shrinking has to do with tool bar (was Re: describe-{function, variable} shrinks frame (GTK+/KDE))

[Jan Djärv]

Thanks for the explanation and the test case.

It may very well be that those 2 missing pixels causes some rounding error and 
that the frame shrinks.  As the code is now, we just accept the size the tool 
bar sets itself internally.  We could try something else, i.e. a fixed size or 
perhaps never shrink, just grow.  With themed icons, you never know how large 
or small they are going to be.

But I suspect there is a bug in the resize logic here, only the tool bar 
should expand/shrink, not the number of lines.  I'm going to debug it, but it 
may take a few days, I am not at home right now.

BTW, what KDE and gtk-qt engine version do you have?  Is there any special 
theme to use to get this effect?

	Jan D.


Stephen Berman skrev:
> On Mon, 19 Nov 2007 14:53:27 +0100 Stephen Berman
> <Stephen.Berman@gmx.net> wrote: 
> 
>> So far, the more I've tested, the muddier the water has become, and I
>> think I've failed to achieve real insight into what's going on.
> 
> I think I've hit upon a bit of insight.  I think the reduction in
> frame-height is conditioned by (or at least related to) the presence of
> a tool bar containing at least one icon that does not belong to the
> theme currently used by the gtk-qt engine.  Both the Info and w3m tool
> bar are cases in point.  In addition, when I start Emacs with -Q -D,
> i.e. without a tool bar, then I do not get the frame-height reduction
> with the functions I defined (which do induce the frame-height reduction
> with -Q, where there is a tool bar).  I've also come up with a test case
> that involves neither Info, w3m, nor describe-*.  I start emacs -Q and
> evaluate the following:
> 
> (defvar srb-tool-bar-map
>   (let ((tool-bar-map (make-sparse-keymap)))
>     (tool-bar-add-item "prev-node" 'ignore 'ignore :help "Do nothing")
>     tool-bar-map))
> 
> (defun srb-mode ()
>   (interactive)
>   (kill-all-local-variables)
>   (setq major-mode 'srb-mode)
>   (setq mode-name "srb")
>   (set (make-local-variable 'tool-bar-map) srb-tool-bar-map))
> 
> (defun srb-shrink-test ()
>   (interactive)
>   (message "frame height: %d" (frame-height))
>   (with-current-buffer (get-buffer-create "*srb-shrink-test 1*")
>     (srb-mode))
>   (pop-to-buffer "*srb-shrink-test 2*")
>   (sit-for 0.5)
>   (delete-window)
>   (switch-to-buffer "*srb-shrink-test 1*")
>   (sit-for 0.5)
>   (message "frame height: %d" (frame-height)))
> 
> When I invoke srb-shrink-test after emacs -Q, the first message is
> "frame height: 40", the second is "frame height: 39".  Stepping through
> with edebug, I see the reduction occur after the second sit-for.  If I
> delete any line in srb-shrink-test or change the order, there is no
> frame-height reduction.
> 
> If I am correct in implicating non-theme icons, then I would expect the
> turning point for getting the frame-height reduction to be this change:
> 
> 2007-09-02  Jan Djärv  <jan.h.d@swipnet.se>
> 
> 	* term/x-win.el (x-gtk-stock-map): Map diropen to system-file-manager.
> 	(icon-map-list): New variable.
> 	(x-gtk-map-stock): Use icon-map-list.
> 
> Prior to this, diropen was mapped to a non-theme icon.  And indeed,
> srb-shrink-test does not reduce frame-height on a GTK+ build from
> 2007-08-29 (immediately post-multi-tty-merge), nor does my test
> involving Info, posted previously in this thread.  Strangely, however,
> my test involving w3m does show frame-height reduction.  I don't know if
> this means I'm wrong to suspect non-theme icons or if the w3m tool bar
> has other properties that cause the frame-height reduction (it contains
> no icons from the current gtk-qt theme).  In any case, as I mentioned
> earlier in this thread, on a pre-multi-tty build from 2007-08-24, I do
> not get any frame-height reduction, whether with srb-shrink-test, with
> the test involving Info, or even with the test involving w3m.  (Jan
> D. added support for themed icons on 2007-08-28, one day before the
> multi-tty merge, but as noted, that did not include a themed icon for
> diropen.)
> 
> Regardless of whether, or how much, the frame-height reduction is due to
> non-theme icons, there is another related frame-height problem that I've
> seen only under the gtk-qt engine on KDE.  Namely, tool bars that
> contain non-theme icons, including the Info, w3m, and Gnus tool bars,
> are slightly taller (by one or two pixels) than tool bars containing
> only themed icons (e.g. those in Text and Fundamental mode).  As a
> consequence, whenever I switch between buffers with differently high
> tool bars, the entire frame changes in height by that much.  This is
> particularly disconcerting when I use the minibuffer (Fundamental mode)
> or have split windows.
> 
> I presume that none of the core Emacs developers uses the gtk-qt engine
> (do any of you regularly use KDE?) and can therefore understand that
> Emacs problems involving it are not a high priority, but if anyone has
> any suggestions I would be grateful.  (Unfortunately, I know nothing
> about either the gtk-qt or the Gtk+ source code.  But the problems I
> mentioned here, as well as in earlier posts about frame maximization, I
> have seen only with Emacs but with no other Gtk+ apps in KDE, which
> presumably also use the gtk-qt engine.)
> 
> Steve Berman 
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: GTK+/KDE frame shrinking has to do with tool bar

[Stephen Berman]

On Tue, 20 Nov 2007 08:33:21 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Thanks for the explanation and the test case.
>
> It may very well be that those 2 missing pixels causes some rounding
> error and that the frame shrinks.  As the code is now, we just accept
> the size the tool bar sets itself internally.  We could try something
> else, i.e. a fixed size or perhaps never shrink, just grow.  With
> themed icons, you never know how large or small they are going to be.

Really?  I would have assumed there are standard sizes (but that
wouldn't guarantee that non-theme icons would be available in the
appropriate size).

> But I suspect there is a bug in the resize logic here, only the tool
> bar should expand/shrink, not the number of lines.  I'm going to debug
> it, but it may take a few days, I am not at home right now.

I would appreciate that, and let me know if I can do anything at this
end to help.

> BTW, what KDE and gtk-qt engine version do you have?  

KDE is 3.5.8-2.2, gtk-qt engine is from kcm_gtk-0.7svn20070827-16 (RPMs
for openSUSE 10.3).

>                                                       Is there any
> special theme to use to get this effect?

I'm using the default GTK style of openSUSE 10.3, which I believe is
QtCurve (it's just labelled "default" in my personal KDE configuration
file, but the systemwide configuration file refers to QtCurve).  To see
the effect of changing the style it is necessary to restart KDE, which
is rather onerous to do repeatedly.  When I have some time to do that
systematically and find differences depending on the theme, I'll report
back about it.

Steve Berman

Re: describe-{function,variable} shrinks frame (GTK+/KDE)

[Richard Stallman]

Can you try building sources from various dates
to see which change caused the problem?
With binary search you could localize it in a few days
with little actually attention from you.

Re: describe-{function,variable} shrinks frame (GTK+/KDE)

[Stephen Berman]

On Sat, 17 Nov 2007 18:30:50 -0500 Richard Stallman <rms@gnu.org> wrote:

> Can you try building sources from various dates
> to see which change caused the problem?
> With binary search you could localize it in a few days
> with little actually attention from you.

I'll try to do that as soon as I can.

Steve Berman