leopold @ leopold @lemmy.kde.social

Posts

0

Comments

239

Joined

2 yr. ago

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.

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.

Wine 9.9 bug fixes:

#56000 Window title is not set with winewayland

Wine 9.8 minor changes:

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.

Wine 9.7 minor changes:

winewayland: Remove now unnecessary swapchain extents checks.
winewayland: Remove now unnecessary swapchain wrapper.

Wine 9.5 minor changes:

configure: Check the correct variable for the Wayland EGL library.
winewayland.drv: Implement wglCreateContextAttribsARB.
winewayland.drv: Implement wglShareLists.
winewayland.drv: Implement wgl(Get)SwapIntervalEXT.

Wine 9.4 major changes:

Initial OpenGL support in the Wayland driver.

Wine 9.4 minor changes:

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.

OnlyOffice is not based on LibreOffice. There might be a point in joining forces with OpenOffice if OpenOffice actually had forces to join with, but it doesn't because it is a dead project.

Indeed, but GNOME is big enough to veto against anything they dislike getting into Wayland. And indeed, TWMs were brought up as a big reason why CSD sucks; window decorations primarily contain controls for the window manager and the form these controls should take depends entirely on the nature of the window manager, therefore the window manager should draw the controls. But GNOME doesn't want to perform the oh so difficult task of providing window controls to apps that don't provide their own under Wayland, so too bad.

it's a frontend for ollama. so no, because under the hood it is ollama.

especially considering KDE already has an application with almost exactly the same name for the same purpose https://invent.kde.org/utilities/alpaka

Proton+DXVK is pretty darn efficient. On average it is slightly slower than Windows, but not by much and it can also be faster in certain games.

It shouldn't speed up anything on Proton, since it already uses f-sync, which gives the same speedup, but breaks some apps, which is why Wine wasn't using it and ntsync was created as an alternative.

When I last tried it (around the time that article was posted, could've improved since), you needed to mess with gconf to enable the feature, which was for good reason because the compatibility was abysmal (ublock origin did not work and neither did dark reader or violentmonkey or really any extension I wanted to use).

i3 doesn't support Wayland, not the other way around. It's an X11 window manager. Not sure why you would expect it to work on Wayland.

It's even more bonkers than it sounds. If you look at the code locations for that KDE count, you'll see it also includes just about every KDE project. That's not just Plasma, that's hundreds of projects, including some really big ones like Krita, Kdenlive, Calligra, LabPlot, Kontact, Digikam and Plasma Mobile. Hell, it even includes KHTML/KJS, KDE's defunct web engine as well as the ancestor of WebKit and Blink. It even includes AngelFish and Falkon, KDE's current web browser frontends.

Same deal with GNOME. It includes just about everything on GNOME's GitLab, even things that are merely hosted there without strictly being GNOME projects, like GIMP and GTK.

And yet still they are both that far behind Chromium and Firefox. Modern web browsers are ludicrous.

it's a drop-in replacement for i3 on wayland

Well, it is basically LibreJS logic applied to an entire distro, like your typical FSF-approved distro. It's a distro by free software extremists for free software extremists and no one else. It's is completely impractical for actual use. But really it's worse than the average FSF-approved distro. It takes things several steps further by removing many things that are 100% free software, but just subjectively disliked by the maintainers, including even the Linux-libre kernel, as the project is in the process of moving to an OpenBSD base. The OpenBSD people naturally want nothing to do with them, so I'm looking forward to seeing that play out.