nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c I see there is an option to copy an image's URL as well as open it in browser. Any chance you could add to the backlog an option to copy the image to the clipboard as well?
Discussion
What client are you using?
It’s Mike’s Gossip. But I literally use them all lol (both iOS/Android and Mac/Linux). And I send feedback/suggestions to each dev, for quality of life and feature requests.
0. Images start as a URL.
1. The 'Fetcher' then handles it and moves it through these states: Starting, CheckingCache, LoadingFromCache, Queued, Fetching, Ready, Taken, Failed. These states are so that subsequent calls to the Fetcher don't start over and fetch it yet-again. This consults a local file cache and then gets it from the network.
2. Then the media handler hashes the data and compares it to any file metadata that was specified to see if the hash matches what was expected.
3. Then it scales the image and converts SVGs into images and makes this result available for the UI as an RgbaImage.
4. The UI then takes the image and turns it into a UI-friendly ColorImage which is loaded to the GPU, and the UI remembers just a TextureHandle.
5. The UI can now draw it with the TextureHandle as needed. When the UI draws it, it also draws the menu that lets you copy the URL (which it remembered).
In order to add "Copy Image to Clipboard" there will need to be sigificant refactoring because you'll want the original bytes before the media handler scaled and converted the data for rendering purposes back in step 3, which the UI never sees currently (it is part of the lib media handler, which I admit is wrong) and also the UI dropped the bytes itself as soon as it got a TextureHandle (it never needed to keep the bytes so far, and keeping all the images might hog CPU-side memory unnecessarily).
I've added the code to the "unstable" branch but it isn't working for me. I can't tell if it is my desktop environment that doesn't copy/paste images, or if egui didn't fully implement it, or if I have a bug. If you could try it and report back it would help.
Will test this soon. I also wanted to know your thoughts on the placement of "Show New Updates" button. I have my gossip set to 1sec refresh and sometimes it doesn't recompute automatically in the feed and instead shows the button, but because the "Recomputing..." text pops up every sec it makes it hard to click the show updates text lol. Even when I changed refresh to a few sec more, it was hard to click the button. Perhaps, the button should be placed in a way where it shows in front of "recomputing.." text so if it does show the recomputing text doesn't interfere?
Hmm.
I have "recompute feed periodically" on (every 8 seconds. the default) and when something is new it gives a "Show new updates" link.
For me, recomputing happens so fast there usually isn't even a single frame where the text is printed.
I suppose if recomputing happens more frequently, and if it takes a long time to recompute, then having these rendered on top of each other would be bad. I've just never seen that myself.
Are you on an SSD?
On a m1 pro mac... but could test on my linux machine. here's a clip of what it looks like. https://file.nostrmedia.com/p/d49a9023a21dba1b3c8306ca369bf3243d8b44b8f0b6d1196607f7b0990fa8df/2312b1e220b685bfc6319f642e20042d198b515da2ed79f085683f16a2b6b272.mov
I can rearrange these so the link doesn't move. But I'd say there are multiple problems to be fixed.
You are following 416 people, that is reasonable, shouldn't be the reason recomputing takes so long.
I doubt this matters but:
Turn on Settings > UI > Show DEBUG statistics in sidebar. How big is "ES"? I'm at 1.1 million.
ES 34470
Ok I pushed a fix to unstable.