Resolve ~ and $HOME in icon_path

[zappolowski]

icon_path was used verbatim which doesn't resolve e.g. ~ or $HOME. As string_to_path already exists, we can use it for the resolution here as well.

This fixes #1371.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 65.37%. Comparing base (c1cc6d1) to head (97510de).

Files with missing lines	Patch %	Lines
src/icon.c	0.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1383   +/-   ##
=======================================
  Coverage   65.37%   65.37%           
=======================================
  Files          50       50           
  Lines        8321     8321           
  Branches      999      999           
=======================================
  Hits         5440     5440           
  Misses       2881     2881           

Flag	Coverage Δ
unittests	65.37% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bynect]

ok for me. it works with multiple paths right?

what about using TYPE_PATH for icon_path tough?

[zappolowski]

it works with multiple paths right?

Yes, every path (separated by :) is processed on its own.

what about using TYPE_PATH for icon_path tough?

I don't think this would work, as TYPE_PATH is used for single argument which is then expanded. What might work instead would be the introduction of a new type e.g. named TYPE_PATH_ARRAY, which then could be processed on reading the configuration (opposed to expansion on usage like it's currently done).

[bynect]

well, I guess this is all right

[danielwerg]

@zappolowski works as expected!

---

On a side note, for some reason, this branch dunst (and master I assume) uses global.height as min height instead of max height (only expand when content size demands) unlike v1.11.0.
Is this intentional or should I open an issue?

[bynect]

@zappolowski works as expected!

On a side note, for some reason, this branch dunst (and master I assume) uses global.height as min height instead of max height (only expand when content size demands) unlike v1.11.0. Is this intentional or should I open an issue?

See #1342. Now global.height is a range. if you specify a single number the max = min and the size is fixed. Otherwise you can specify (min, max). Just like the width value