I know it requires the somewhat mysterious phantom Bluetooth/Wi-Fi connectivity that AirPlay/Airdrop use, so if I have disabled Bluetooth on my device, for example, it will no longer work. I have found a lot of utility with cross-device copy/paste. Maybe you meant something more specifically related to 3rd-party sniffing/modifying clipboard contents, but I haven’t really encountered that outside of apps such as CopyQ and Paste, and they are pretty explicit and intentional about their functions. I would think requiring opt-in for clipboard functionality would be the more radical option that would leave most users (myself included, I would imagine) scratching their heads when they can’t copy/paste as a matter of course. And all clipboard access attempts should probably get logged somewhere. They need to implement permissions that deny all apps the ability to get/set the clipboard by default, and have an option to ask the user whether so-and-so app can access the clipboard (outside of normal copy/paste), every time with the option to allow always. I have to say, this is one of the more disappointing developments from Apple, that they certainly must know by now about these clipboard shenanigans, but have done nothing to stop them. I just assume that everything is spying on my clipboard contents now, hoping to log secrets/passwords and PII to sell to scammers. On iOS it's more random, and I feel like it's probably Facebook doing it, or maybe websites in Safari. I even get a feel for it, like my mind detects the pattern that empties the clipboard so I sense when I can no longer paste, but I can't figure out concrete repeatable steps to make it happen. I usually notice it in apps like Sourcetree, where I'll click something or do a certain action and suddenly I can't paste anymore. I've noticed that more and more apps on both macOS and iOS sniff the clipboard contents and randomly clobber it. But if you can, it is the right thing to do. This meant that not only did we tweak the icons at the small sizes (in the example above for a track bar control, we don’t use the large size 128x one scaled down to 16x even though they are both built on a 16x grid) but that we used a different base grid for the 24x and 48x versions compared to all other sizes. We’ve gone through and tweaked the icons for each different pixel grid.” Similarly, shape edges should be snapped to the pixel grid for each size. Even if we support antialiasing, a 1-pixel-wide line looks much cleaner when it takes up one pixel in the image, rather than being approximated through antialiasing over several pixels, which makes it look blurry. An icon designed for 16×16 or 32×32 won’t resize and scale to look good at 24×24, because the pixel grid is different. TTrackBar is a good example of this: at each size, the small indicator marks are different. > “…notice that the icons are not simply the same image scaled up or down. I was lucky enough to oversee a project replacing seven hundred icons back in 2017, and we hand-adjusted the low resolution versions of 16x16 and 24x24. Incidentally, does anyone know enough about the way sips scales PNGs to confirm that it makes sense to create the 16px version straight from 1024px, as opposed to basing it off 32px (and all the way up)? I.e., is it better to downscale in fewer steps (as currently) or in smaller steps? icns file for your app from a single 1024 by 1024 PNG without any third party software:Ĭp Icon1024.png -z 16 16 Icon1024.png -out MyIcon.iconset/icon_16x16.png You can use sips together with iconutil to generate a complete.
0 kommentar(er)
