[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging the pgtk branch
From: |
Yuuki Harano |
Subject: |
Re: Merging the pgtk branch |
Date: |
Tue, 03 Aug 2021 21:52:45 +0900 (JST) |
On Mon, 02 Aug 2021 14:49:37 +0300,
Eli Zaretskii <eliz@gnu.org> wrote:
>> >> -install: all install-arch-indep install-etcdoc install-arch-dep
>> >> install-$(NTDIR) blessmail install-eln
>> >> +install: all install-arch-indep install-etcdoc install-arch-dep
>> >> install-$(NTDIR) blessmail install-eln install-gsettings-schemas
>> >> @true
>> >
>> > Does this mean gsettings-schemas will be installed by non-PGTK builds
>> > as well? If not, where are the conditions to prevent that?
>>
>> Yes, it is installed if gsettings is enabled, even if non-PGTK builds.
>
> Is that useful without the PGTK build? What is that used for?
No, it is not useful for non-PGTK build.
X build supports X defaults. But GTK doesn't support it.
Instead, I implemented this hook with gsettings:
terminal->get_string_resource_hook = pgtk_get_string_resource;
gsettings supports type. Type of each key is written in the schema file
etc/org.gnu.emacs.defaults.gschema.xml.
(I implemented this feature instead of X defaults, so types of all the key
are string.)
However, I'm not sure whether people want Xdefaults-like feature.
Emacs' frame parameters are enough...
>> >> --- a/lisp/server.el
>> >> +++ b/lisp/server.el
>> >> @@ -900,12 +900,17 @@ server-create-window-system-frame
>> >> )
>> >
>> >> (cond (w
>> >> - (server--create-frame
>> >> - nowait proc
>> >> - `((display . ,display)
>> >> - ,@(if parent-id
>> >> - `((parent-id . ,(string-to-number parent-id))))
>> >> - ,@parameters)))
>> >> + (condition-case nil
>> >> + (server--create-frame
>> >> + nowait proc
>> >> + `((display . ,display)
>> >> + ,@(if parent-id
>> >> + `((parent-id . ,(string-to-number parent-id))))
>> >> + ,@parameters))
>> >> + (error
>> >> + (server-log "Window system unsupported" proc)
>> >> + (server-send-string proc "-window-system-unsupported \n")
>> >> + nil)))
>> >
>> > Why is this change needed?
>>
>> emacsclient tries WAYLAND_DISPLAY, and DISPLAY if the first try is failed.
>> The code catches the display connection failure, and returns the failure
>> to emacsclient.
>
> Hmm... what about window-systems that have neither WAYLAND_DISPLAY nor
> DISPLAY? will this always fail? I feel that I'm missing something
> here: why wasn't this needed before?
Sorry, I mistook.
GTK supports GDK_BACKEND environment variable.
If GDK_BACKEND=wayland, GTK tries only wayland connection.
If GDK_BACKEND=x11, GTK tries only X connection.
If GDK_BACKEND=wayland,x11, GTK tries wayland connection, and X
connection if the first try failed.
If GDK_BACKEND=x11 and DISPLAY is not set, then emacs fails to start.
----
luna:objs % unset DISPLAY
luna:objs % GDK_BACKEND=x11 ./src/emacs
(emacs:322982): Gtk-WARNING **: 00:31:26.986: cannot open display:
luna:objs %
----
If GDK_BACKEND=x11 and DISPLAY=:0, then emacs starts.
However, `emacsclient -c` first tries with WAYLAND_DISPLAY and
it fails, because GDK_BACKEND=x11 and emacs itself does not open
wayland connection.
The error is:
----
-error Cannot&_connect&_to&_display&_server&_wayland&-1
----
(In case of WAYLAND_DISPLAY=wayland-1.)
And emacsclient does not retry.
I wanted to work around this error.
I send -window-system-unsupported by that change.
In this case, emacsclient retry with alt_display, which is
DISPLAY by another change.
> what about window-systems that have neither WAYLAND_DISPLAY nor
> DISPLAY? will this always fail?
emacsclient.c:
----
#if defined (NS_IMPL_COCOA)
alt_display = "ns";
#elif defined (HAVE_NTGUI)
alt_display = "w32";
#endif
----
if (!display)
{
display = alt_display;
alt_display = NULL;
}
----
On ns and w32, display is set.
To make sure whether that change works on ns and w32,
it is needed to test on such machines.
I didn't test on such machines.
--
Yuuki Harano
Font size (was: Merging the pgtk branch), Kévin Le Gouguec, 2021/08/04
- Re: Font size (was: Merging the pgtk branch), Eli Zaretskii, 2021/08/04
- Re: Font size, Kévin Le Gouguec, 2021/08/04
- Re: Font size, Yuri Khan, 2021/08/04
- Re: Font size, Eli Zaretskii, 2021/08/04
- Re: Font size, Yuri Khan, 2021/08/04
- Re: Font size, Eli Zaretskii, 2021/08/04
- Re: Font size, Yuri Khan, 2021/08/04