• 9 Posts
  • 207 Comments
Joined 1 year ago
cake
Cake day: June 6th, 2023

help-circle
  • But Wayland isn’t a thing on its own, there’s no “Wayland server” or anything else equivalent to the X server. The compositors like Kwin or GNOME’s Mutter are Wayland implementations fully responsible for handling the display output.

    You can blame Wayland for the lack of universally supported global hotkeys or for issues with apps that need to know exactly where on the screen they are - these are issues with the protocol - but not for bugs in one compositor’s implementation of display management.




  • I can’t speak for these specific laptops, but unlike x86, ARM generally doesn’t have a way for an OS to discover the available hardware, and most ARM platforms historically didn’t do anything to help. There is a standard for UEFI on ARM where the UEFI is supposed to tell the OS about the hardware, but as far as I know this is only a thing on ARM servers and these laptops might not support it.

    Without any way of probing for hardware or getting the information from UEFI, Linux has to somehow be compiled with all the info about the hardware built-in. And the build will be model-specific (there’s a way to pass a file describing the hardware to Linux from the bootloader which enables a single kernel to be used on multiple models and have just a small part of the bootloader be model-specific, but somebody still needs to make that file and the manufacturers clearly don’t intend to do that).




  • As the other person said, what you’re doing is pretty much emulating the behavior of tiling window managers. Edit while writing: I’m leaving the rest here because you might find it useful, but I’ve just realized that there’s a tiling extension for GNOME (the desktop environment used by Ubuntu): Tiling Shell. That’s definitely going to be the most painless way for you to try out tiling. There’s also bound to be something similar available for KDE.

    I think you will get a much better result than with virtual screens by configuring one to your taste, assuming you’re willing to spend a few hours learning all the ins and outs (it’s absolutely OK if you’re not willing to do that).

    Here’s links to a few of them, you should be able to install them in whatever distro you prefer:

    Hyprland - a tiling WM focused on good out of the box experience and animations (but it’s still very configurable). If you want to get your feet wet with standalone tiling WMs as fast and painlessly as possible, this is IMHO the way

    Sway - a more keyboard-centric tiling WM that leaves out the fancy stuff (for example I don’t think there’s any way to do window shadows or animations for all the window manipulation) and focuses on just being fast and efficient if you learn its concepts. This is the only one I’ve ever used for longer periods of time.

    SwayFX - “Sway, but with eye candy!” - I don’t think I can write a better description - has some graphics effects like window blurring or shadows.



  • Pixel - varies by manufacturer

    That was the Nexus line, Pixel phones are all made by Google. Although Pixel 5 series and older use Snapdragon SoCs, while 6 onwards use Google’s custom Tensor based on Samsung’s Exynos. The major downside is IMHO the awful modem efficiency - if I want to keep mobile network on so that I can receive calls, my 7a is limited to 2 days of battery life if I’m lucky (and that’s with barely using the phone, just a few pictures).

    Edit: and I forgot to mention that all Pixels have great third party ROM support, except if you want GrapheneOS, in which case you need to go for the recent ones that are still supported by Google.


  • They probably fixed all the bugs they considered essential, and the rest is just nice to have fixes that can be moved to the next cycle if necessary (and they still have a week to work on them before release, although they might be careful not to introduce severe bugs now).

    The general idea with this approach is that it doesn’t make sense to block a release on a few bugs worked on by only a subset of available developers and having the rest idle - the project can be finished faster by moving the remaining tasks over to the next release and accepting the bugs in the meantime.





  • Nah, this development version is way worse than both Android 12+ design and Android 11 design - it just has random unlabeled tiles for system settings where you have to guess the meaning by the icon.

    In Android 11, this was only used for the six quick settings you could access when you were looking at the notifications, and they would get labels when you expanded the settings side. In 12+, there are no unlabeled settings anywhere. But this redesign introduced unlabeled tiles for settings you don’t use often, which just seems insane to me.


  • Wow, first time I feel strongly about a quick settings update. It looks awful, taking the worst parts of the Android 12+ redesign and combining them with the worst ideas from the older design, like unlabeled icons.

    It looks like there are unlabeled icons in the expanded state? Wtf? If I’m expanding the quick settings, that means I’m fishing for the less used settings, so there’s no way I’m going to remember that for example the weird circle with a small segment cut out means “Data saver”. It will just be a mystery icon that does some mystery action - that has nothing to do in a modern OS.

    It looks like this design is heavily sacrificing usability for people who don’t spend hours every day mucking around with quick settings in order to please some hypothetical user who feels more slowed down by swiping over one or two screens than by having to find the one setting they currently need in a big matrix of poorly designed icons.

    Edit: also it looks like the home screen is visible under the quick settings - I’m not a big fan of that, I really like the current design where the notifications are pretty much their own separate screen without distracting app content, but that’s just my subjective taste. Unlabeled icons are objectively bad.