Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spotify: support --force-device-scale-factor for high-DPI displays #98350

Merged
merged 1 commit into from Sep 21, 2020

Conversation

9999years
Copy link
Contributor

Add a deviceScaleFactor argument to set the --force-device-scale-factor in the wrapper. If unset, nothing is added.

This allows e.g.

spotify.override { deviceScaleFactor = 1.66; }

for use with high-DPI displays.

Motivation for this change

Spotify's text is tiny by default on my monitor and I didn't know there was a way to fix it. I also want the --force-device-scale-factor argument to be the same every time i launch it, so adding an argument to the derivation seems like the best solution.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests) (N/A)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@9999years 9999years changed the title spotify: support --force-device-scale-factor spotify: support --force-device-scale-factor for high-DPI displays Sep 20, 2020
@timokau
Copy link
Member

timokau commented Sep 21, 2020

Thanks for taking the time to contribute! I'm not entirely sure this belongs into the package itself. Couldn't you just create a new wrapper in your configuration.nix?

@Ma27
Copy link
Member

Ma27 commented Sep 21, 2020

I'd be fine with adding such an option to a wrapper, however I'd advise against doing this in default.nix since this has the downside that you now have to rebuild the entire package just to change a value which isn't relevant at build-time.

Although rebuilding spotify isn't much of an effort, this is actually an anti-pattern IMHO.

A better solution would be to create a wrapper with symlinkJoin where you do this in a postBuild. Examples for this are e.g. rofi or rxvt-unicode.

If you need further assistance with this, feel free to ask :)

Add a Spotify wrapper with a `deviceScaleFactor` argument to set the
`--force-device-scale-factor` flag for high-DPI displays. If unset,
nothing is added.

This allows e.g.

   spotify.override { deviceScaleFactor = 1.66; }

Uses a separate wrapper derivation as suggested by @Ma27.
Uses `wrapProgram` instead of `makeWrapper` as suggested by @Ma27.
@ofborg ofborg bot requested a review from Ma27 September 21, 2020 18:43
@Ma27 Ma27 merged commit 2e98177 into NixOS:master Sep 21, 2020
@timokau
Copy link
Member

timokau commented Sep 28, 2020

This PR has introduced some inconveniencies:

Those could be fixed (maybe by not exposing -unwrapped in all-packages and moving meta to the wrapper).

Now slightly off-topic, but I'm still a bit unconvinced why we need a spotify specific wrapper in the first place. Wouldn't something like a library function for convenient, declarative wrapping be better?

environment.systemPackages = with pkgs; [
  (wrapbin spotify "/bin/spotify" "--force-device-scale-factor 42")
]

timokau added a commit to timokau/dotfiles that referenced this pull request Sep 28, 2020
Regarding the spotify-unwrapped unfree package:

NixOS/nixpkgs#98350 (comment)
@9999years 9999years deleted the spotify-device-scale-factor branch December 24, 2020 22:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants