Quack Doc

Click baity title aside. This is actually pretty much pretty true. What the vast majority of people want when they’re writing their own composers seems to be specifically the custom window management aspects.

And it is true that even with something like Wlroots or a Smithay, it is a lot of works right your own composer and have it be “competitive”. And he is right. There are a lot of composers out there that are just not usable for anything more than the basics. And there are tons more which are just toys that have been abandoned that aren’t really usable. That being said we saw a lot of that with window managers, But yes, writing a compositor is a lot more then writing a window manager.

I personally don’t use hyperland, but I can see the point he’s trying to make, and I think it’s a rather good point. I think if we had more compositors that focused on having a scriptable window management, then that would be for the better.

I don’t really see this as toxic either. I mean, if it’s toxic to call a composite or trash in one way or another, then I would argue that 90% of the Linux community is far more toxic than he is. It’s just a matter of truth. Wayland is a big complicated thing with a lot of protocols and some of it is poorly documented.

And of course, this is him shilling his own composter. It’s his own composter, and this is the blog about him making his own composter. Of course he’s gonna put a post on it, shilling his own compositor.

That being said, As I said earlier, I would like to see a more scriptable take for things like window management. I don’t think hyprland has to be unique in this aspect, but as it stands, it most definitely is.

pardon my weird language, its hard to use STT.

is another big factor, and probably the one that finally tipped the scales

means that it is not the sole motivating factor.

which means even if they are literally adolf hitler, I shouldn’t care, as long as they don’t post about gassing people on my server

Literally means that if they go around spewing crap, they get dealt with. This is not condoning hateful trolling at all. He is on the free speech side of things, but that doesn’t mean he condones it at all. If you start posting bad crap, you get dealt with. Minor slights, are as the name implies, minor. Those are allowed but within strict limitations, if you start going full blown idiot, you get dealt with.

Wrong. This was originally technically motivated as hyprland had been limited by wlroots in the past and often had different update cycles from sway causing packaging issues.

Vaxry never condoned hateful trolling of trans people. In fact, he publicly acknowledged, and apologized for the lack of moderation that lead to the incident, said he would do better, DID better, and THEN after everything had blown over FDO tried to ego butt into his server even more.

I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.

The idea of a using a separate thing for it is fine, in itself, but necessitating it is an issue to me. There are a LOT of wayland compositors now, for all sorts of systems, each one also new needs a compatible xdg portals implementation (or whatever third party tool you like), in the case of xdg portals this also means pulling in things like dbus. It actually becomes a lot to build a “Minimal but fledged out” ecosystem. something which should otherwise be possible.

we’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?

sure but then you have xdg-portals denying actually useful a11y protocols because they “don’t want to expose it to containers” -_- apparently they never heard of a permissions system? but this also highlights why the wayland ecosystem right now is so poor for select individuals (and why they get heated when told that they need to swap to wayland)

I have a couple of issues with portals. One is that we’re putting too much eggs in the basket of something that is designed for containers. XDG portals Have rejected features that people have requested because they don’t want to expose that functionality to a container and they are allergic to permission prompts apparently.

I also have other issues with the portals for instance video capture. It requires you to have a camera portal. It requires you to have a desktop capture portal. It also requires you to have an app to app, video, portal, which doesn’t exist yet. All of these things require pipewire pretty much in most cases, so why can’t we just have a single pipewire portal? It may not scale well in the future, but it doesn’t scale well now anyways. If you want just a generic pipe wire stream, you’re not gonna be able to have it, you’re going to have to conform to one of the standards anyways. For a case in point example, the OBS pull request for Game Scope Capture is the perfect example of this over reliance in XDG portals.

I’m showcasing this just to highlight the fact that the XDG portals are incredibly poorly thought out, and I don’t think that it’s a reliable method for the future going forwards.

PS. Please pardon any oddities in this, I had to use speech to text, since my RSI is acting up.

I did and quite frankly it’s trash, XDG portals are a clunky and quite frankly terrible and poorly thought out api. I’m not the only one that disagrees with this sentiment as multiple people are trying to get protocols like ext-screencopy-v1 for screen recording and ext-foreign-toplevel-* for window management upstreamed into wayland so that xdg portals aren’t necessary for these use cases. I don’t mind the reliance on pipewire too much, but I too think that It shouldn’t be necessary for screen capture.

IMO It is one of nate’s worst takes of all time if not the worst. Usually I agree with most things he writes, but not this, xdg-portals is a travesty, pipewire is nice and all, but I don’t see why we should need an entire media system for basic screen capture capabilities. and clearly im not alone on this sentiment

woops my bad, I mean to link this https://github.com/probonopd/wayland-x11-compat-protocols it’s a repo of going to be protocols, to fill in the gap instead of pretending the issue doesn’t exist

Really glad probonopd is doing this, X11 is dying but wayland isnt ready to replace it, so it’s nice to have this

EDIT, paste didn’t work https://github.com/probonopd/wayland-x11-compat-protocols

I use mpvpaper on sway and cosmic

not to mention the totally bogus comparison they preformed which is an insult to anyone who has a even an inkling into how image metrics and comparisons work and more then 30sec to compare

Google has been trying to clamp down on people daring to run software they don’t approve on their devices.

“Google” isn’t. ChromeOS is actually providing more and more flexibility then ever. Android however is the exact opposite. One must keep in mind that google isn’t some monolithic company, it’s very fractured and has many independent teams, the best showcase of this is JXL. 3/4 top contributors to libjxl are google employees, and yet chromium decided to remove JXL support citing bogus reasons generated by obviously flawed testing and analysis.

crostini is pretty damn great but it’s important to know what it IS and it’s actually really simple. Crostini is two things combined into one

Firstly A VMM

Crostini uses the crosvm VMM which is can be thought of kinda like an inhouse version of qemu but designed to explicitly run natively integrated and high performance VMs safely instead of being a swiss army knife (KVM acceleration, virtio peripherals etc) (PS. it’s written in rust too) They use it for chromeOS to integrate android support (on select newer devices) and linux. It runs a supervisor distro which can run containers inside of it.

ChromeOS calls the VM termina. Im not sure what distro is running in the VM, or if its a specialized one. I forget

Next is the containerization

It is a lot like distrobox, It can run a myriad of distros but the key part of it is sommelier. A wayland compositor designed to render windows through virtio-wayland, an extension of virtio-gpu. In practice very similar waypipe which rendering wayland windows to a remote wayland client using network/sockets (Yes, it does support AV_VSOCK so it can work with qemu.)

Sommelier is run in the containerized Distro, running on the TerminaVM. Using termina provides excelent security and performance, and then using LXD inside of termina provides excellent flexibility

The guts of “crostini” crosvm, virtio-wayland, sommelieris all open source, you can actually (with some degree of hassle) set this up entirely yourself, or do what I do, and run qemu + waypipe for a similar experience. Waypipe is much easier to setup however it comes at a preformance detriment since qemu virtio-gpu perf is worse then crosvm (no vulkan support in qemu yet still)

EDIT: s/Architecturally/in practice/ I have no idea why I said Architecturally. they are quite different things. I must have had a brain fart

I just get any windows tablet that has good linux support and throw bliss on it, Linux tablet situation is bad right now

I am aware of that, but even with it there’s still a decent amount of waste.

I fell for the lie of flatpak not being bloated, I just nuked flatpak from my PC since I just run arch anyways. Im not sure if repo is safe to remove. You might be able to run rmlint -g and see how much data can be deduplicated on an FS level, I never checked myself since I run f2fs, but if you run an FS with dedupe capabilities it may work for you.

For sure try out olive You can’t do automatic stabilization but manual works fine, However I will always use gyroflow whenever possible anyways. If needed you can easily script motion tracking data from 3rd party sources.

but it is properly color managed throughout the entire editor so doing color correction works properly and accurately. the node system is really powerful despite it’s early nature, and as far as I know olive is the only FOSS editor with proper OCIO integration, which means you get industry standard color management tooling including things like ACES support. You also have OTIO support for importing and exporting editorial cutting information.

i’ve been using sonobus lately and it’s been pretty good, I had latency issues when I tested the android app a long time ago, ill have to test it again

You could probably look into something like paperwm or Niri, I think scrollable window managers have a lot of potential to be a novel but good touch experience

EDIT: Im not sure if niri support touch, I havent tested it, but I think i might actually try it myself when I get the chance now

I am, very hesitantly, optimistic for the new smithay based compositors. Cosmic doesn’t have touch support yet, but it’s super light weight, I get better perf then I do even with KDE. I plan on swapping to it full time on my tablet when it gets touch support. (and when some touch friendly gui stuff is available). you also have catacomb which is an actual mobile compositor. Very promising stuff, but still very far out

I find that even if you get a touch primary device, make sure to get one with a keyboard, Ubuntu, Fedora, doesn’t matter, KDE, Gnome doesn’t matter, the touch only experience on linux is simply not great. Make extra sure to get the keyboard with it if its optional.