These are the problems you're facing on Linux, and I'm baffled!
leopold @ leopold @lemmy.kde.social Posts 46Comments 329Joined 2 yr. ago
can't find any client by that name
No. all KDE config is in the home directory except maybe some SDDM stuff, which should be trivial to reconfigure if needed.
You learn significantly more from actually fixing the problems with your install as opposed to just constantly starting over every time. Doing it just to get rid of a couple of GNOME packages is especially not worth the trouble, considering it's a rather trivial task.
Permanently Deleted
Enlightenment is easily the lightest full DE. It is my recommendation.
The idea that a web application for screen recording is less bloat than OBS is absurd. As this was the idea presented by OP, atzanteol reacted by figuratively saying that the word no longer had any meaning. Given the context, this was quite clearly not an attempt to downplay the effects or severity of software bloat, but simply a figurative use of the phrase meant to point out how badly the word bloat had been misused. You completely misinterpreted their comment. Then, when this was pointed out to you, you proceeded to do the Reddit thing of mockingly editing your original downvoted comment, successfully making an ass out of yourself.
The D3D shader compiler has been open source for many years. This is just a new version of it.
KDE3's Plastik style was closer to XP's Luna than Vista/7's Aero. The default icon theme CrystalSVG had a colorful pastel and cartoonish style. There's a full port of it to Plasma 5 here. It should still work fine in Plasma 6.
The Plasma 4 Oxygen style was much closer to the detailed realistic skeuomorphic style of Aero (though it was probably more so inspired by early OSX Aqua). It is still usable on Plasma 6 and packages for the theme should be available in your preferred distributions' repositories.
Crystal Remix is really a mix of three icon themes designed by Everaldo Coelho in the 2000s. Only the first of these, the aforementioned CrystalSVG, was ever an official KDE theme. The second is Crystal Clear, the successor to CrystalSVG. It had a more detailed and realistic style compared to CrystalSVG, looking far closer to Aero. The third one is Crystal Project, the final iteration of Crystal. It went further into Crystal Clear's direction and erased the last vestiges of CrystalSVG's more cartoonish style. Crystal Project's icons are particularly detailed and I'd consider it a really underappreciated piece of skeuomorphic icon design.
Personally, I'm not that big on Crystal Remix. I'd prefer either a complete CrystalSVG-styled icon theme or a complete Crystal Project-styled icon theme. Preferably the latter because the former already pretty much exists. The two styles don't mesh together all that well, IMO. Crystal Remix's coverage (especially for action icons) is also a bit lacking and it's pretty common to run into unthemed Breeze icons in some applications.
Crystal Dock doesn't strike me as particularly KDE3-ish. It's basically nothing like KDE3's Kicker, though there were a lot of popular third party docks in the KDE3 era like KoolDock, which were actually quite similar to this project. All of them are gone by now and there's been a lot of demand for new third party docks since the death of Latte Dock. So I anticipate this project will make quite a few people happy.
How? D3D9 only needs HLSL 3. Perhaps you meant adding support for newer D3D versions? D3D10 and D3D11 support are certainly possible, though even still D3D11 only needs HLSL 5. As for D3D12, it would be impossible for the same reason Vulkan on Gallium is impossible; it's too low level.
Anyway, I've used Gallium-Nine with RadeonSI. It works fine. It can even be faster than DXVK, sometimes. Other times, DXVK is faster. They're about on par. Which kinda begs the question, what's the point? Gallium-Nine isn't substantially faster than DXVK and is much less portable, since it requires a Gallium3D driver to work, so it won't work for Nvidia. The Nouveau Gallium3D driver is way too slow to come close to DXVK. Zink + Gallium-Nine probably works, but I also can't see that beating DXVK. That's the reason Gallium-Nine died. Not because they didn't have the latest HLSL, but because DXVK killed interest in the project.
Elisa wasn't really meant to be an Amarok successor, it just kinda turned out that way because Elisa popped up around the time of the Plasma 5 release while Amarok never made the Qt5 transition. There were other reasons for Amarok's death (before its recent revival), though Elisa could be considered a factor.
Kontact is on Flathub, so it is definitely possible.
EDIT: Merkuro is apparently bundled with the Kontact Flatpak. Seems like they're just shoving anything that uses Akonadi in that package. So on one hand, it seems there is a Merkuro Flatpak already. On the other hand, it's bundled with a bunch of extra stuff you probably don't need if you're using Merkuro (like the entire Kontact suite), so you're probably better off with distro packages.
I guess the main improvement is that the panels and sidebars don't cover the desktop, so you can edit all of it more easily.
To me the most annoying thing with edit mode was that auto-hide panels would still hide in edit mode, making them difficult to edit, but that was also fixed a little earlier.
It's not being packaged by distros yet. You need to build from source.
Mesa + DXVK/WineD3D/VKD3D/Gallium-Nine.
CC BY-SA is considered open source. CC BY-NC is not.
Wine doesn't wait for major versions to merge major features. Major versions like Wine 9.0 are considered stable and are preceded by a feature freeze and multiple release candidates. Minor versions like Wine 9.9 are not, they're just released every two weeks from the master branch. This means nearly all of Wine 9.0's killer features were already present in the final Wine 8.21 minor version. The same will be true with Wine 10. Wayland support will continue to improve incrementally in the coming versions.
Sure.
#56000 Window title is not set with winewayland
winewayland.drv: Enable wglDescribePixelFormat through p_get_pixel_formats.
winewayland.drv: Set wayland app-id from the process name.
winewayland.drv: Implement SetWindowText.
winewayland: Get rid of the now unnecessary surface wrapper.
winewayland: Remove now unnecessary swapchain extents checks.
winewayland: Remove now unnecessary swapchain wrapper.
configure: Check the correct variable for the Wayland EGL library.
winewayland.drv: Implement wglCreateContextAttribsARB.
winewayland.drv: Implement wglShareLists.
winewayland.drv: Implement wgl(Get)SwapIntervalEXT.
Initial OpenGL support in the Wayland driver.
winewayland.drv: Add skeleton OpenGL driver.
winewayland.drv: Initialize core GL functions.
winewayland.drv: Implement wglGetExtensionsString{ARB,EXT}.
winewayland.drv: Implement wglGetProcAddress.
winewayland.drv: Implement wglDescribePixelFormat.
winewayland.drv: Implement wglSetPixelFormat(WINE).
winewayland.drv: Implement OpenGL context creation.
winewayland.drv: Implement wglMakeCurrent and wglMakeContextCurrentARB.
winewayland.drv: Implement wglSwapBuffers.
winewayland.drv: Handle resizing of OpenGL content.
winewayland: Remove now unnecessary vulkan function name mapping.
winewayland: Remove unnecessary vkDestroySurfaceKHR NULL checks.
New minor versions of Wine are released every two weeks. Last major Wayland update was in 9.4. Smaller updates have happened every release since, except 9.6.
I would consider the "source code" for artwork to be the project file, with all of the layers intact and whatnot. The Photoshop PSD, the GIMP XCF or the Krita KRA. The "compiled" version would be the exported PNG/JPG.
You can license a compiled binary under CC BY if you want. That would allow users to freely decompile/disassemble it or to bundle the binary for their purposes, but it's different from releasing source code. It's closed source, but under a free license.
Package management is probably the biggest thing a Linux user might need to use the terminal for. The graphical package managers used by default on most desktop environments are far too limited.
KDE's Discover for instance is capable of installing (graphical) desktop applications, uninstalling packages and performing updates. Sure, it supports native packages on the majority of distros through PackageKit, as well as Flatpaks and Snaps, but it can only perform very basic package manager operations. I imagine most users will at some point need to install a package that isn't a graphical desktop application, such as a driver or an optional dependency and they will need to use the terminal for it.
To my knowledge, this is also the state of most other graphical package managers that take the form of "software centers" like Discover. More powerful graphical package managers do exist, usually specific to a specific package manager such as Octopi for Pacman. Few distros ship with them, however. I believe one notable exception is OpenSUSE with YaST. There's also dnfdragora on Fedora, which is pretty basic, but might be good enough for most purposes.
why did it insert and translate some random japanese phrase in the lede