unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu <luangruo@yahoo.com>
To: martin rudalics <rudalics@gmx.at>
Cc: emacs-devel@gnu.org
Subject: Re: master 30dbdecd4a: * src/xterm.c: Add a small writeup on input handling on X.
Date: Sat, 15 Jan 2022 18:10:45 +0800	[thread overview]
Message-ID: <87sftpb97e.fsf@yahoo.com> (raw)
In-Reply-To: <658c420a-ed76-8a3d-aaf3-9ee2c0dc8f56@gmx.at> (martin rudalics's message of "Sat, 15 Jan 2022 10:31:17 +0100")

martin rudalics <rudalics@gmx.at> writes:

> I can do that but note that most of the frame resizing code is shared
> among X and other backends - in particular, the necessity to call
> change_frame_size, set delayed_size_change there, call adjust_frame_size
> eventually ...

I think xterm.c is still the right place to put that information, since
xterm is essentially the reference implementation for an Emacs window
system.

> Can you see any necessity to call widget_update_wm_size_hints here?

Yes.  Xt has its own idea about size hints, and bad things will happen
if Xt doesn't know about them.

Ideally, we would actually just set the size hints on the EmacsShell
widget (that is the WMShell, since EmacsShell extends ApplicationShell,
which subclasses WMShell), and rely on Xt to do the heavy lifting.  I
will give that a look soon enough.

> The second question is with XSetWMSizeHints in emacsgtkfixed.c: _My_
> version of its starts as
>
> /* Override the X function so we can intercept Gtk+ 3 calls.
>    Use our values for min_width/height so that KDE don't freak out
>    (Bug#8919), and so users can resize our frames as they wish.
>
>    2021 REMIX: But do override only if x_gtk_override_size_hints is true
>    (the default).  If x_gtk_override_size_hints is false, proceed with
>    the original specification so shrinking frames with a specified
>    minimum size works as intended (Bug#46963) and Emacs is always
>    informed of the real sizes the WM reserves for its windows.
>
>    We really should default x_gtk_override_size_hints to nil by default,
>    but this can be done only after sufficient experience has been
>    gathered, in particular on KDE.  Ideally, the code below will be
>    dropped, the sooner the better.  */
>
> void
> XSetWMSizeHints (Display *d, Window w, XSizeHints *hints, Atom prop)
> {
>   struct x_display_info *dpyinfo = x_display_info_for_display (d);
>   struct frame *f = x_top_window_to_frame (dpyinfo, w);
>   long data[18];
>
>   data[0] = hints->flags;
>   ...
>   data[17] = hints->win_gravity;
>
>   if (x_gtk_override_size_hints && hints->flags & PMinSize && f)
>     {
> #ifdef HAVE_PGTK
>       int w = f->output_data.pgtk->size_hints.min_width;
>       int h = f->output_data.pgtk->size_hints.min_height;
> #else
>       int w = f->output_data.x->size_hints.min_width;
>       int h = f->output_data.x->size_hints.min_height;
> #endif
>       data[5] = w;
>       data[6] = h;
>     }
>
> Do you think we could eventually drop that overriding code invented by
> Jan back then?

Yes, I think we could (and should).  But I would introduce that option
first, ask most of the the people tracking master to set it to nil, and
if it seems okay after a year or two to then delete the code entirely.

> BTW one of these
>
> #ifndef HAVE_PGTK
> #ifdef HAVE_PGTK
> #else
> #endif
> #endif
>
> in that code should be eliminated - but I don't know which.

#ifdef HAVE_PGTK
      int w = f->output_data.pgtk->size_hints.min_width;
      int h = f->output_data.pgtk->size_hints.min_height;
#else
      int w = f->output_data.x->size_hints.min_width;
      int h = f->output_data.x->size_hints.min_height;
#endif

Should be replaced by the contents of the !HAVE_PGTK branch, since no X
function is overridden on PGTK.

Thanks.



  reply	other threads:[~2022-01-15 10:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <164216105411.7395.2418079616938679655@vcs2.savannah.gnu.org>
     [not found] ` <20220114115054.720EBC0DA2E@vcs2.savannah.gnu.org>
2022-01-14 11:57   ` master 30dbdecd4a: * src/xterm.c: Add a small writeup on input handling on X Po Lu
2022-01-15  9:31     ` martin rudalics
2022-01-15 10:10       ` Po Lu [this message]
2022-02-28 15:40     ` martin rudalics
2022-02-28 15:50       ` martin rudalics
2022-03-01  0:40         ` Po Lu
2022-03-01  0:43       ` Po Lu

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=87sftpb97e.fsf@yahoo.com \
    --to=luangruo@yahoo.com \
    --cc=emacs-devel@gnu.org \
    --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).