mpsq / arewewaylandyet Goto Github PK

IME, Input Method Editor is used for asian to enter text.

There are a few IME but I think fcitx5 supports it but there are still issues. I think ibus and fcitx does not support wayland yet.

From what I recall, freedesktop have input proposal unstable input method protocol v1 but I don't think anyone is using that.

Sway have their own input method protocol v2 which is not in freedesktop but I think that is what others implements.

I haven't been keeping up with this but I don't think wayland is usable yet for anyone that needs IME.

This might seem a little superfluous with GNOME fully supporting wayland, but Geary is no Thunderbird replacement. In my opinion, one or both of the items in the title would be a good thing to research and add to the list.

you forgot some tilling window managers (i.e sway)

https://github.com/hcsubser/hybridbar

Instead of showing application replacements, it would be more meaningful to compare the state of "possible functionalities" offered by the Wayland protocols and those offered by X11 + EWMH https://en.wikipedia.org/wiki/Extended_Window_Manager_Hints.

Many complaints about "Wayland cannot do X" are instead complaints about "there is no Wayland protocol to do X" or "Not all compositors implement protocol X".

EWMHs are the X11 equivalent of Wayland's protocols. You can focus a window via xdotool in X11 only thanks to EWMH. If you cannot programmatically focus a certain window with ydotool is not because the code is missing in ydotool, but because there is no protocol that composers can use to expose that functionality.

Comparing existing Wayland protocols (and support in major compositors) with EWMH would reveal which functionalities are still needed to achieve functional parity.

Since https://github.com/cyclopsian/wdisplays repo has gone (available at the internet archive), people were looking for a new upstream repo to follow.
https://arewewaylandyet.com/ redirects to https://github.com/luispabon/wdisplays
However, https://aur.archlinux.org/packages/wdisplays-git/ relies on https://github.com/artizirk/wdisplays

Luispabon added the following text to README.md

Luis' Note

Looks like the original repository has disappeared, so since GPL v3 allows I've created a fork of it. Not sure I want to maintain it but for now it won't hurt to have it here.

On the other hand, artizirk merged two patches (artizirk/wdisplays@5198a9c and artizirk/wdisplays@cfc8339) as mentioned in the package's comment section on AUR

arti commented on 2021-03-29 08:39

Looks like upstream repo is gone. I pushed the latest commits with emersion patch here https://github.com/artizirk/wdisplays

How should we proceed?

imv does not have proper downsampling/antialiasing for zoomed out images.

to my surprise nomacs works on wayland natively.

That is quite obvious to people who, know but not obvious to people that don't know.

evince works under wayland.

Also atril - a MATE fork of GNOME 2 evince, should now work under wayland - mate-desktop/atril#504 , the version 1.24 doesn't work, but but 1.26 should have this fixed.

https://github.com/Rafostar/clapper

Not only it works on Wayland - it works better :)

Let's be honest, this favicon I hacked together is... bad! If anyone has something better or decent designing skills, I would be very happy to integrate that instead!

If I don't get a contribution on this, I might try to do a v2 myself, it probably won't be that great either though!

Most applications using either of these toolkits will have a similar quality of Wayland support. A thing to note here is that the quality might depend on the used compositor: QT applications don't have window decorations on Gnome Wayland for me. And it is fair to assume that there are similar issues in the other direction (someone with KDE please test and report).

I wouldn't consider that soon. Also there are more than 20 blocking bugs for working Wayland support. Additionally, we won't know when the much more popular Google Chrome will get native Wayland support.
The linked Phoronix article states that "They hope that in the second half of 2021 that Ozone will be the default on Linux". That is not very reliable and it might take even more time.

https://github.com/oknozor/onagre

Interception Tools is an xmodmap and xcape alternative (that works better IMO). Specifically, the "dual function keys" official plugin is great.

I think this shouldn't be considered working with Wayland. At least not without an addtional notice.
The upcoming version 4 will be working natively.
For reference: flathub/org.videolan.VLC#102

With wayland support now fully merged, it's not needed to install a plugin anymore

I use terminator under X11/Mate for years, and I just tried it under wayland, and it works, no extra options required.

https://terminator-gtk3.readthedocs.io/en/latest/

https://github.com/gnome-terminator/terminator

I used version 2.1.0 from Debian testing running under weston, but probably it works is a bit earlier versions.

You might add a list of linux distros that ships wayland by defaults (i.e Ubuntu 21.04, fedora, Manjaro sway, opensuse GNOME)

I'll attempt a PR...

engrampa - https://github.com/mate-desktop/engrampa , http://www.mate-desktop.org/

supports Wayland. Tested version 1.24.1 from Debian testing.

Currently obs-studio does not provide wayland capture without the wlrobs plugin. This should be mentioned instead of just stating OBS.

One of the two largest discrete GPU vendors does not support GBM and EGLStreams has poor or no support on most compositors. Given that Nvidia users form the majority of the gaming and machine learning userbase, this should get a mention.

Maybe this deserves turning Chromium into it's own subsection in the Nvidia style, though I think explicitly mentioning Electron based apps wouldn't be a bad idea (despite Electron's bad press it gets), as many apps people care about run on the platform, ie. Spotify, Discord, VSCode, Slack, Etcher, etc.

As mentioned in this issue the electron team is expecting compatibility once Chromium is enabled. I know this should be obvious for a lot of people, though full transparency and lack of assumptions are probably smart here, as the idea is to get people excited and confident about Wayland's viability over X. A large portion of the most popular packages in the AUR are Electron based, so the popularity is there.

Qutebrowser runs very well under Wayland. When launched, it defaults to X.org, but when called with QT_QPA_PLATFORM=wayland launchers and runs perfectly.

https://reddit.com/r/archlinux/comments/jm8743/are_we_wayland_yet/gatuol7?context=3

The goal will be to explain what is the purpose of arewewaylandyet.

Great resource, thanks! However, when I tried to run color pickers on KDE's KWin running Wayland:

• grim fails on start on KDE's KWin running Wayland with compositor doesn't support wlr-screencopy-unstable-v1
• I'm pretty sure azote won't work
• Gnome's Color Picker (gcolor3), which isn't in the list yet, starts but its eyedropper can't select from other windows

As I understand it, there isn't a Wayland protocol yet for color picking, so these are going to be specific to particular compositors. I'm not sure how you could highlight this. The big compositors are Gnome, KDE, Sway, but there are others based on weston and wl-roots.

Maybe I was unlucky and other categories of apps generally work on the different compositors, in which case you could only change this one section to something like

• Color picker: Azote (Sway compositor only), Color Picker/gcolor3 (Gnome desktop only), grim (Sway compositor only)

I think some screenshot tools will also be specific to a compositor. Flameshot claims "Experimentally Gnome Wayland and Plasma Wayland support" but I couldn't get it to work under KWin. So the page should have a disclaimer "Some programs only work with particular Wayland compositors".

If this is more general you might need a more elaborate solution, e.g. switch to a table with columns for each compositor with ✔✘ ?; or badges after each program for each compositor under which it works.

maybe mention some hidpi issues?

I'd say 'hidpi is supported, but you might run into issues regarding mouse size scaling', or whatever other issues people frequently run into.

Well, inkscape 1.0.2 from Debian testing works.

Also, I think that is quite important - gimp doesn't work, and people should know about it.

https://reddit.com/r/archlinux/comments/jm8743/are_we_wayland_yet/gaumn9v?context=3

Nyxt supports wayland in a native way using pure gtk+ or qt.

Developer's page

AFAIK network transparency means no need for a particular protocol for networking. Wayland is not network transparent like every sane and modern protocol/software.

I would replace "network transparency" with "networking" or "network protocol".

foot is a very good terminal that is like Alacritty in minimalism, is fast or even faster than Alacritty in some cases, and offers nice features like sixel graphics support and daemon mode, it targets Wayland primarily (I don't even know if it runs on X11)

https://codeberg.org/dnkl/foot

There's a guy who made a few programs:
https://github.com/nwg-piotr/autotiling
https://github.com/nwg-piotr/nwg-launchers
https://github.com/nwg-piotr/nwg-panel
https://github.com/nwg-piotr/nwg-dock

Use https://community.kde.org/Plasma/Wayland/Nvidia instead

ulauncher supports wayland natively, more of an alfred-style launcher than the others.

FreeRDP supports Wayland (wlfreerdp).

Since it uses gtk3, it's 100% compatible. I use it and I can confirm that global hotkeys do not work in the Tilix window, and nor do xeyes, so it's definitely running on wayland.

https://github.com/gnunn1/tilix

Under X11 I usually use xdotool or xdo.

Under wayland it looks there is ydotool ( https://github.com/ReimuNotMoe/ydotool ) and wtype ( https://github.com/atx/wtype ) that provides some similarity and functionality.

However, I didn't actually have any success with ydotool or wtype under weston, they throw exception or complain about backend or about virtual keyboard protocol missing).

As far as I know, there is still no proper color management on Wayland.

Source: https://discuss.pixls.us/t/wayland-color-management/10804/447

I'd love to provide a PR, but I don't know where the "not supported" features should go on the Web page.

P.S.: I found this website on Reddit, and I think it's a good idea. Thanks for bringing this up :)

List of display managers that currently work on wayland:

• https://sr.ht/~kennylevinsen/greetd/
• https://wiki.gnome.org/Projects/GDM
• https://github.com/max-moser/lightdm-elephant-greeter

SDDM almost has wayland support : sddm/sddm#440

https://github.com/realh/roxterm

I totally understand if this change is rejected but the pedantic in me wanted to bring it up. Tiling Window Manager should arguably be changed to Tiling Compositor.

It would be nice to add a list of vnc or remote display possibilities. It comes up often on discussion sites like:
https://lobste.rs/s/pmqmzs/are_we_wayland_yet#c_fjzugv

At least waypipe: https://gitlab.freedesktop.org/mstoeckl/waypipe/-/blob/master/README.md

Arch's wiki has a few: https://wiki.archlinux.org/index.php/wayland#Remote_display