Wallpaper script brittleness #188

Open
opened 2020-07-23 11:42:30 -07:00 by jlin · 4 comments
jlin commented 2020-07-23 11:42:30 -07:00 (Migrated from github.com)

There are some known issues re our current wallpaper changer for dinobuildr. We use a pinned version of a set of scripts hosted at https://github.com/mozilla/macos-desktop/ , forked from upstream https://github.com/tech-otaku/macos-desktop

This issue is to collect known bugs and cases of fluke bugs so that we can find our next step for replacement and/or change of approach when it comes to setting wallpapers.

There are some known issues re our current wallpaper changer for dinobuildr. We use a pinned version of a set of scripts hosted at https://github.com/mozilla/macos-desktop/ , forked from upstream https://github.com/tech-otaku/macos-desktop This issue is to collect known bugs and cases of fluke bugs so that we can find our next step for replacement and/or change of approach when it comes to setting wallpapers.
jlin commented 2020-07-23 11:46:00 -07:00 (Migrated from github.com)

Known issue:

  • wallpaper script does not work in multi-monitor setups

  • even after the external monitor is detached, it will not proceed because there is an entry of a monitor having been attached at some point in time.

  • on testing vm's this can be bypassed with changing a variable in one of the preferences databases (I'll try to locate / find the exact change)

Known issue: - wallpaper script does not work in multi-monitor setups - even after the external monitor is detached, it will not proceed because there is an entry of a monitor having been attached at some point in time. - on testing vm's this can be bypassed with changing a variable in one of the preferences databases (I'll try to locate / find the exact change)
jlin commented 2020-07-23 11:48:28 -07:00 (Migrated from github.com)

Mystery/flaky issue that came up with https://github.com/mozilla/dinobuildr/pull/187 - on a VM in VMware running 10.15.5, @luciusbono had an issue where the wallpaper didn't change even though all files were being written correctly, and everything else seems set. On VirtualBox and on a physical computer, the wallpaper change did go through as designed. The PR was committed because it seemed like a fluke on a VM instance, but it points to the brittleness of the script.

see mozilla/dinobuildr@dc5a798e55

Mystery/flaky issue that came up with https://github.com/mozilla/dinobuildr/pull/187 - on a VM in VMware running 10.15.5, @luciusbono had an issue where the wallpaper didn't change even though all files were being written correctly, and everything else seems set. On VirtualBox and on a physical computer, the wallpaper change did go through as designed. The PR was committed because it seemed like a fluke on a VM instance, but it points to the brittleness of the script. see https://github.com/mozilla/dinobuildr/commit/dc5a798e551652d4d15c0da902236fad2ac4d981
data-sync-user commented 2021-10-05 15:59:44 -07:00 (Migrated from github.com)

Known issue:

* wallpaper script does not work in multi-monitor setups

* even after the external monitor is detached, it will not proceed because there is an entry of a monitor having been attached at some point in time.

* on testing vm's this can be bypassed with changing a variable in one of the preferences databases (I'll try to locate / find the exact change)

Hi @jlin Were you able to determine the variable to change in the preference databases, and can we implement a way to fix it in instances where multi-monitor setup is used by mistake during running of dinobuildr?

> Known issue: > > * wallpaper script does not work in multi-monitor setups > > * even after the external monitor is detached, it will not proceed because there is an entry of a monitor having been attached at some point in time. > > * on testing vm's this can be bypassed with changing a variable in one of the preferences databases (I'll try to locate / find the exact change) Hi @jlin Were you able to determine the variable to change in the preference databases, and can we implement a way to fix it in instances where multi-monitor setup is used by mistake during running of dinobuildr?
jlin commented 2021-10-06 06:43:44 -07:00 (Migrated from github.com)

Yes, the multi-display and multi-"space" entries are in $HOME/Library/Application Support/Dock/desktoppicture.db

using sqlite we can remove the extra entries in the "display" and "spaces" tables. I don't have a script ready to do this, in my testing hardware I've been browsing the sqite db using a gui to examine the database and remove the entries as needed.

The relevant code is in

jlin/macos-desktop@81fb52052c/set-desktop.sh (L157)

and

jlin/macos-desktop@81fb52052c/set-desktop.sh (L163)

for the fix, since we are using this script on "new" computers we can simply add something that will remove the extra lines (the upstream software doesn't do this because they don't know if the 2nd monitors are important, but for us, we know that in our use case the 2nd monitor isn't really being used yet, since the users are most likely getting the computer fresh from manufacturer)

Can run through these details in Thursday 7 Oct 2021 meeting with team - and perhaps put in fix if someone is willing to help me test.

Yes, the multi-display and multi-"space" entries are in $HOME/Library/Application Support/Dock/desktoppicture.db using sqlite we can remove the extra entries in the "display" and "spaces" tables. I don't have a script ready to do this, in my testing hardware I've been browsing the sqite db using a gui to examine the database and remove the entries as needed. The relevant code is in https://github.com/jlin/macos-desktop/blob/81fb52052cb13480ce49258a70821a0b387cfafb/set-desktop.sh#L157 and https://github.com/jlin/macos-desktop/blob/81fb52052cb13480ce49258a70821a0b387cfafb/set-desktop.sh#L163 for the fix, since we are using this script on "new" computers we can simply add something that will remove the extra lines (the upstream software doesn't do this because they don't know if the 2nd monitors are important, but for us, we know that in our use case the 2nd monitor isn't really being used yet, since the users are most likely getting the computer fresh from manufacturer) Can run through these details in Thursday 7 Oct 2021 meeting with team - and perhaps put in fix if someone is willing to help me test.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jlin/dinobuildr#188
No description provided.