emacs-devel
[Top][All Lists]
Advanced

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

Re: Cleaning out old X11 toolkits?


From: Robert Pluim
Subject: Re: Cleaning out old X11 toolkits?
Date: Sun, 14 Feb 2021 13:50:23 +0100

>>>>> On Fri, 12 Feb 2021 20:32:31 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> Cc: chad <yandros@gmail.com>, Yuan Fu <casouri@gmail.com>,
    >> Alan Third <alan@idiocy.org>, emacs-devel <emacs-devel@gnu.org>,
    >> "Basil L. Contovounesios" <contovob@tcd.ie>,
    >> Stefan Monnier <monnier@iro.umontreal.ca>, Lars Ingebrigtsen
    >> <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>
    >> From: martin rudalics <rudalics@gmx.at>
    >> Date: Fri, 12 Feb 2021 18:56:05 +0100
    >> 
    >> > If thatʼs what we want, then we should merge pgtk to master and ask
    >> > people to test it.
    >> 
    >> Why should people "test" it more when it's been merged?

    Eli> Because presumably building a pgtk port will need some non-default
    Eli> switch to the configure script?  And if no one uses that switch, the
    Eli> merged code will remain unused?

right. And not everyone is going to want to go to the trouble of
switching branches in git or creating a second workspace, so having a
configure options just makes their lives easier. In fact, perhaps it
should be

--with-x-toolkit=pgtk

(even though it works for Wayland as well)

    >> > Works fine for me here with a GTK build, although my frame ends up
    >> > with a height of 30. pgtk generally has issues with frame sizing and
    >> > positioning.
    >> 
    >> We might be in for some rude awakening here.

    Eli> I think those positioning issues need to be fixed before we will agree
    Eli> to merge the branch.

Iʼm not sure what we can do: under Wayland the window manager I have
ignores programmatic requests to change frame positions, and this is
apparently by design.

Hmm, specifying *initial* frame sizes and positions seems to work, but
only if done early enough, such as by setting 'default-frame-alist' in
early-init.el. I guess worst case we can destroy frames and recreate
them instead of moving them. Someone (Martin?) suggested creating an
invisible max-size top-level frame that we could use as the parent for
all other frames on pgtk, since pgtk does allow us to move and resize
child-frames. I donʼt know if thatʼs actually possible.

Robert



reply via email to

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