Need testers for Symphony 3.0

[vyrx-dev]

need some help testing symphony 3.0 on actual hardware (not VMs)

if you have a spare machine or disk and some time to spare, would appreciate it

[jacob-zawadzki]

I have a Lenovo IdeaPad laptop I can install it on and use for a while. Is there anything in particular you want tested, or just general usage/functionality?

[vyrx-dev]

hey jacob, thanks for offering to help!

quick question though - are you testing the 3.0 branch or main? i need 3.0 tested on actual hardware since we changed how some stuff works under the hood. just want to verify the install works, cli commands work, and updates don't break anything.

let me know!

[jacob-zawadzki]

On my desktop I'm using main, but I went ahead wiped the drive on my laptop, did a fresh install of Arch, and pulled down the symphony-3.0 branch for testing. Theres a couple things I noticed right away.

• In the initial installation scripts, the set -e doesnt carry over from the boot.sh or install.sh scripts. This causes the script to exit if an if statement returns a non-zero value
  Therefore it's necessary to add set -e to all the scripts under the install directory.

• The bin/first-run script was triggering on every boot if you use the reboot option due to the marker file not getting created before the system shut down. To fix this I moved lines that create the marker file to the install/themes/install.sh script to ensure the file gets created and the first-run script won't loop

• removed spicetify-cli from the package list as it failed to build and install, causing the entire install script to exit. This of course is not a bug in this project, its a problem with the AUR pkgbuild. The maintainer is aware of the issue and it might already be fixed, I haven't checked. But I did temporarily remove it, just to get the script to run completely.

• Migrated the wallpaper handling to awww like in the main branch

There's a few smaller things I changed that you may or may not want to actually implement.

• in the waybar network module, I changed the interface from wlan* to wl* since my network device actually shows up as wlp1s0. And setting it wl* should work with devices named wlan or wlp

• on every boot, the idle-lock indicator would show up in waybar, even if it was disabled. This was because the idle-indicator script was checking if hypridle was active before hypridle actually had a chance to start. To fix this, I added an if statement that checks for a marker file. If the marker file doesn't exist, it will sleep for 2 seconds to give hypridle a chance to start and create the marker file, so that every time the script is called after the first time, it functions as normal.

• in the symphony-tui script, I changed the fzf-previewer section in the browse function to use kitty's icat instead of chafa. This is because with chafa, the previous image would not get cleared from the buffer, and the new image would just get overlayed on top of it. This wouldn't be a problem if all the images were the same size, but because they aren't, you can see the edges of images that are bigger, underneath the one you're currently viewing. icat has a built in clear function to clear the last image from the buffer before displaying the new one.

You can view all of these commits in my fork of the symphony-3.0 branch and see if the changes are something you would like to merge into your branch.

[jacob-zawadzki]

Update: Found a few other small issues.

• added source-color-index=0 parameter to matugen in the selectWall and change-theme scripts
• changed the matugen output paths in config/matugen/config.toml, they were outputting to a redundant nested .config directory
• The README says that symphony switch -r will apply a random theme but the short -r flag did not actually exist in the script, only the long --random flag. I added the short -r flag.

I haven't fully tested any of these changes but so far, I haven't found any other issues.

[vyrx-dev]

hey jacob, thanks so much for testing and finding all those issues. honestly it's been pretty rough working on such a big pr alone so really appreciate the help.

would you be cool with me assigning pr #45 to you? i'm kinda swamped with other projects right now but i'll still help out with this one. if you're up for it, you can open a pr from your fork targeting the symphony-3.0 branch with your fixes and we can get them merged in. then if you find more stuff just keep doing the same thing.

let me know if that works for you!

[vyrx-dev]

btw quick question - i originally liked using stow for the simplicity but switched to native copying because people kept running into symlink issues and conflicts. do you think the current copy-based approach is better or should we go back to stow? just want to get your take on it

[jacob-zawadzki]

@vyrx-dev I don't mind if you assign the PR to me, but just so you're aware, I'm not a developer, I'm an auto mechanic by trade so I'm still kind of figuring out how the github workflow works. There's a couple things I changed in my branch just for testing purposes, so once I changed those back, I will open a PR to merge into your symphony-3.0 branch

btw quick question - i originally liked using stow for the simplicity but switched to native copying because people kept running into symlink issues and conflicts. do you think the current copy-based approach is better or should we go back to stow? just want to get your take on it

Personally, I prefer stow because of, like you said, the simplicity, and also having everything centralized. It's nice to be able to work completely within the ~/symphony directory and push changes to a personal dotfiles repository to be able to clone on other machines.

[vyrx-dev]

don't worry about that though, this pr looks good

[Ltony2022]

hello, the dotfiles may need to handle awww as well because the swww had been renamed to awww. I ran this setup on arch and swww broke after recent update

[vyrx-dev]

hello, the dotfiles may need to handle awww as well because the swww had been renamed to awww. I ran this setup on arch and swww broke after recent update

Already been fixed by @jacob-zawadzki