I hate how installing or removing (or even updating) a flatpak causes the whole software center to completely refresh, and it doesn’t keep its state so if you were in the middle of a search or scrolled down through a category… say goodbye to it.

They might’ve done so out of necessity. I don’t know if the dev(s) of the Simple Tools apps were working on it full time, but if they were and just not enough contributions were coming in from it… Well everyone has to eat.

As the saying goes, “everyone has their price”. It’s easy to condemn the developers for their choice until you’re in the exact same scenario as they were. Whether that’s because they were starving, or even just offered enough money to make their lives a lot easier - not too many people would turn it down.

Hmm, I can’t say I’ve seen that before. However, it might be worthwhile trying to just boot a live ISO of GNOME (or any other DE) just to rule out a KDE issue. Then if that doesn’t replicate the problem, try a live distro of something with a newer version of KDE (such as Fedora 39).

At the very least, that’ll help narrow down where the problem might be coming from!

I posted about this on the KDE community a couple of weeks ago, but Dolphin (their file manager) has a nice trick for archives (zips, tar’s, etc) - in the extract menu, there’s an “Extract, Autodetect Subfolder” button which will:

• If the archive has an inner subfolder (and just that), it will extract this as expected
• If the archive doesn’t have an inner subfolder, and all the files are at the root level, it will create a new folder for you and extract the files there

This way, you don’t end up with files splattered all over say, your downloads folder. Easily one of my favorite features, and is something I wish every File Manager had. It feels like someone had the same pain that I do (and I’m sure plenty others) of extracting something, and regretting it - but then they went as far as to fix the problem for everyone and implemented a feature for it (I’d love to have the knowledge to contribute to KDE someday)!

Yeah if it’s the comment chain that I think they’re referring to, I believe it came down to Mozilla “being in bed with Google” because Google is the default search engine.

I’ll take the default search engine being Google over things like affiliate links being hijacked, but maybe I’m crazy for taking that position.

Interesting, sounds like they’re killing the wakelock that Caffeinate acquires then (which is what actually keeps the screen active), rather than killing the whole app itself.

That’s another one of those issues that I don’t think there’s too many workarounds for. Theoretically I might be able to have the app check to see if the wakelock is still active and if not, re-acquire it… but if there’s no way for the app to “know” that the wakelock has been killed in the first place, the only way around it would be to constantly ask Android “Is the wakelock still active? Is the wakelock still active? Is the wakelock still active?” over and over again, which would definitely lead to battery issues.

I do know it works on some Samsung devices, as I bought an old A2… something to test it on, and couldn’t find any signs of a problem there.

I mean hell, I’d love for there to be a way to not even require a wakelock for Caffeinate, but the only other way is a “soft” wakelock, in which you tell Android “Never turn the screen off while my app’s window is open”, but of course that would mean you’d need to keep the actual app window in the foreground and would defeat the whole purpose (such as my favorite usecase, keeping the screen on while I’m reading a recipe - or keeping the screen on while I’m tracking a delivery from a food delivery application).

If you’re on an EFI based system and have systemd, you can use systemctl reboot --firmware-setup to get into BIOS!

Dark theming is definitely a fair point, I’ll definitely need to have a look into that.

Material You support is probably going to be out of scope though, as I feel that would be making it complex for the sake of being complex.

I do want to learn more about the Material You API that being said.

Well I definitely am glad to hear that! Yeah the situation is just unfortunate, as there’s really nothing I can do for the users who are getting the issue - since as you’ve seen, Caffeinate is already really light on RAM usage (which would normally be one of the only ways to try to remedy the issue as a developer, from what I can tell).

In the end I just decided to keep it compatible for all mobile devices, though I did consider adding a “compatibility warning” type of banner to the app or a one-time notification for devices that had a small amount of RAM. Eventually the emails stopped coming in about it though so I figured either the problem ended up resolving itself as updates to the platform occurred, or everyone who was going to run into the issue already ran into the issue. I’ve pretty much considered the app to be feature complete now, short of any Android changes that break it (such as when notification channels was introduced, followed by full-on notification runtime permission requirements).

I’m curious about what you mean by the issue with Android’s security model. Apps can have whatever package name they want (… Well, I am sure you can’t publish a com.google package on the Play Store) so that doesn’t make sense.

The only thing I can imagine you’re referring to is data sharing between applications signed with the same key, but that’s not the package name.

And you really don’t want it to either. That could cause all sorts of privacy issues if you accidentally include private information in the conversation - and as far as I have heard it is harder to remove information from LLMs than it is to “add” information to it.

Also Microsoft’s Tay could adapt itself based on conversations and that went real well…

Someone could’ve compromised the materials used to build the CPU, better assemble the atoms together one by one.

Maybe your bug report didn’t get collected into the other bug report, but it’ll be resolved for Plasma 6 thankfully!

Or AMD, apparently. The bug report for this issue was explicitly renamed to say “Non Intel GPUs” - even though it seemed to be more likely(?) to happen to Nvidia users.

As far as I understand, its the major push for moving forward with Wayland and dropping X11 as fast as possible yet Wayland still doesn’t work for a lot of workflows (say, making use of global hotkeys, or Nvidia users, etc).

Generally Plasma. I really like the look of Libadwaita applications, but the GNOME desktop is very much a “do it our way, or take a hike” - and some of the interactions that I’ve seen in the past between the GNOME group and others… well, lets just say whenever I see drama in the Linux community as of recently its always been either with GNOME or Wayland. That doesn’t necessarily instill a lot of confidence in me using either of those.

W

So what type of challenge do you get when it doesn’t think you’re human then?

It’s called “Caffeinate” (I’m avoiding posting the direct link just so I don’t break any self promotion rules), I made it in the Android 7 days when the quick settings Tile API came out to replicate the similar tile that was available in CyanogenMod. It ended up getting way more downloads than I ever expected honestly - I just wanted to try the new API haha.

I know that Caffeinate itself doesn’t use up a lot of RAM (the only thing it does when its active is create a persistent notification and creates a wakelock in order to keep the screen active), but perhaps the lower end Samsung device models just have less RAM available, so opening a browser or such kills it.

I don’t think it actually corrupted the SSD, perhaps a module is missing or such, and that’s why it goes into emergency mode. Have you tried mounting the drive from say, a live usb?