akirakyle / emacs-webkit

An Emacs Dynamic Module for WebKit, aka a fully fledged browser inside emacs
GNU General Public License v3.0
425 stars 25 forks source link

EAF has support wayland #10

Closed manateelazycat closed 4 years ago

manateelazycat commented 4 years ago

EAF has support wayland,I think doc need adjust

akirakyle commented 4 years ago

Native wayland support or through xwayland?

manateelazycat commented 4 years ago

Native wayland support or through xwayland?

native support

manateelazycat commented 4 years ago

Native wayland support or through xwayland?

check https://github.com/manateelazycat/emacs-application-framework/commit/86de461465fd487d1a213db538e965399583831c

akirakyle commented 4 years ago

It looks like EAF forces qt to use the xcb backend on wayland displays: https://github.com/manateelazycat/emacs-application-framework/blob/df9da7b600ff21c69c2e6c7af66ddb94573207c6/eaf.el#L1143-L1144

Then QWindow::setParent arranges the XEmbed connection under the hood using xcb: https://github.com/qt/qtbase/blob/7ee682a1ddc259225618b57ff00f4c36ff5e724c/src/plugins/platforms/xcb/qxcbwindow.cpp#L1239-L1253

So unless I'm misunderstanding something here, I think my point still stands that EAF doesn't work on wayland. Given what I've learned about wayland compositors when I toyed with creating a wlroots based exwm replacement, I'm not sure I see a clean way for EAF to work with wayland since it will have to rely on the compositor behaving well but that may be difficult given the differing behaviors across mutter, kwin, and wlroots based compositors. Of course its hard to know anything concrete without trying, so I'd be happy to be proven wrong!

manateelazycat commented 4 years ago

It looks like EAF forces qt to use the xcb backend on wayland displays: https://github.com/manateelazycat/emacs-application-framework/blob/df9da7b600ff21c69c2e6c7af66ddb94573207c6/eaf.el#L1143-L1144

Then QWindow::setParent arranges the XEmbed connection under the hood using xcb: https://github.com/qt/qtbase/blob/7ee682a1ddc259225618b57ff00f4c36ff5e724c/src/plugins/platforms/xcb/qxcbwindow.cpp#L1239-L1253

So unless I'm misunderstanding something here, I think my point still stands that EAF doesn't work on wayland. Given what I've learned about wayland compositors when I toyed with creating a wlroots based exwm replacement, I'm not sure I see a clean way for EAF to work with wayland since it will have to rely on the compositor behaving well but that may be difficult given the differing behaviors across mutter, kwin, and wlroots based compositors. Of course its hard to know anything concrete without trying, so I'd be happy to be proven wrong!

EAF can works well on Wayland, we have test it, have you try it?

akirakyle commented 4 years ago

Sorry I should have been more specific. Yes I've tried and found it works fine on wayland with the usual --with-x but that means emacs itself is running under xwayland and hence eaf also is running under xwayland. To run emacs natively on wayland you need to compile emacs using the experimental --with-pgtk. I tested eaf using that and it does not work, giving the error message

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.screen: QXcbConnection: Could not connect to display wayland-0
Could not connect to any X display.
manateelazycat commented 4 years ago

If you don't like Qt or Python, I understand. ;)

I mean that the document should show that EAF can work in Wayland, avoid misunderstanding that EAF can not work under Wayland, regardless of what technology it uses.

bqv commented 4 years ago

@manateelazycat I think you've misunderstood - EAF does not and can not work on wayland without XWayland. While that means it can be used on most wayland compositors, it does not make it wayland native, and on any compositor that doesn't allow XWayland (quite possible!) EAF will fail to work.

akirakyle commented 4 years ago

I think "can not work on wayland" is perhaps a bit too strong. It may be possible for it to work and my guess is that it would have to be by using the wayland popup window protocol as that's all I could find with respect to wayland offering the concept of a parent window. Perhaps Qt might implement something like that behind the scenes for its QWindow::setParent call on the wayland qpa platform but when I dug around there I couldn't find anything resembling that capability, although I didn't look too hard. If Qt did this EAF would work for free on pgtk emacs, but as I mentioned before I think this may still be pretty difficult since unlike xorg where you can rely on XEMBED functioning the same across window managers and compositors, it's up to each compositor to define its own implementation that may comply with the xdg spec to varying degrees or with varying quirks.

It's at least pretty clear to me that EAF does not currently run natively on wayland. That's perfectly fine since xwayland won't be going anywhere for awhile, but it does mean it won't be able to take advantage of the improvements in pgtk emacs.

manateelazycat commented 4 years ago

I think "can not work on wayland" is perhaps a bit too strong. It may be possible for it to work and my guess is that it would have to be by using the wayland popup window protocol as that's all I could find with respect to wayland offering the concept of a parent window. Perhaps Qt might implement something like that behind the scenes for its QWindow::setParent call on the wayland qpa platform but when I dug around there I couldn't find anything resembling that capability, although I didn't look too hard. If Qt did this EAF would work for free on pgtk emacs, but as I mentioned before I think this may still be pretty difficult since unlike xorg where you can rely on XEMBED functioning the same across window managers and compositors, it's up to each compositor to define its own implementation that may comply with the xdg spec to varying degrees or with varying quirks.

It's at least pretty clear to me that EAF does not currently run natively on wayland. That's perfectly fine since xwayland won't be going anywhere for awhile, but it does mean it won't be able to take advantage of the improvements in pgtk emacs.

EAF use Qt's QWindow::setParent instead XLib reparent function. I believe Qt has adapt Wayland and X11, at least in README document should say EAF depend on Qt's implement and not depend on XEmbed protocol directly, because EAF current version not use any XLib/XCB code.

akirakyle commented 4 years ago

See my first comment where I link to the implementation of QWindow::setParent on the xcb qpa backend which you force Qt to use in eaf. Qt arranges the xlib reparent for you when you call setParent which ultimately relies on the xembed protocol. I guess while I'm at it, I'll go ahead and let qt use the wayland backend for eaf and see how it behaves then report back here.

MatthewZMD commented 4 years ago

EAF use Qt's QWindow::setParent instead XLib reparent function.

@manateelazycat ,@akirakyle 想表达QWindow::setParent源码用了xcb,并且EAF也通过(unless (equal (getenv "WAYLAND_DISPLAY") "") (setenv "QT_QPA_PLATFORM" "xcb"))来确保qt5用的是xcb。这代表Wayland里EAF是通过XWayland这个backward compatible的方式将x11与wayland强行连接起来了,也就是说如果使用纯native wayland(--with-pgtk),EAF还是不能运行。

There're probably some confusion in the conversation, hopefully this clears them out.

manateelazycat commented 4 years ago

EAF use Qt's QWindow::setParent instead XLib reparent function.

@manateelazycat ,@akirakyle 想表达QWindow::setParent源码用了xcb,并且EAF也通过(unless (equal (getenv "WAYLAND_DISPLAY") "") (setenv "QT_QPA_PLATFORM" "xcb"))来确保qt5用的是xcb。这代表Wayland里EAF是通过XWayland这个backward compatible的方式将x11与wayland强行连接起来了,也就是说如果使用纯native wayland(--with-pgtk),EAF还是不能运行。

There're probably some confusion in the conversation, hopefully this clears them out.

我知道,(setenv "QT_QPA_PLATFORM" "xcb") 这个是后面加上的补丁,加之前也是可以在Wayland下运行的。

MatthewZMD commented 4 years ago

加之前也是可以在Wayland下运行的

对,但是是通过xwayland运行的(因为QWindow::setParent技术底层用了xcb)。xwayland让x11程序能在wayland成功运行,而 @akirakyle 的意思是这不是native wayland,所以pgtk emacs就有问题。

现在我们要不想办法绕过QWindow::setParent支持native wayland,要不等待Qt团队更新这个api。

manateelazycat commented 4 years ago

加之前也是可以在Wayland下运行的

对,但是是通过xwayland运行的(因为QWindow::setParent技术底层用了xcb)。xwayland让x11程序能在wayland成功运行,而 @akirakyle 的意思是这不是native wayland,所以pgtk emacs就有问题。

现在我们要不想办法绕过QWindow::setParent支持native wayland,要不等待Qt团队更新这个api。

其实可以在Wayland下用Native的方法,其他平台用QWindow::setParent.

MatthewZMD commented 4 years ago

其实可以在Wayland下用Native的方法

现在需要寻找一个Native的办法 :)

akirakyle commented 4 years ago

Sorry I can't really follow this conversation effectively as I don't know Chinese (I tried using google translate though). I just tried using emacs --with-pgtk and (setenv "QT_QPA_PLATFORM" "wayland"). As I expected, I get that the EAF widget is created in its own window rather then embedded in an emacs buffer. Perhaps the Qt devs will figure out a way to implement QWindow::setParent on wayland, but as I mentioned before, I don't think this will be easy, or necessarily even possible.

I just realized another issue that EAF would need to overcome to work on wayland, but I can't think of any way it can be solved as it seems to go against wayland's design. EAF currently uses the x11 XID that Emacs reports in the window-id frame-parameter. AFAIK there is no equivalent to an XID on wayland as applications shouldn't really be able to identify and tell the compositor to affect another app's windows (yay security?!). Thus emacs --with-pgtk reports the pointer to the GtkWindow in window-id. I don't think there's anything useful Qt could do with this Gtk pointer. The recent bug I fixed (#12) was all about the different window-id between x and pgtk window-systems, but thankfully I can convert an XID to a GtkWindow pointer on x, but on wayland the reverse isn't possible.

MatthewZMD commented 4 years ago

Sorry I can't really follow this conversation effectively as I don't know Chinese (I tried using google translate though).

No worries, I was just paraphrasing what you were saying to him in Chinese.

I've created a issue manateelazycat/emacs-application-framework#449 dedicated to the continuation discussion of this topic in the EAF repo, as this issue's conversation is becoming more on the specifics of EAF, instead of emacs-webkit itself.

manateelazycat commented 2 years ago

@akirakyle EAF has support Wayland native https://github.com/emacs-eaf/emacs-application-framework/commit/8df41d0058a59affbec19f013b504259305109cc

Don't need XWayland anymore.

manateelazycat commented 2 years ago

pgtk support by https://github.com/emacs-eaf/emacs-application-framework/commit/29a5e56e6e0fdad161bc83064f4f04dbda7d8d59

If you are using Wayland environment, you need update EAF to newest and execute the command cp -r emacs-application-framework/gnome-shell/eaf-wayland@emacs-eaf.org ~/.local/share/gnome-shell/extensions and activate the Gnome-Shell plugin eaf-wayland@emacs-eaf.org in Gnome3

bqv commented 2 years ago

Does this support only Gnome Wayland?