For me, using -depth was the simplest solution to reduce the arg length. I was dealing with deep directory structures and thousands of files, thus ran into shell limits (ie, zsh: argument list too long: find). The find command's -maxdepth arg in this example relates to subdirectory traversal. (At some point in here I may also have wiped OSX's $, but IIRC that was not relevant to getting imageoptim-cli to trigger JPEGmini 1.8.7 via the -j arg.) name '*.jpg' -type f -maxdepth 5 | imageoptim -j
Clear the imageoptim cache: 'rm -rf ~/Library/Caches/ImageOptimResults.db`. Steps after unsuccessful attempts with 1.9.0 and installing 1.8.7: JPEGmini v1.8.7 (not v1.9.0 which has a disabled "File > Open" menu item). Yes, I was able to avoid the "can't get sheet" error with the following setup:. Something like 27,000 images means it won't finish anytime soon. So, I moved this file out of ~/Library/Caches and - once more into the breach - ran "ImageOptim: Results cache is in /Users/cweekly/Library/Caches/ImageOptimResults.db" so I kept looking in the console log, till I finally noticed this hiding in plain sight: Googled "imageoptim how to flush cache", and the 3rd result was ImageOptim/ImageOptim#65 - confirming others have wanted this cache flush option, and that it's not supported by the tool. JPEGmini makes a huge difference, and I am 100% sure I want imageoptim to forget about its past runs and simply start over. If not, hopefully a quick note in the docs will help others? Or maybe they will find this issue's comment thread. So this is a friendly / grateful vote in favor of supporting a "flush cache - yes I'm sure" kind of option in the api, IF you've got time / inclination to do so. I totally get the concept of diminishing returns (and necessity of stopping in finite time, and trying to protect users from setting up dumb workflows) but when there's a real dependency on a 3rd party tool, accounting for breakage is necessary, to avoid this clippy-like "helpfulness". But in this case, because JPEGmini didn't get a chance to do its thing, the "already been chewed" heuristic is inappropriate. Normally this is a sane / helpful aspect to ImageOptim. foo.jpg, because it has been optimized before." "ImageOptim: Skipping /private/var/folders/./imageoptim-cli/jpg/. I looked again at the console's system log (/Applications/Utilities/Console.app) to see what imageoptim was logging (after it had given up on jpegmini lossy pre-processing per its premature exit). the Universe is smiling on me right now!).Ĭonfirmed: JPEGmini v1.9.0 disabled the File > Open menu, which may be responsible for breaking the current imageoptim-cli scripting mechanism.Īgain per Paul, JPEGmini v1.8.7 doesn't have this issue, and he even provided this convenient DL link:īut, using 1.8.7, I still ran into the "can't get sheet 1 of window 1" problem. Now: Thank you so much, Paul "Serendipity_" Treny (_you posted this crucial info just SIX HOURS AGO. webapp.war/img -name '*.jpg' | imageoptim -jįirst: ImageOptim-CLI is a great tool. Going through grunt (via grunt-imageoptim) was getting in the way of my debugging, so I have been using npm directly, egįind. Same issue - but I think I've just resolved it! TL DR: rm -rf ~/Library/Caches/ImageOptimResults.db (and use JPEGmini v1.8.7 - NOT 1.9.0). 
I'm not sure my issue is the same as 's anymore, downloaded the last version prior to 1.9.0 (1.8.7) and the File > Open… menu is still enabled, so the change happened in 1.9.0 👎)ĭrag and drop of an image file onto JPEGmini works, and clicking the yellow CHOOSE button works, but the ( ⌘O) hotkey support seems to be no more, at least unless the developer changes it back. I'd love to believe it's a bug, but I imagine it's more likely an intentional act by the JPEGmini developers, specifically designed to break the automation that imageoptim-cli offers, in a misguided attempt to drive users to their JPEGmini Server subscription service ($199/month). imageoptim-cli relies on this hotkey existing when automating the image file selection process ( line 106), and I imagine it will be difficult to script it to work (you'll have to move the mouse manually to the yellow CHOOSE button) This dropdown existed in past versions, but does not exist in any version of JPEGmini lite, normal or pro, I tested version 1.9.0. It looks to me like the JPEGmini developers have disabled the the File > Open… menu dropdown, which in turn disables the hotkey ( ⌘O ). imageoptim-cli/bin/imageOptimAppleScriptLib:3009:3085: execution error: System Events got an error: Can’t get sheet 1 of window 1 of process "JPEGmini Pro". I suspect it is the same problem I am now facing, however.
If you can, you should include the text before the execution error, it will help to pinpoint which line of the code is causing the issue.
0 kommentar(er)
