bug#17120: Fwd: Error displaying a frame modified with (tool-bar-lines . 0)

bug#17120: Fwd: Error displaying a frame modified with (tool-bar-lines . 0)

[Juanma Barranquero]

Package: emacs
Severity: minor
X-Debbugs-CC: robert@capuchin.co.uk


This is the underlying bug with GTK and Emacs that caused bug#17046.

It's minor because it's unlikely that modifying frames' heights with
tool-bar-lines = 0 be a common operation.


  emacs -Q -l bug.el

with bug.el:

;;; bug.el
(let* ((default-frame-alist nil)
       (frame (make-frame '((width . 80) (height . 20))))
       (lines (frame-parameter frame 'tool-bar-lines)))
  (discard-input)
  (read-event nil nil 2)
  (modify-frame-parameters frame '((tool-bar-lines . 0)
                                   (width . 60) (height . 25)))
  (modify-frame-parameters frame `((tool-bar-lines . ,lines))))
;;, end

causes the frame to be redisplayed incorrectly (the trigger being the
(tool-bar-lines . 0) parameter:

http://debbugs.gnu.org/cgi/bugreport.cgi?msg=26;filename=emacs-sshot.png;att=1;bug=17046

This happens on a Ubuntu 13.10:

GNU Emacs 24.3.50.2 (i686-pc-linux-gnu, GTK+ Version 3.8.6)
 of 2014-03-14 on poulenc
Repository revision: 116756 rudalics <at> gmx.at-20140314103846-ytcz7b30ocmzo8jh
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description: Ubuntu 13.10

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

bug#17120: Fwd: Error displaying a frame modified with (tool-bar-lines . 0)

[Robert Marshall]

Jan Djärv writes:
 > Hello.
 > 
 > Is this still an issue?  I can't reproduce it on Mint 16, Gtk+ 3.8.7.
 > It could be window manager related.  Are you running Unity?
 > I'll see if I have some Ubuntu lying around.
 >
 
Yes it's still replicable - I'm running kde/plasma

I've just tried running the test in an Xnest session with
fluxbox/windowMaker/sawfish and in all cases the session crashes with

X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  70 (X_PolyFillRectangle)
  Resource id in failed request:  0x0
  Serial number of failed request:  30246
  Current serial number in output stream:  30246

at the point where the second emacs frame appears. Maybe they (or Xnest)
can't cope with the weird window.

With unity there doesn't seem to be a --display option and running it
from a normal session the bug doesn't appear - the 2nd frame is drawn
normally so the bug looks very window manager related.

Robert

bug#17120: Fwd: Error displaying a frame modified with (tool-bar-lines . 0)

[Robert Marshall]

Jan Djärv writes:
 > Hello.
 > 
 > Is this still an issue?  I can't reproduce it on Mint 16, Gtk+ 3.8.7.
 > It could be window manager related.  Are you running Unity?
 > I'll see if I have some Ubuntu lying around.
 > 

One point I should add to that last comment (of mine)- it was buried
somewhere in the original 17046 bug thread - I only see the problem if
the emacs frames doesn't get keyboard focus until after the startup
has completed - I assume that's also why eval'ing that expression in
*scratch* doesn't show the problem. So you may need to reconfigure
your X session if it is set up so that new windows get focus automatically.

The frames look ok until the moment I give them focus when the minibuffer
and the X decorations then disappear.

Robert
-- 
Robert Marshall

bug#17120: Fwd: Error displaying a frame modified with (tool-bar-lines . 0)

[martin rudalics]

 > This is the underlying bug with GTK and Emacs that caused bug#17046.
 >
 > It's minor because it's unlikely that modifying frames' heights with
 > tool-bar-lines = 0 be a common operation.
 >
 >
 >    emacs -Q -l bug.el
 >
 > with bug.el:
 >
 > ;;; bug.el
 > (let* ((default-frame-alist nil)
 >         (frame (make-frame '((width . 80) (height . 20))))
 >         (lines (frame-parameter frame 'tool-bar-lines)))
 >    (discard-input)
 >    (read-event nil nil 2)
 >    (modify-frame-parameters frame '((tool-bar-lines . 0)
 >                                     (width . 60) (height . 25)))
 >    (modify-frame-parameters frame `((tool-bar-lines . ,lines))))
 > ;;, end
 >
 > causes the frame to be redisplayed incorrectly (the trigger being the
 > (tool-bar-lines . 0) parameter:
 >
 > http://debbugs.gnu.org/cgi/bugreport.cgi?msg=26;filename=emacs-sshot.png;att=1;bug=17046
 >
 > This happens on a Ubuntu 13.10:
 >
 > GNU Emacs 24.3.50.2 (i686-pc-linux-gnu, GTK+ Version 3.8.6)
 >   of 2014-03-14 on poulenc
 > Repository revision: 116756 rudalics <at> gmx.at-20140314103846-ytcz7b30ocmzo8jh
 > Windowing system distributor `The X.Org Foundation', version 11.0.11405000
 > System Description: Ubuntu 13.10

I now checked in a fix.  Please have a look.

On builds with an internal tool bar you have to, for example,

(setq frame-inhibit-implied-resize nil)

to get the desired 25 lines.  Otherwise, the

(tool-bar-lines . ,lines)

will steal the necessary lines from the frame's text area.

Thanks, martin

bug#17120: Fwd: Error displaying a frame modified with (tool-bar-lines . 0)

[martin rudalics]

tags 17120 fixed
close 17120 28.1
quit

 > I now checked in a fix.  Please have a look.
 >
 > On builds with an internal tool bar you have to, for example,
 >
 > (setq frame-inhibit-implied-resize nil)
 >
 > to get the desired 25 lines.  Otherwise, the
 >
 > (tool-bar-lines . ,lines)
 >
 > will steal the necessary lines from the frame's text area.

Bug marked as done now.

martin