Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xfwl4 – The Roadmap for a Xfce Wayland Compositor

alexxcons.github.io

Post reply on HN
Print view View original

151–160 of 339 posts

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#151

Post by mhitza »

jchw wrote: post #88
ok123456 wrote: post #20

Earlier quoted context omitted.

Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems. At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to sup…

Here's my PoV: - Having a single X server that almost everyone used lead to ossification. Having Wayland explicitly be only a protocol is helping to avoid that, though it comes with its own growing pains. - Wayland-the-Protocol (sounds like a Sonic the Hedgehog character when you say it like that) is not free of cruft, but it has been forward-thinking. It's compositor-centric, unlike X11 which predates desktop compos…

You seen to know your Waylands.

Do you know if global shortcuts are solved in a satisfactory way, and if there easy mechanism for one application to query wayland about other applications.

One hack I've made a while ago was to bind win+t command to a script that queried the active window in the current workspace, and based on a decision opened up a terminal at the right filesystem location, with a preferred terminal profile.

All I get from llms is that dbus might be involved in gnome for global shortcuts, and when registering global shortcuts in something like hyperland app ids must be passed along, instead of simple scripts paths.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#152

Post by gf000 »

diath wrote: post #144
PunchyHamster wrote: post #64

Earlier quoted context omitted.

It's mostly coz nobody really wants to improve X11. I don't think there is many wayland features that would be impossible to implement in X11 it's just nobody wants to dig into crusty codebase to do it. And sadly wayland decided to just not learn any lessons from X11 and it shows.

What do you mean nobody wants to improve X11? There were developers with dozens of open merge requests with numerous improvements to X11 that were being actively ignored/held back by IBM/Red Hat because they wanted Wayland, their corporate project, to succeed instead.

Reviewing PRs and merging them requires great effort, especially in case of a non-trivial behemoth like X. Surely if all these merge requests were of huge value, someone could have forked the project and be very happy with all the changes, right?

Not having enough maintainers, and some design issues that can't be solved are both reasons why X was left largely unmaintained.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#154

Post by gf000 »

MrFurious wrote: post #87
adzm wrote: post #65

Earlier quoted context omitted.

What about systemd?

Systemd was easy for me. All things worked in transition and have the big advantage that don't need shell scripts for create services. Wayland..., is slow, buggy, applications close without reason...

How on earth would Wayland be slow? Like it's literally an IPC on top of the lowest level Linux kernel API (DRM), displaying buffers.

It was partially made for car infotainment systems that are knowingly weak hardware.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#155

Post by mikkupikku »

PaulDavisThe1st wrote: post #148
yason wrote: post #126

Earlier quoted context omitted.

Because Wayland only does essential low-level stuff such as display and graphics it forced people to start coming up with a common Linux desktop (programming) interface out of nowhere to basically glue everything together and make programs at least interoperate. Such an effort to rethink Linux desktop alone could've been a major project on its own but as having something was necessitated by Wayland all of it has beco…

Nobody has a user-space stick big enough to force things in the Linux world. When Apple dropped the old audio APIs of classic macOS and introduced CoreAudio, they pissed off a lot of developers, but those developers had no choice. In the GUI realm, they only deprecated HIKit for a decade or two before removing it (if they've even done that), but they made it very clear that CoreFoo was the API you should be using and…

GNOME has enough weight to at least force most projects to accommodate them. But unfortunately this has mostly been for the worst, as GNOME is usually the odd one out with most matters of taste and design.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#156

Post by davidgerard »

jchw wrote: post #3

I hope that XFCE remains a solid lightweight desktop option. I've become a huge fan of KDE over the past couple of years, but it certainly isn't what you would consider lightweight or minimal. Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it…

Long-time XFCE user here. We care that stuff works the same, we appreciate how much work it is to achieve that when the world is changing out from under you, and we appreciate that XFCE understands this and cares about it. Being in Rust is not a concern.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#157

Post by davidgerard »

gmueckl wrote: post #129
bee_rider wrote: post #114

Earlier quoted context omitted.

This seems to be implying that the creation of Wayland had some motivation that was essentially malicious toward X. Is that right?

This question sounds to me like you suspect some outright evil getting projected here. That would go too far. The wayland project tried to get the support of X developers early so that they could become a sort of "blessed" X successor early on. Plenty of earlier replacement attempts have failed because they couldn't get bigger community support, so this had to be part of a successful strategy. Any detrimental effects…

This isn't quite right? Wayland was literally created by an X11 developer who got two more main X11 developers in. It's a second system, not a competitor as such.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#158

Post by duped »

elektronika wrote: post #146
fork-bomber wrote: post #89

Earlier quoted context omitted.

This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of…

> This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. I have done it and it left a bad taste in my mouth. Once you're doing interop with C you're just writing C with Rust syntax topped off with a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer. It's unergonomic and you lose the differentiating features of Rust. Writing safe bindings i…

> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer

You just have to get over that. `unsafe` means "compiler cannot prove this to be safe." FFI is unsafe because the compiler can't see past it.

> Once you're doing interop with C you're just writing C with Rust syntax

Just like C++, or go, or anything else. You can choose to wrap it, but that's just indirection for no value imo. I honestly hate seeing C APIs wrapped with "high level" bindings in C++ for the same reason I hate seeing them in Rust. The docs/errors/usage are all in terms of the C API and in my code I want to see something that matches the docs, so it should be "C in syntax of $language".

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#159

Post by prima-facie »

treve wrote: post #119
prima-facie wrote: post #15

Am I the only one who's not buying into the Wayland hype? I just want X11 support not to fall into disrepair, as I see nothing wrong with it.

Some cognitive dissonance going on here. The vast majority of current Linux Desktop users are on Wayland, and X11 is phased out across the board. Calling it hype is absurd.

Sure, but do you have any facts to backup that assertion?

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#160

Post by gf000 »

throw0101a wrote: post #78
ux266478 wrote: post #70

Earlier quoted context omitted.

It depends on what you mean by send. Wayland doesn't have network transparency, there's a bit of a song and dance you have to do to get that working properly. I'm not sure the state of that or of Wayland compositors in general on Mac.

> It depends on what you mean by send. Currently I can: $ ssh -X somehost xeyes and get a window on macOS.

For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.

X's network transparency was made at a time when we drawn two lines as UI, and for that it works very well. But today even your Todo app has a bunch of icons that are just bitmaps to X, and we can transfer those via much better means (that should probably not be baked into a display protocol).

I think Wayland did the correct decision here. Just be a display protocol that knows about buffers and that's it.

User space can then just transport buffers in any way they seem fit.

Also, another interesting note, the original X network transparency's modern analogue might very well be the web, if you look at it squinted. And quite a few programs just simply expose a localhost port to avoid the "native GUI" issue wholesale.

Post reply on HN