291–300 of 339 posts
Earlier quoted context omitted.
> running XFCE on Wayland is going to make it slower Citation. None of the other desktops have slowed with Wayland, and gaming is as fast as, if not marginally faster on KDE/Gnome with Wayland vs LXDE on X. https://www.phoronix.com/review/ubuntu-2504-x11-gaming
I based it on this thread - https://news.ycombinator.com/item?id=46780901
Earlier quoted context omitted.
I don't really get your first 2 paragraphs. We are talking about connecting remotely to another computer, you can't do much at the other end of a network call with a server allocated buffer - at most you can cache stuff there. But that ain't helping with a video or any kind of fancier than a solid rectangle graphics. And sure, simple UIs have their place - but they will also work just as well with a proper transport…
You can cache icons on the server, you do not need to send them over a network, that is it. With video, I'm saying it is a case where wayland is not better, it is just the same. So you say compression of said icons, etc, is better than caching them on the server? No.. You've mentioned web, but no one does that on the web.
Earlier quoted context omitted.
I don't really get your first 2 paragraphs. We are talking about connecting remotely to another computer, you can't do much at the other end of a network call with a server allocated buffer - at most you can cache stuff there. But that ain't helping with a video or any kind of fancier than a solid rectangle graphics. And sure, simple UIs have their place - but they will also work just as well with a proper transport…
You can cache icons on the server, you do not need to send them over a network, that is it. With video, I'm saying it is a case where wayland is not better, it is just the same. So you say compression of said icons, etc, is better than caching them on the server? No.. You've mentioned web, but no one does that on the web.
Earlier quoted context omitted.
What about systemd?
systemd was a problem for early adopters (e.g., Fedora). Distros like Debian joined the party later and, as a result, got things way more stable. I never had any systemd-related problem in Debian, while for Fedora (some years earlier) I had some bugs affecting my ability to work. They all seem to work very fine now. Things took a while to mature, but it just works now.
Mind you, the libc5 -> glibc2 upgrade was pretty horrible in Debian land, so they didn't always get it right in the early days...
Earlier quoted context omitted.
You can cache icons on the server, you do not need to send them over a network, that is it. With video, I'm saying it is a case where wayland is not better, it is just the same. So you say compression of said icons, etc, is better than caching them on the server? No.. You've mentioned web, but no one does that on the web.
I mean, no one does what you suggest on the web. You do not render a web page to an image and send that to a browser. To summarize. No one wants X11 transparency to run a web browser. But ok, if someone wants to do that.. X11 still can be more advantegeous over waypipe.
But again, GUI apps don't use X draw commands for the most part, so they are effectively a bitmap/video stream to X's eyes. And what's better to transport a video stream than a format designed for efficient transport of video streams.
Earlier quoted context omitted.
Are you willing to write accessibility support for the new xfce only wayland compositor? How will you get every other wayland compositor to support your non-'wayland core' accessibility extension? People like to frame things like the waylands are some sort of default and nothing is being lost and no one is being excluded.
Everyone has settled on an accessibility standard (Matt Campbell's). So it's not "your" accessibility protocol, it's already "the" accessibility protocol. This is working as intended IMO: allow things to compete and future in the wild and then pick the fittest.
Since you seem informed perhaps you can clear something up for me, when Cambpell says "push full accessibility tree to trusted clients" does that mean you get the entire desktop tree, or only for that application?
Because if you don't get the entire window tree, because you only get the single windows information when that application provides it, it is highly incompatible with existing solutions. They say it is compatible because application developers can create a new virtualized thing themselves. But that's not compatible. And beyond that, it is a "solution" that prevents me from controlling my own computer. I understand GNOME is targeting everyone not just power users. But as a power user I am someone. I am a human being.
And Campbell's assertions that push is more performant than pull and full tree are being backed by arguments informed from problems that don't even apply generally. GTK 4 broke this, not GTK 3. It's not a push versus pull thing. It's wayland architecture focused Gtk4 causing the problem when things are fine in X11 focused GTK 3. ref: https://gitlab.gnome.org/GNOME/gtk/-/issues/6269 a11y: No API for supporting a11y Selection interface , https://gitlab.gnome.org/GNOME/gtk/-/issues/6204 a11y AT-SPI: get_child_count implementation iterating over all children causes freeze for objects with many a11y children
Earlier quoted context omitted.
I mean, no one does what you suggest on the web. You do not render a web page to an image and send that to a browser. To summarize. No one wants X11 transparency to run a web browser. But ok, if someone wants to do that.. X11 still can be more advantegeous over waypipe.
Because on the web we have a very very complex protocol(s) built up over decades to tell a client what to draw locally. That's html/css/js and its scope is far larger than of x draw commands (it's also an application model). But again, GUI apps don't use X draw commands for the most part, so they are effectively a bitmap/video stream to X's eyes. And what's better to transport a video stream than a format designed fo…
Also the font rendering. The client could then just send text to the x11 server if it was not vector fonts.
x11 xrdb. With it you can configure say font size on your computer, not on the computer where program is running. Say comp1: 10pt, comp2: 20pt.
Earlier quoted context omitted.
I am not complaining about what people do in their spare time. If the blog post said "someone does this because he likes to spend his own time on it", I would not complain. I am complaining about a) the justifications given which I think are all nonsense IMHO and rationalizations for something which some likes to do, and b) the use of donations which should be better used to improve the software instead of creating m…
> I am not complaining about what people do in their spare time. Re-read your original post. You are absolutely complaining about what we do in our spare time. > If the blog post said "someone does this because he likes to spend his own time on it", I would not complain. I mean, that's part of it. I wouldn't do it if I wasn't interested in doing it. I have my own long list of Wayland criticisms, but I think it's inte…
> Re-read your original post. You are absolutely complaining about what we do in our spare time.
Then I am not sure how I have to understand this sentence: "After careful consideration, we’ve decided on a meaningful way to use the generous donations from our community: funding longtime Xfce core developer Brian Tarricone to create xfwl4, a brand-new Wayland compositor for Xfce."
Earlier quoted context omitted.
(xfwl4 author here.) That's a fair criticism sometimes, but, frankly, if you want things the way you want them, learn to code and dig in. Otherwise it's not really fair of you to complain about stuff that people have built for you for free, in their spare time. In this particular case, it's not fully a "new and shiny, must play!" situation. I personally am not even a big fan of Wayland, and I'm generally highly criti…
> That's just the way the wind is blowing. I trust you understand that some readers may not find (to paraphrase) "I don't like it either but it is what it is." a compelling reason to fix something that is not broken.
Rust is not GNU