-
Notifications
You must be signed in to change notification settings - Fork 237
[macOS][bug] changing the wallpaper restarts the Dock, which is annoying #70
Comments
Found the cause! We explicitly restart the Dock to (I think?) make OS X refresh the image. Since I have no idea about OS X, maybe the author of OS X support (@jcmiller11) might help us here. :) |
this may be a bit of a overkill, but maybe use wallpaper? it takes just one line to change the wallpaper, and does not need you to kill the Dock:
|
is there more than one I tried replacing that section with:
but the Dock still restarts. mysterious. |
No. It's even more mysterious for me as someone who never used a mac. :) I'll look for a Python module to set the wallpaper, or going to create one as a separate project. The current status seems like a bit of mess and that really bothers me. I thought about using appscript but it's abandoned. Making people install a node.js app for a 300 lines of Python script seems like an overkill. Thank you so much! I'm keeping this open, in case someone finds a solution. |
nevermind, fixed it:
works. you need to have wallpaper installed. |
Glad to hear! I'll keep the issue open though, for the problem is still not resolved. |
@sg-s @boramalper subprocess.call(["osascript", "-e", 'tell application "System Events"\n'
'set theDesktops to a reference to every desktop\n'
'repeat with aDesktop in theDesktops\n'
'set the picture of aDesktop to \"' + file_path + '"\nend repeat\nend tell'])
#subprocess.call(["killall", "Dock"])
subprocess.call(["wallpaper", file_path]) this can execute can every 10 mins. |
Thanks, but I'm strongly against using |
not sure why you're using the AppleScript in addition to wallpaper. To be clear, just this works:
|
@boramalper agreed; the simpler the better! |
Hey guys, was on vacation when this was happening! So as I commented when I added that line: The killing of the dock is to stop a problem where OS X would cache the wallpaper in RAM and not check to see if the picture file had changed given that it was using the same filename each time. It was kind of a hacky solution but it works. A more elegant solution might be to make the filename of the latest downloaded image be unique each time, I believe that would work, but I didn't pursue that method at the time because I didn't want to mess with too much of the non-platform specific stuff just to get OS X support up and going. @boramalper would you be opposed to using unique filenames in other platforms rather than just the filename-latest.png ? Also note, if you take a quick glance at how wallpaper does it, it seems to depend on a compiled binary written in objective-c: https://github.com/sindresorhus/macos-wallpaper which itself depends on Apple's Appkit. No clue whether this method also has the issue with multiple calls to the same filename not always updating. Edit: a quick search seems to suggest that the method that wallpaper uses also suffers from the same issue: http://stackoverflow.com/questions/34607809/redraw-desktop-background-without-restarting-dock-in-os-x That stack overflow question seems to suggest that using unique filenames will work... unless the user is currently in a fullscreen application when the update happens... which seems to just be a bug with OS X that should ideally be filed with Apple. |
It's been a long time since I touched all of this code, and it's all coming back to me solving this problem when I first added that killall line. We can add code to the main system to do something like timestamps for a unique filename to partially solve the problem of the picture update only working occasionally, but then we need to deal with a more complex cleanup system to remove them later... which only solves the problem if the user is not in full screen... or we can just kill the dock, which is also inconvenient... particularly if the user makes use of some window management systems in OS X like minimizing.... Kinda sucks but I couldn't find a perfect solution :/ so I just went with the scorched earth approach by just killing the process |
how bad would it be to use unique filenames on macOS? you could even use random file names -- i agree it is clunky but that seems to be the only reasonable way |
would have to add in some whole way to store the name of the last file to delete, destroying the simplicity of relying on each native filesystem to overwrite the file, would most easily be implemented outside of the environment specific code, still wouldn't totally solve the problem. I'll wait for @boramalper to weigh in on this |
I think we can append the date in the file name. Then we'll delete the last image, and save the new one. Since himawaripy is using appdirs to save images in its own dedicated directory, we can check if there is only one I'm really busy this week, but I'll try to implement it as soon as possible afterwards. :) Thank you all for your contribution! |
how about a cruder approach?
repeat |
@sg-s Why cruder? The only difference (checking whether there are more than one .png file to be deleted) is very very simple to implement (just checking the length of the results) yet can save us from a possible catastrophe. Given that how many things went wrong with this intended-to-be-small-script, I'm really hesitant of crude approaches. :) |
Agreed, any script that deletes a file should do so very judiciously as a small bug can be catastrophic, for example: MrMEEE/bumblebee-Old-and-abbandoned#123 Using a random name might necessitate an extra check for the very small chance of a collision lest one in a million updates fail to display for mac users, lol. I think @boramalper 's proposed solution is the best choice. |
This commit should resolve the issue. Can you confirm @sg-s? |
HI @boramalper, thanks! I think you forgot to remove this line:
in I removed it, and it looks like it's working! Awesome! |
@sg-s Fixed. Thank you all so much! |
problem is as described: when the wallpaper is reset, the Dock reloads, causing it to close and open, which is very distracting.
Surely there is a better way of changing the wallpaper than reloading the Dock/Finder?
The text was updated successfully, but these errors were encountered: