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
<address@hidden> 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  <address@hidden>

        * 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