label: add relative values for font_size

[NotLebedev]

This adds ability to use relative sizing for font_size of label widget. It's really useful to use % to position and size widgets across displays with different resolutions, however such functionality is lacking in font_size. Added vh and vw suffixes to size text proportionally to viewport height and width respectively. This functions the same as in css. Also I picked vw and vh instead of % because in css it is defined as "relative to parent objects" font size and in hyprlock there is no parent object font size, so this would be just confusing whichever way it is implemented.

Examples in action (sorry for photos of screen, didn't figure out how to screenshot):
4K screen before (config was created for it):

4K screen after (changed all values in config to vh):

1080p screen before:

1080p screen after:

P.S. thanks for this awesome piece of software. Works like a charm!

[PointerDilemma]

Looks exactly like what I initially intended for label size to be output relative.

However, there is also #591,
which essentially solves the same problem, but not via the font_size option.
Have to looked at that?

That pr makes you configure sizex instead of font_size and also addresses the image widget.
Let me know what you think, I think both solutions are OK.

I will test this later.

[PointerDilemma]

@Memoraike, since you commented on the other PR, which solution would you prefer?

[Memoraike]

@Memoraike, since you commented on the other PR, which solution would you prefer?

I prefer #591, it's more flexible and perfectly solves the problem I faced when developing complex CLabel based widgets.

[NotLebedev]

However, there is also #591,
which essentially solves the same problem, but not via the font_size option.
Have to looked at that?

Didn't realize that MR implemented ~ the same thing. Name is kinda not obvious.
Biased, but I kinda like my approach better because

1. vh, vw is a well known unit used everywhere css or some resembling stuff is used.
2. vh vw allows to size both relative to width and height, sizex is only relative to width, if I understand correctly.
3. It is kinda unrelated to sizex. One can do sizex: 10, sizex: 10vw and sizex: 10vh which all mean different things and this way it is more flexible
   Adding vh vw to image:sizex seems trivial

[NotLebedev]

Illustration for point 3.

[NotLebedev]

Also sizex does not work the same as font_size because if there is more text in label with fixed sizex font size shrinks? E.g. in my screenshots on "Monday, May 05" date text will be bigger then on "Monday, September 01"?

[PointerDilemma]

Sorry for not responding earlier.

Actually like you said in point 3, you are right that this is not really the same as sizex.

I would propose to get the PR for sizex merged fist, which will allow to specify the size of Image and Label via relative units. Like mentioned in the PR if font_size for label is set, it will behave just like before.

Afterwards, we can adapt this PR and make font size and all size/position args support vh, vw. Currently % is relative to the side that it references. So pos=1%,1% is equivalent to pos=1vw,1vh . With that one could make everything relative to the monitor height for example and have font_size be accurate across monitors.

in my screenshots on "Monday, May 05" date text will be bigger then on "Monday, September 01"?

Yes that is 100% correct and an additional reason why we might want to have sizex AND vh/vw for font_size.

@NotLebedev does that work for you?

[NotLebedev]

Yeah. That is exactly what I wanted to accomplish. I will update this PR when the other one is ready

[jaredmontoya]

It's sad that this PR didn't make it into the recent release.

[NotLebedev]

Fell out of the loop, but I'm back. Sorry for the delay. I see that #591 was closed. I think this PR and what I may do in this direction needs to be reealuated. @PaideiaDilemma what's your current idea?

[PointerDilemma]

Sorry I am also not really in the loop on this one currently.

I closed #591, because I wasn't happy with the approach. Check out #555 (comment), where I described my alternative plan.
Currently working on some bugfixes and changes in the hyprland session-lock support.
Then I want to revision current suspend problems on nvidia.

If you have some time on your hand, feel free to pick up what I wrote in the comment I linked if you want (I also linked a commit). Otherwise I am afraid it will take a bit longer to do what was planed here.

[asiantuntija]

Just a gentle ping, would be nice to have this feature as I'm using the same hyprlock config across multiple machines. What you described in #555 comment looks usable at least.

[PointerDilemma]

I ran into a roadblock in terms of the configuration format.
Once this is merged, I will continue with the plan I mentioned in #555.
hyprwm/hyprlang#82

[jaredmontoya]

Tracking: related to #261