Regarding the last point, pompyboard is very much a tablet or pointing device meant only for enthusiast osu! players from what I understand. No artist in the world needs a 8KHz polling rate tablet let alone 1KHz. Tablets from other brands are much better suited for drawing.
While the basic idea of a rectangle you put a pen on is the same for artists and osu! players, the more detailed requirements are basically opposites
Basically:
- Pen click is useless for osu! or can just be digital, while artists would want analog pressure
- Buttons on a pen are actively detrimental for osu! but very useful for artists
- Smoothing on a tablet is more detrimental for osu! the more of it there is but absolutely necessary for artists
- High polling rate is useless for artists (they would have input delay due to the smoothing they need either way) but very useful for osu!
- Big tablets are useless for osu! players as they typically only use a 5-15cm area while they are very useful for artists
I think the entire point of something like pompyboard is to make a tablet just for osu!, which doesn’t exist right now. Meanwhile for artists there is already a whole industry of tablets available for them
I wonder how this compares to Skip[1]? This seems to be focused entirely on Android, as opposed not making existing iOS SwiftUI code work on Android. I assume that might lead to better apps but any practical examples?
Would be great... what I've heard is, Apple's incredible battery life comes from the vertical integration - they make everything, the laptop, the OS... so they are able to optimize it incredibly well. Even running Linux on a Apple Silicon Mac doesn't get you the same kind of battery life because of how much work the OS does putting different components to sleep etc. (though one could argue Apple's arbitrarily making it harder for Linux by making it so much reverse engineering work to get everything to go into sleep mode!)
I don't think it's that per se, it's just apple has a lot of resources to optimise/test a relatively small amount of configurations.
The big "issue" with Linux on non-server workloads imo is a lack of testing like this - which is completely understandable. Afiak Microsoft runs millions of automated tests on various hardware configurations _a day_.
Intel does something similar for the Linux kernel, which no doubt explains the relative stability of Linux server vs Desktop (servers are running far less "OS level" software in general in day to day use than the desktop).
The desktop experience itself needs more automated testing. There are so many bugs/regressions which I've noticed in eg gnome which should have been caught by e2e testing - I do try to report them when I see them.
Doing a bit more digging there seems to be some basic e2e testing for gnome ran nightly but currently most tests are failing https://openqa.gnome.org/tests/12128.
This isn't a criticism at all btw, it's quite boring and resource intensive work for a project like gnome to do. I hope soon some large corp decides to go all in on realLinux desktop (not ChromeOS) and can devote resources to this.
> I haven't booted into Windows in over 3 months on my tower and I'm starting to realize that it's not worth wasting the space for.
Kind of glad to read this, I went into it thinking it will be another person saying "I'll use Linux forever!" the day after installing it, similar to everyone who says their new years resolution is to work out more, then proceeds to go to the gym 2 times total :)
Moved to NobaraOS back in April (gaming focused Fedora based distro) on my desktop tower and haven't used Windows since, nor have I felt the need to. Some minor tinkering with launch options for Steam games aside it's been a smoother experience than Windows was the previous 5 years.
The last Windows computer that I have is my work laptop, which is an acceptable compromise as far as I"m concerned.
No you can't. Turning off Handoff turns off everything that synchronizes between your devices, not just the clipboard. For example call and imessage forwarding.
They decided to do it Gnome style and give the user no options.
I know nothing about any of this and I am surprised to learn that something that is apparently considered to be permanent is stored in something as ephemeral as a browser cookie, and then causes problems if deleted. At least this is how I understand the exchange above.
Any web application really has access only to "ephemeral" storage like cookies or localStorage when used in this manner (you could be cleaning your localStorage for every session too).
Switching to localStorage would help things, but until they do, you can avoid the known failure case for Element Web by not doing that.
Obviously though, they need to figure out a way to reestablish encryption when the keys are gone, as long as you are willing to accept no access to history, or keeping keys encrypted server side.
On the other hand, there’s been a bug open to make a simple harmless change to fix this in Android for 9 months, with no response from Google other than asking for reproduction steps as far as I can tell.
Buganizer is not where you submit code to be reviewed and accepted into Android. And by the author's own admission that change is a hack and not a proper fix. Anyone is free to make a proper fix and upstream it if they wanted to.
No one has presented a remotely correct fix anywhere on that issue, or elsewhere to my knowledge.
You're welcome to write an actually correct patch for android if you want, one that isn't just commenting out code and probably breaking some spec-compliant bluetooth devices.
Make sure to test your patch against all the bluetooth devices in existence to make sure it doesn't regress.
Do that, make a PR, wait the average third-party-android-PR review time (approximately 5 years), and then if your PR isn't accepted at that point we can maybe say Google is intentionally ignoring this issue.
Nobody actually productively commenting in the thread thinks it's a conspiracy theory and everyone acknowledges that the Apple hardware is off-spec. It would be nice to see Android add this workaround.
You have linked me to what sounds like an AI generated comment. AI comments cannot be trusted. AI will make up believable sounding gunk and cannot be trusted.
"The bug", aka not implementing spec violating behavior, also exists in BlueZ, the Linux Bluetooth stack. Is the BlueZ team taking kickbacks to make sure earbuds don't work on Linux, too? They were Google Summer of Code partners, too, so this potentially goes pretty deep.
Basically:
- Pen click is useless for osu! or can just be digital, while artists would want analog pressure
- Buttons on a pen are actively detrimental for osu! but very useful for artists
- Smoothing on a tablet is more detrimental for osu! the more of it there is but absolutely necessary for artists
- High polling rate is useless for artists (they would have input delay due to the smoothing they need either way) but very useful for osu!
- Big tablets are useless for osu! players as they typically only use a 5-15cm area while they are very useful for artists
I think the entire point of something like pompyboard is to make a tablet just for osu!, which doesn’t exist right now. Meanwhile for artists there is already a whole industry of tablets available for them
reply