Live data from Hacker News

Preparing for KDE Plasma's Last X11-Supported Release

blog.davidedmundson.co.uk

381–390 of 392 posts

Re: Preparing for KDE Plasma's Last X11-Supported Release

#381

Earlier quoted context omitted.

alt + left mouse button anywhere in the window (maybe win button or something is default now). using the titlebar for moving a window is extremely backwards and productivity killer. that being said, I agree with you, and I think its an outright abomination to put the tabs in the titlebar, and its disgusting how crome and firefox by default removes the real titlebar

Alt+LMB drag is impossible to do properly, at least on Windows, because too many applications use that for their own inputs. There are some X11 applications that also use that (Blender?), so while it's cool when it works, it comes with pretty severe problems.

there might exist some programs that do it, but this might be why they changed default from alt to win key.

in either case, that appears to be the very extreme minority of cases you have to move a window

Re: Preparing for KDE Plasma's Last X11-Supported Release

#382
post #8

What's sad is that after many years Wayland still lacks several things/features that X11 has/allows. Some of them are intentionally not implemented because of security paranoia. For example, Chrome "picture in picture" window doesn't stay on top when I click somewhere else since Wayland doesn't allow windows to stay on top. If I had a lot of time I could list how Wayland breaks many applications. Not saying that X11…

> Wayland doesn't allow windows to stay on top

I use Wayland and it has a "stay on top" option for windows.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#383
post #341

Earlier quoted context omitted.

Things like input methods, certain accessibility functions, screen savers and similar things.

Huh? Fcitx and IBus both worked on GNOME and KDE as far as I'm aware. Now, Fcitx using QT and IBus using GTK helps them feel more native on KDE and GNOME respectively, but they would both work .

Doesn't seem possible on Gnome and not very straightforward on other DEs according to the arch wiki: https://wiki.archlinux.org/title/Fcitx5#Integration

Re: Preparing for KDE Plasma's Last X11-Supported Release

#384
post #383

Earlier quoted context omitted.

Huh? Fcitx and IBus both worked on GNOME and KDE as far as I'm aware. Now, Fcitx using QT and IBus using GTK helps them feel more native on KDE and GNOME respectively, but they would both work .

Doesn't seem possible on Gnome and not very straightforward on other DEs according to the arch wiki: https://wiki.archlinux.org/title/Fcitx5#Integration

It seems to me that the issues on that page are Wayland-specific; anectotally, on my random X window manager works fine with Fcitx (except for Emacs, but that's probably Emacs' fault, not the IME protocol's).

Re: Preparing for KDE Plasma's Last X11-Supported Release

#386

Earlier quoted context omitted.

alt + left mouse button anywhere in the window (maybe win button or something is default now). using the titlebar for moving a window is extremely backwards and productivity killer. that being said, I agree with you, and I think its an outright abomination to put the tabs in the titlebar, and its disgusting how crome and firefox by default removes the real titlebar

Alt+LMB drag is impossible to do properly, at least on Windows, because too many applications use that for their own inputs. There are some X11 applications that also use that (Blender?), so while it's cool when it works, it comes with pretty severe problems.

Alt-drag works perfectly well on windows. I use a third party app called alt-drag to enable it. Has worked fine for years.

It also allows you to use it with win-drag of course.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#387

Sadly, recent GNOME versions introduced a hard dependency on systemd and can no longer be used on systemd-free distros. This is the kind of problem that the anti-systemd people had in mind back then when debates about systemd raged.

This is a good thing. Gnome and systemd both suck.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#388

Earlier quoted context omitted.

I don't get it, if you're on google meet, and you want to make one of many videos PiP. How can you ever do that in the window manager? It has to be done in the application! You right click or click on the menu on that particular video, and click Picture in picture. How the heck can the window manager do it?

If things were designed well, it would be as easy as clicking the pin icon on the window border.

That's what I have in my setup, six titlebar buttons: send to other screen, sticky among workspaces and always on top in addition to the base 3. Can't imagine ever using something that gives me less control again.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#389

Earlier quoted context omitted.

> unprivileged X11 programs that use the Scroll Lock light as an indicator I didn't know such apps existed! What do they use it for?

One use case is a new message indicator. Unlike icons on the desktop, keyboard lights are visible even when a full-screen application is running, or when we're to the side of or across the room from the computer, or when the display is asleep. I depend on this for my daily communications. Another use case is for keyboard macro utilities to indicate the state of layers, modifier modes, or multi-keystroke input sequenc…

Which programs can be configured in this way? Something custom you wrote?

Re: Preparing for KDE Plasma's Last X11-Supported Release

#390
post #32

Earlier quoted context omitted.

Did you really just [sic] a British guy using British spelling?

Is that a British spelling? Oops. Honestly my computer gave it a red underline so I decided to do that. I didn’t think about it harder than that. If I recognized it like “colour” I wouldn’t have.

> my computer gave it a red underline so I decided to do that.

Why? You were quoting text so it would never be confused for yours anyway.

Post reply on HN