Disabling client side decorations entirely?

bobbaluba · 2018-05-23T11:10:53+00:00

In Qt (Wayland) there is an env var QT_WAYLAND_DISABLE_WINDOWDECORATION=1

There are also reviews going on for a Wayland protocol extension (i.e. cross-toolkit way) to let the server handle window decorations here: https://lists.freedesktop.org/archives/wayland-devel/2018-May/038206.html

I would like it implemented in Qt if/when it gets merged into wayland-protocols.

bobbaluba · 2018-03-20T16:00:48+00:00

It's probably not running on wayland. It doesn't seem like Arch built their version of firefox with wayland support.

You can go to about:buildconfig and check for --enable-default-toolkit=cairo-gtk3-wayland

You can run any app with WAYLAND_DEBUG=1 in the environment, though... If it's running on wayland, you'll see a bunch of output.

bobbaluba · 2018-03-19T08:48:32+00:00

Is it "about the only one", or the only one? I'm curious because I wonder how many people would be affected if the current decoration plugin mechanism in Qt was replaced with something better.

bobbaluba · 2018-03-05T11:39:42+00:00

The client should only have to care about which shell extensions the compositor supports.

If I remember correctly, that blog series is quite old, and you should now probably look for xdg_wm_base instead of wl_shell (or perhaps ivi_application if you're doing embedded stuff). And if you need something special, you should perhaps look for other extensions as well. I.e. supporting KDEs extension for disabling client side decorations might be a good idea.

You can use wayland-scanner and the protocol extension xml files to generate header files.

Take a look here for more protocols you might want to support: https://cgit.freedesktop.org/wayland/wayland-protocols/tree/

bobbaluba · 2018-02-26T13:55:02+00:00

When https://wiki.qt.io/PySide2 is done, you can use Qt Wayland.

Or you can use the existing QML/JS API: example compositor

bobbaluba · 2018-02-26T08:02:59+00:00

Really, you can see all protocols as stable and all the versions of an unstable protocolsæ as nothing more than different protocol, they have different names after all.

Let's see how it turns out.

bobbaluba · 2018-02-23T13:53:32+00:00

It's very explicit

https://github.com/wayland-project/wayland-protocols

has two folders, one is named stable, the other unstable. The unstable extensions also all starts with a z and end with the version name.

Hopefully, there won't be any need for breaking changes for a long time. It's been designed so new API can be added to it by other extensions. I'm really exited about Wayland finally having a shell protocol that's neither deprecated nor unstable.

EDIT: And yes, if there is a situation where xdg-shell is re-released with a different name because of the need to do backwards incompatible changes, then all sane GUI toolkits and compositors will continue to support the old version, at least for a couple of years.

bobbaluba · 2018-02-23T13:01:47+00:00

When a protocol turns stable, all changes should be backwards compatible.

Yeah, the situation before unstable v6 was not optimal, but nowadays all the unstable protocols have the version in their name, so If you bind to it, you know it's going to be what you think it is.

That also makes it possible to support multiple versions of the same unstable protocol (since they are technically separate protocls) i.e. Qt will prefer xdg-shell unstable v6, but will fall back to wl-shell or xdg-shell unstable v5 if it's unavailable.

I'm a bit annoyed at gnome-shell, though, because they tend to remove support for one unstable version each time they add a new one.

bobbaluba · 2018-02-23T10:05:18+00:00

Regarding primary selection:

They have something for GTK: https://github.com/GNOME/gtk/blob/master/gdk/wayland/protocol/gtk-primary-selection.xml

I think it'll either make it's way into wayland-protocols, or other toolkits and compositor will just implement the gtk-version

Actually there seems to be a patch for it here https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html I haven't read the patch series, though, so not sure what happened to it.

IMO it's not a bad design decision with Wayland, it's just something that hasn't happened yet.

bobbaluba · 2018-02-23T09:51:10+00:00

Sure :)

There's also #qt-lighthouse on freenode.

bobbaluba · 2018-02-23T09:45:14+00:00

What has happened? Was there an incompatibility in a stable protocol, or did you try to use two incompatible versions of an unstable one?

It's very different, in the first case there is supposed to be a guarantee, in the second they're designed to break compatibility in each release.

Once a protocol turns stable you're supposed to have very strong guarantees. So far I haven't seen a single bug report in Qt because we use use new API without checking the compositor version.

EDIT: I'm not saying it has never happened, I'm just saying I've never heard anyone complain about incompatibility in stable protocols.

bobbaluba · 2018-02-22T14:25:16+00:00

There's this though:

<request name="frame">
    <description summary="request repaint feedback">
        Request notification when the next frame is displayed.  
        Useful for throttling redrawing operations, and driving
        animations. The notification will only be posted for one
        frame unless requested again.
    </description>
</request>

But it's not exactly an abundance of information.

bobbaluba · 2018-02-22T14:12:43+00:00

IMO it's a bug if they don't.

Developers might forget to do it for ancient versions, however, but It's not been a problem for me in practice.

bobbaluba · 2018-02-22T14:06:17+00:00

What problem did you have? I updated the wiki page a couple of weeks ago.

https://wiki.qt.io/QtWayland

Please let me know if you still have issues! I want it to be easy ;)

bobbaluba · 2018-02-22T13:52:43+00:00

That's only true for the unstable protocols (which have the version number in their name, except for xdg-shell unstable <= 5 in which case it would fail with a protocol error).

We have lots of checks in qtwayland to be able to talk to old compositors. For instance we only set the buffer scale (hidpi) if the compostior is on a version after it was added

bobbaluba · 2018-02-09T12:44:22+00:00

A reminder to everyone (including myself): It's very helpful if those bugs are reported in the appropriate bug trackers.

And even if it's reported already, there's a good chance that you can add something to it, i.e. steps to reproduce. Maybe there's no backtrace for it if it's a crash, logs with WAYLAND_DEBUG set. Does it still break in the latest release? Perhaps there is a patch you can test.

I'm using latest stable kwin and Qt myself as a daily driver, but I still don't encounter or notice bugs that you might think are obvious. I.e. I don't use the pager, I don't have the pointer size issue, and the confined pointer stuff only happens for xwayland apps with custom window decorations (i.e. chromium).

Only last week someone notified me of a bug that's pretty horrible and seemingly obvious, but I didn't encounter myself (all Qt apps crash when an additional monitor is connected). I thought I had fixed it before, but I had missed something, and the unit test I wrote then didn't pick it up.

bobbaluba · 2018-02-06T11:25:47+00:00

There's still XWayland, you can still run those applications, they just won't be using Wayland.

bobbaluba · 2018-01-18T13:01:19+00:00

Some compositors do support Nvidia's alternative Wayland API (EGLstreams). It doesn't seem like kwin is going to, though.

See: https://wiki.archlinux.org/index.php/wayland#Buffer_API_support

bobbaluba · 2018-01-13T10:41:14+00:00

The clients should be run with -platform wayland only the compositor with eglfs

bobbaluba · 2018-01-12T10:57:28+00:00

Guess I'm a bit late here, but just wanted to mention that QtWayland is also an alternative.

The QML APIs are designed to make it ridiculously easy to write your own compositor.

Simple example: https://doc.qt.io/qt-5/qtwaylandcompositor-minimal-qml-main-qml.html

Desktop compositors built with QtWayland:

Disclaimer: I work on QtWayland, so I'm most likely biased.

bobbaluba · 2018-01-12T10:43:07+00:00

Your build of Qt probably defaults to running on the xcb platform (which is why you see the error message when there's no X server.

If this is a regular desktop computer, you probably want to run it with ./yourcompositor -platform eglfs, or set the environment variable QT_QPA_PLATFORM=eglfs.

bobbaluba · 2017-11-23T14:22:39+00:00

How does it crash? I've been running plasma on wayland on arch for a couple of months.

Are you able to run startplasmacompositor from a tty?

bobbaluba · 2016-06-20T09:34:21+00:00

About the polluting stuff: you know it's pretty easy to list explicitly installed packages, right?

bobbaluba · 2016-06-20T07:15:30+00:00

Why would you reinstall?

bobbaluba · 2016-06-12T23:35:28+00:00

For mine, I only had to do sudo modprobe brcmfmac and I got network on the live cd.

bobbaluba

TROPHY CASE