unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Yuri D'Elia <yuri.delia@eurac.edu>
To: martin rudalics <rudalics@gmx.at>, Jan D. <jan.h.d@swipnet.se>
Cc: 19990@debbugs.gnu.org
Subject: bug#19990: 24.4; Bad resizing interaction when WM ignores size hints
Date: Fri, 6 Mar 2015 11:53:08 +0100	[thread overview]
Message-ID: <54F98714.10603@eurac.edu> (raw)
In-Reply-To: <54F9718B.8070409@gmx.at>

On 03/06/2015 10:21 AM, martin rudalics wrote:
> The OP said that:
> 
>     I force the emacs frame to take the height of the entire screen.
> 
> So this looks like a fullheight frame to me without, apparently,
> explicitly specifying it as such.

I should have never said 'full screen height', since this keeps
confusing you. In my particular configuration, I have no window borders,
so two windows side-by-side will automatically fit the screen height.
This is *not* a special case for a tiling window manger.

A tiling window manager will force the frame to fit a screen region,
_possibly_ ignoring size hints. That's all there is to it. It does that
*intentionally*, since you can imagine that having gaps between the
tiles is just plainly annoying. In a side-by-side configuration, you
don't want gaps on the lower corner of the screen.

> Maybe the OP's problem is that the Window manager conceptually gives
> Emacs the full height of the screen and Gtk+ is not aware of that.
> Maybe also Gtk+ doesn't even understand fullheight.  At least I can't
> detect an entry for it in GtkWindowPrivate which OTOH has a 'tiled'
> entry.

The problem with Gtk+ is that it tries to handle hints both on behalf of
the window manger and on the client. I have *no* clue of why it does
that. Maybe to handle TWM? Or more probably to handle the "Windows" port
which has no such feature?

The second issue with Gtk+ is that it notifies the application while
doing his own hint handling (or again, is that intentional?).

I would be perfectly happy to discuss this issue with Gtk+ folks, but I
remember that back in Gtk 1.3/2.0 days, many of my patches where
rejected since they fixed behavior that wasn't really intended "for the
common user", whatever that means. Gtk 3 seems to have regressed even
more in this area, so I just gave up in trying to argue.

To sum up, however, what about this:

Since we receive the first ConfigureNotify event with the unhinted
width/height, we *can* detect that the size hints have been ignored.
Couldn't we disable them at that point? This would fix Gtk+ trying to do
a reconfiguration attempt and remove the following two useless events.
This looks like a simple fix that would already improve the current
configuration, but I would need experience with the Mac/Win port to tell
if Gtk would fail in this scenario. Maybe an "ifdef X11" is required.

The question then becomes: would actually be possible to set the hints
immediately back on, so that in a further resize request the WM sees the
hints, but *without* having Gtk+ do it's mess? This would mean that we
would need to set the hints back on when the resize request has been
fully settled. Tricky. Setting them back-on on a further repaint/focus
in/out event is either too late or not enough.

As mentioned in my first request, this is a minor nuance fix for folks
with tiling window managers. My point is "can we handle it better?".






  reply	other threads:[~2015-03-06 10:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03 11:38 bug#19990: 24.4; Bad resizing interaction when WM ignores size hints Yuri D'Elia
2015-03-03 17:47 ` martin rudalics
2015-03-03 18:41   ` Yuri D'Elia
2015-03-04 18:45     ` martin rudalics
2015-03-04 18:53       ` Yuri D'Elia
2015-03-04 19:22         ` Jan D.
2015-03-04 19:30           ` Yuri D'Elia
2015-03-04 19:38             ` Yuri D'Elia
2015-03-04 21:18             ` Jan D.
2015-03-05  8:04           ` martin rudalics
2015-03-05 16:36             ` Jan D.
2015-03-05 18:15               ` martin rudalics
2015-03-06  6:03                 ` Jan D.
2015-03-06  9:21                   ` martin rudalics
2015-03-06 10:53                     ` Yuri D'Elia [this message]
2015-03-06 17:05                       ` Jan D.
2015-03-06 17:19                         ` Yuri D'Elia
2015-03-06 18:54                       ` martin rudalics
2015-03-06 17:00                     ` Jan D.
2015-03-06 18:54                       ` martin rudalics
2015-03-07  8:00                         ` Jan D.
2015-03-05  8:04         ` martin rudalics
2020-02-29 18:05 ` Stefan Kangas
2020-03-01 21:24   ` Yuri D'Elia
2020-03-02  8:00     ` Stefan Kangas
2020-03-02  9:53       ` Yuri D'Elia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F98714.10603@eurac.edu \
    --to=yuri.delia@eurac.edu \
    --cc=19990@debbugs.gnu.org \
    --cc=jan.h.d@swipnet.se \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).