Same as any other font. Add it to ~/.fonts or /usr/local/fonts. You might also have something like font browser already preinstalled, and usually there’s an Install button
Same as any other font. Add it to ~/.fonts or /usr/local/fonts. You might also have something like font browser already preinstalled, and usually there’s an Install button
Windows on external USB drive, disconnected after each use
No surprises there, just the usual shit
As for Windows plugins with no native Linux version, there are ways to use VSTs over Wine. Check out Yabridge project. There’s no guarantee that 100% of plugins will work, but many do pretty well. It requires some additional setup, but once it’s done, you don’t have to think about it much, just call yabridgectl when you add new plugins to sync them (it creates stub library that is seen as Linux native, but it wraps Windows plugin using Wine)
Reaper is perfectly fine choice if you’re already familiar with it, but here are some other you may want to look at:
FOSS Options:
Commercial options:
Arch btw
Kitty - super simple, configurable and lightweight
The older Lunduke gets, the more he’s convinced about being right on everything, therefore the more rubbish he has to say.
To me it’s hard to say if BlueZ actually has some technical debt and is hard to fix, or is it just lacking some maintenance. Are bluetooth issues actually due to BlueZ, or is it more about finky drivers? My Bluetooth experience on Linux systems is mostly good, but it might vary a tiny bit depending on the hardware.
I’d say, if you see some architectural benefits then try and go for it. To really make sense it should do BlueZ’s job better than BlueZ. Being drop-in replacement is good for desktops integration, but maybe the API could be improved providing some benefits to how desktop integrations work (like provide more status info or prevent some situations from blocking), but again I know nothing about BlueZ internals so just guessing
Eventually it’ll be easier to create a compatible drop-in replacement than maintain the decades old code, if it isn’t already
I like the GNOME 2 vibes. It looks really clean and to me it doesn’t even feel outdated.
deleted by creator
I guess there’s that beginner period when that should be allowed. I kind of wished it happened to me again, instead of daily driving boring Arch systems with no incentive to ever change.
This probably works as intended, even of it’s not the desired behavior. Given that the protocol only allows clients to activate()
the surface that needs attention and never mentions the actual window focus, it is up to the compositor (in this case Kwin) to decide what to do exactly with the request.
On a side note, I think this behavior should be configurable. I for one would not want windows to automatically focus ever (and Plasma even switches the virtual desktops when that happens), but I also see why someone would want to.
I’m not sure about Thunderbird specifically, but it works with any apps (like Kitty terminal or Slack client) on Plasma Wayland session for me. You’ve got no reaction at all, or is the task manager icon at least turning orange for attention?
This used to be a problem few plasma versions back as there wasn’t any standardized protocol for this, and then it got stabilized and implemented https://wayland.app/protocols/xdg-activation-v1
Is your default web browser set properly (check default programs in system settings, you might try and set it to something else then back)? And how about the following:
xdg-open https://kde.org
nobody would say that one year ago far as my memory goes, and it’s reasonable thing to say now. Personally I expected some break-throughs that have happened in 2023 to take much longer.
Nouveau + NVK is the hope 🙏
This is barely explained and the readme gave me more questions than answers.
I immediately thought it’s going to be a library for Wine to use instead of DXVK/VKD3D.
If that’s only for developers to build Linux ports, very little to no real-world use is expected, unless it’s somehow can offer effortless conversions. Even then developers are likely to prefer relying on Proton/Wine to simply have single binary for both platforms, rather than maintaining them separately.
I wonder how much work it will take for drivers to support the API… Or maybe it won’t need anything in Mesa and will somehow work directly on DRM with strictly platform-agnostic code if that’s possible?
Offering better performance than the likes of DXVK is brave to put it mildly. In many scenarios it can already match or surpass native Windows performance even when running Windows binaries.
Desktop Linux is in its never-ending process of replacing old displaying system with new one. The process is long and not really transparent, because the two displaying systems were designed in completely different times for different hardware and with different security concerns in mind, therefore the X11 clients (all the software that was ever made or ported to Linux) are very much incompatible with Wayland. For backwards compatibility there’s Xwayland, which provides full blown Xorg server running on top of Wayland compositor with all the things X11 app requires. Until now, Firefox, even though had its Wayland backend as WIP feature (possible to activate with environment variable MOZ_ENABLE_WAYLAND=1) it defaulted to Xwayland on Wayland sessions. It now uses native Wayland backend by default providing better efficiency, DPI scaling, touchpad gestures etc
Is it though https://gitlab.freedesktop.org/mstoeckl/waypipe
That’s the English language in a nutshell from my perspective as non-native