171–180 of 419 posts
Moving from X will be painfull. I remember that first non X Server OSX versions were buggy as hell...
DPS was available as extension on X11, but it wasn't the same implementation as on NeXTSTEP, where AFAIK even the old 0.8 code already used Mach IPC for communication with window server.
We all saw this coming.
Shame on those who speak / think ill of Wayland. /s
Earlier quoted context omitted.
> Still, it does not seem a really fundamental problem, it must surely be solvable from within X? X gives you two options: set DPI per displays. The thing is, you cannot drag windows between displays, the app has destroy it, connect to another one and recreate it here. There's even no mechanism to detect multiple displays other that user setting up the DISPLAY env variable. Or you can do, as the Xorg does: use multip…
> [Xorg] limitation is, that all screens have to have same DPI. The limitation is not true. Yes, the core protocol gives you a single, global DPI value. However, who cares about the core protocol? You have XRandR, which gives you a per-screen DPI. Alternative, you could have a freedesktop standard/convention where the DPI is stored as a global property of the root window, in a array of values, one for each display, s…
Not so fast!
Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998? It certainly won't respect you new protocol.
How the compositors are supposed to handle that?
If you are not going to handle it, and just let it behave as it behaves today, you are still not achieving your goal of scaling all clients properly, and kind of throwing away that 30 years of development by making it unusable anyway.
As long as there are no replacements for tools like wmctrl and xdotool Wayland is not in a usable state for me.
Earlier quoted context omitted.
> Because software engineers working for companies will know the struggle of trying to justify reducing technical debt, improving security practices, etc. but fail to see why these things are useful to them personally when the tables turn. Problem is, ever so often what should reduce technical debt ends up also reducing "technical assets" even more. Firefox is a perfect example of this, they reduced technical debt by…
Firefox has treesyle tabs which has zero good alternatives on chrome. Tridacyl, vim like bindings for your browser + ability to bind javascript or native shell is more powerful than chrome alternatives. Chromium is losing google sync and chrome and chromium are Effectively destroying adblocking sooner or later courtesy of manifest v3. Ublock origin and treestyle tabs alone make a compelling case and are visually and…
In fact I asked yesterday and it was an interesting experience: https://bugzilla.mozilla.org/show_bug.cgi?id=1332447#c170
Wayland doesn't even work for me, so I guess I don't have such problems. I'm not really into the actual arguments between NVidia and Wayland folks, but I suspect it's something like "they don't want to bow to us, therefore we don't want to work with them" from both sides. Like a kindergarten ;)
It's more like "Nvidia claims they support a certain API, but it's utterly broken, and developers are rightfully fed up with that".
Earlier quoted context omitted.
I haven't seen many desktop apps emerging in the last decade, so whom is that "legacy is holding back the Linux desktop" argument addressed at? X may not be the most modern architecture, but it's still the API almost all F/OSS desktop apps are ultimately written and tested against. For many apps, wayland doesn't bring a new perspective, but end of life with no new apps taking their place. For other apps, wayland mean…
We (desktop devs) eventually gave up on it and are enjoying our Windows/macOS/Android/ChromeOS setups instead.
The rest of the new desktop apps are electron which doesn't care about X vs Wayland
Earlier quoted context omitted.
> It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues. Many seasoned Xorg developers work on Wayland. All the decades of lessons form Xorg _were_ carried over to Wayland.
>> Many seasoned Xorg developers work on Wayland. All of them are either working on Wayland or moved on. There are no Xorg developers.
Earlier quoted context omitted.
As a complete outsider - ok, I'm a developer, but I haven't had the pleasure (?) of writing something that interfaces directly with Xorg yet - I have been reading for years about Wayland being the way forward and how Xorg is dragged down by a long history of dubious design decisions and features nobody needs anymore, and I was secretly wondering: if this is really the future of desktop Linux, why doesn't it gain more…
> This post is a bit too ranty for its own good, but it has a valid point, and one that is unfortunately common in the open source community: because you have no monetary obligation to your "customers" (=users), there's not really a lot that forces you to maintain backwards compatibility. And yet, distros like Ubuntu are too conservative, because they are too careful not to break something. Their signalling is then c…
eg. for years you couldn't resize a window from the left edge and everybody was "fine" with it. When they actually bothered to implement it, it was astounding to think you couldn't do it before!
As for me, I await each Apple release with trepidation and fear.
Will my audio hardware continue to work? (They break the utilities most releases).
Will I need to buy a new version of Parallels or VMWare because Apple changed the virtualisation API? (This happened a few years ago).
Will my apps no longer work? (Goodbye useful 32 bit apps that I can't find a 64 bit version of).
Will they just break random things? eg. PDF viewing, Quickview of multiple files (both of these happened to me).
Will they change random things for the sake of it? eg. Giant spacing between icons on the menubar on Big Sur. Behaviour of the maximise button into "full screen" button just because they could (a few releases ago).
Will my machine be slower for no apparent reason? HFS+ to APFS makes my machine start up TWICE AS SLOW.
The best bits are due to the Objective-C message passing, old apps will make a "call" to a function that no longer exists and it won't break - it'll just do nothing. You literally have no idea if your app will continue to work between releases, even if it runs and the certificate for the app hasn't expired...
And I say this as a daily user of macos! It just isn't reliable between releases.
Earlier quoted context omitted.
Having a singular library is more limiting than X even for a developer of a wm and much more so to user who can no longer merely assemble an environment by setting a list of components to be started by a script.
That's exactly how I'm assembling my Sway session. My Sway config ends with `exec systemctl --user start sway-session.target`, and that target links to all the services I want running in my session (redshift, notification daemon, etc.). If you don't like systemd, you can `exec my-session-startup-script.sh` in the exactly same way. The Sway devs maintain a list of common helper applications that work with Sway: https:…
Creating a user service per single line exec foo is extra ceremony.
I have nvidia hardware so sway makes no sense for me to use.
Also it's developer is extremely abrasive.
Furthermore a lot on that list isn't an even trade.
ydotool is a poor unmaintained replacement, making your own custom layout is a lot more work than xmodmap.
On net if you don't have mixed dpi so far as I can see you aren't actually gaining anything.
The best sales pitches I've seen are almost as good as what you already have but on wayland.
Is there anyway that sway does better than i3?