all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Jan D." <jan.h.d@swipnet.se>
To: martin rudalics <rudalics@gmx.at>, Yuri D'Elia <yuri.delia@eurac.edu>
Cc: 19990@debbugs.gnu.org
Subject: bug#19990: 24.4; Bad resizing interaction when WM ignores size hints
Date: Thu, 05 Mar 2015 17:36:07 +0100	[thread overview]
Message-ID: <54F885F7.80803@swipnet.se> (raw)
In-Reply-To: <54F80E26.1070608@gmx.at>

martin rudalics skrev den 2015-03-05 09:04:
>  > Gtk+ does have code that tries to resize a window if it did not get
> the size it requested.
>
> How does it do that?

It keeps track of what resize it has done, and when the ConfigureNotify 
event arrives, it checks to see if it matches its constraints.  See code 
in Gtk+, gtkwindow.c (it is a mess).


> Why does a first resize with an odd size
> apparently get through at all?

Why shouldn't it?

>  Can't Gtk+ intercept thet first request?
> And how comes that Gtk+ is apparently not able to intercept the focus in
> reqest in the same way?

What do you mean by intercept?  Intercept from who?

>
> BTW, I never understood the following two comments in gtkutil.c:
>
>    /* Must use GTK routines here, otherwise GTK resets the size hints
>       to its own defaults.  */
>
> and
>
>        /* Don't set hints when maximized or fullscreen.  Apparently KWin
> and
>           Gtk3 don't get along and the frame shrinks (!).
>
> How could that possibly work?

Fine so far.  The hints specify things like resize increments which are 
the character size, i.e. you can only resize one full row at the time 
(at least when that comment was made).  If you have a fullscreen frame, 
and the font changes, in principle the hints should change.  But a 
change leads to a war between KWin and Gtk+ regarding who shall control 
the size of the frame.  So we don't change hints, we leave the old in place.

Gtk+ has its own copy of hints, which it sets by itself from time to 
time, and which it tries to enforce.  If we where to set hints with X 
functions, Gtk+ would try to enforce something it has, while the window 
manager would enforce what we actually set.  So we use Gtk+ routines sp 
that Gtk+ and the window manager have the same hints.

These to comments are not really related to each other.

> According to the first comment when we
> "don't set hints when maximized or fullscreen" we get "otherwise GTK
> resets the size hints to its own defaults".

I.e. make sure the window manager and Gtk+ have the same hints, but 
don't change them when fullscreen because Gtk+ and KWin implements 
enforcements of hints differently.  Gtk+ and the window manager still 
has our last non-fullscreen hints.

	Jan D.







  reply	other threads:[~2015-03-05 16:36 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. [this message]
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
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

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

  git send-email \
    --in-reply-to=54F885F7.80803@swipnet.se \
    --to=jan.h.d@swipnet.se \
    --cc=19990@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    --cc=yuri.delia@eurac.edu \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.