bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22000: Patch addressing the menu-bar frame-resize interaction


From: Vivek Dasmohapatra
Subject: bug#22000: Patch addressing the menu-bar frame-resize interaction
Date: Thu, 19 Jul 2018 13:04:55 +0100 (BST)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

Can you point me to where gtk does that?

Backtrace (attached):

  gdk_frame_clock_paint_idle
  …
  → gtk_container_idle_sizer
  …
  → gtk_distribute_natural_allocation

Is the path, I think.

I suppose the container respecting its wishes is that of the Emacs
frame's window.  And if that container were a scrolled window, it
would not auto-resize.  Do I reason correctly?

Initially it's the box (vbox?) that the menubar is added to.
Not sure that's the top level widget.

I'm probably too silly to understand the semantics of containers: The
menu bar widget's size is not fixed so its RTL behavior (and the
font/translation issues gtkfixed talks about) would not be affected.

I'm not overly familiar with GTK myself - I'm just going by the docs
for gtk fixed. You may be correct: I'm not going to speculate further
or try to understand the underlying code, I'm just going to try it :)

Only the "virtual" container we'd add would have fixed size but this
does not mean that it passes on the fixed size property to the menu
bar's widget.  Inherently, this means that we would be cheating GTK
another time.  Or am I wrong?

IIUC you are right - that's how you're supposed to do it - I just don't
know if there's a non-deprecated widget that does what we want.

Worst case scenario: If I grab the scrolled window class and mutilate it
till it does what we want, would you consider emacs carrying that widget
class in its code? It shouldn't change any of the build dependencies.

NOTE: FWIW even the hbox and vbox we are using are deprecated and have
been for a while, so this whole area of code is going to need to be converted over to gtk grid at some point anyway.

You can turn scrollbars off in a scrolled window but unfortunately

This is incoherent, at least.  Could we suppress horizontal scroll
bars separately in a scrolled window (because I think that these are
responsible for the height increase of the menu bar)?

You can suppress the scrollbars independently, but that's what restores
the unwanted resizing behaviour in that direction: Suppress the vertical
scrollbar and suddenly vertical size requests are honoured, suppress
the horizontal and suddenly the menu bar can force the frame size again.

Attachment: gdb.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]