It's done through a similar mechanism, you can paste the URL of a user on a different Mastodon search which triggers the same style of search as it does on Lemmy. Mastodon has relays (an admin needs to add/subscribe to one, and the relay has to confirm/accept) however which can also help "kickstart" Federation so to speak as well - which is like blasting a firehose at an instance.
russjr08
joined 2 years ago
Sure, like I said, it's not impossible as it currently stands. Source availability makes it easier for people who want to say, push ads into it (or even malicious code) their "own" app name though.
One thing the dev mentioned in their comments was that they wanted to keep control over where/how the app is distributed - unfortunately making it source available still makes it so people can go and publish it elsewhere.
Which is not to say that it's impossible as it currently is, but it would make it easier.
(Even if the license disallows it, plenty of people don't listen to licenses)
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).
Oh this looks fantastic! I will be deploying this to all of my systems immediately haha!
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).
Honestly now I am curious if there is a CLI equivalent. I always end up using tar's t flag or opening a zip in vim to see if it has a subfolder as my current workaround...
That's perfectly fair! I always seem to have a 50/50 coin toss of whether there will be a folder inside the archive or not.
I think if things were more consistent for what I end up having, I wouldn't mind it if archives didn't have a folder or if they always had a folder, rather than the current state.
I suppose in your case, it would be cool if there were a config option to make this do the reverse, unpack the files within the subdirectory of the archive to your current directory.
It would be nice if it were at least configurable to set as the default extract option. If I had to take a guess, it'd be that it's not the default option because the amount of single files before needing a subfolder could vary between different people. Some folks may want only one, and others may be fine if it goes up to say 3. However, I suppose that could also just be a configurable option.
That being said, I've at the very least developed the muscle memory to always click that option no matter what. I can't tell by your comment if you weren't aware of the feature, but if not then hopefully it can be of use to you moving forward as well!
Oh I didn't even notice my instance had made it onto the "All" section there, that's pretty cool!