Does anyone else miss the functionality of the Android WhatsApp widget [1] on iOS? Being able to read messages without sending read receipts via the widget is a great feature. The iOS notification 'peek' is a clumsy substitute.
Is this a fundamental limitation of iOS widgets/APIs, or just something WhatsApp hasn't implemented? Curious if others have found better ways to handle this on iPhone.
The use case is slightly different. I prefer to send read receipts, but I also like to peek at messages without sending them and removing unread counts because I want to add the message to my mental queue, but don't want the false impression that I didn't bother to answer the said message.
Ah, you want to read messages without letting the recipient know you've read the message, while still having read receipts enabled. I'm not surprised WhatsApp does not support this one, I think they want their users to be able to trust the read receipt indicators
Actually it supports that, via notifications and peek. The intent is not nefarious, as I said before. I don't want the person who sent me the message think that I read their message and just tossed to a virtual bin.
I just did it yesterday. Somebody sent me a message, and I read it via notification, but they don't have the receipt yet. I'll write their answer with a fresh mind, and send the answer they deserve.
I don't think valuing the person on the other end of the line is a bad thing.
It looks like you're correct -- Gregglogger relies on pynput, and its behavior on macOS aligns with the library's documented limitations [1]:
Recent versions of macOS restrict monitoring of the keyboard for security reasons. For that reason, one of the following must be true:
- The process must run as root.
- Your application must be whitelisted under "Enable access for assistive devices." Note that this might require packaging your application, since otherwise the entire Python installation must be whitelisted.
- On macOS versions after Mojave, you may also need to whitelist your terminal application if running your script from a terminal.
I wonder if they'll index more repositories over time. As it stands, there's no clear way to tell what's indexed versus what's not. A transparent way to see the scope of coverage would be incredibly helpful for users.
As someone who's fascinated by formal verification and who's early in their career, what advice do senior folks who have been using TLA+ have?
TLA+ isn't taught in most universities and while I've read about so many interesting applications, I'm yet to convince myself that someone would hire me for knowing it rather than just teaching it to me on the job. Any tips to get started would also be appreciated!
There's very little tech that somebody is going to hire you for knowing. It's a tool like many others.
If nothing else, spending a few days playing with it will give you an idea of what it's good for and if you want to continue, or it'll make it stick in your mind so you can come back to it if you ever need it.
>There's very little tech that somebody is going to hire you for knowing. It's a tool like many others.
I guess this must be true on places like SF since I see this so often on HN, but almost every single job listing I've seen strictly requires knowledge of a specific tech stack, with the exception of a few internship programs.
There's tech that if it's not on your resume, you won't pass the first filter. But that's different. Knowing it will _not_ get you a job, it'll just get you past some early step.
But things like TLA+ are way different from even that. The number of programming jobs that will bin you if you don't have TLA+ on your resume has to be like, 5 in the world. Nobody is going to see it on there and be like "we _must_ hire this person!".
An example of a not-so-great URL design: Amazon product links have an optional slug before everything else like `{slug}/dp/{id}`. So you end up copying a gigantic URL everytime you wish to share a product unless you use the share product button to get the shortened link.
I think this is actually a really great design in that the name of the product can always be in the URL. The "slug" is completely ignored and just there for SEO/humans. If you send a link I instantly know what it's for -- that's pretty useful!
I also like that the "id" which is an ASIN (Amazon Standard Identification Number) which is a superset of all ISBNs. This means you can just enter any book ISBN directly into the browser and end up on the right page (at least historically) instead of having to search for it.
This got a major retailor (Walmart maybe?) into issues awhile back as they were pulling the product title (only) from this param so people were having a heyday "renaming" official products on the official site.
>>Amazon product links have an optional slug BEFORE everything else
>I think this is actually a really great design in that the name of the product can always be in the URL
he said "before". you could accomplish your goal putting the slug "after". he's making the point that having a place after which you can harmlessly delete the rest of the url is better than having embedded NOPs surrounded by identifying information (not that the average user will ever edit any url, but there is still merit in what he said that you missed, and he's not disagreeing with you)
While the slug helps someone know what they're opening before reading it, most apps have link previews which give you just enough information you need.
I dont know if I'm in the minority but I really dislike link previews the vast majority of the time. They take up too much space and offer to little value. In discord I often x out of the preview and I know lots of others who do too.
Maybe on some sites it's fine but I feel like link previews need more modularity on size or something. Perbaps even configurable both host and client
The information density of the preview has to match, if not exceed, that of the context in which it is provided. Most of the times it's a placeholder image with less text than the URL itself.
At least that stuff is actually informative to a human. A lot of Amazon's URL bloat is the analytics crap they shove into query string. I started using ClearURLs specifically because of Amazon.
If you're referring to the StackOverflow example from the article, it's different because they follow `/questions/:id/:slug`. Keeping slug at the end makes it a lot easier to delete while keeping it readable.
It is a curious decision why they chose to put the ID before the slug.
Stack Overflow, in contrast, puts the ID first, followed by an often very long slug. Which seems to be the more common pattern generally, as far as I can tell.
> So you end up copying a gigantic URL everytime you wish to share a product
Yeah, when I used Amazon I found this incredibly annoying. When I wanted to share a link, I'd have to spend a few minutes figuring out how much of that stuff I could remove and testing the resulting URL before sharing it. A relatively minor irritation, but an irritation nonetheless.
having, like you, studied amazon urls, I just automatically delete everything?inclusive after the "?", then I edit the slug to make it contain a message personalized for my recipient
reply