Adds winprop preferredWidth to set default window width by wm_class (supports 'px' or '%' values)

[jtaala]

Adds user configurable window property (settable in user.js for example) preferredWidth. This property allows setting an initial window width. Accepts a String value with unit px or % (e.g. "50%", "500px", etc).

See README.md changes in this PR for more details (under section Winprops).

This approach builds on / extends (and relates to) #304. I wouldn't say it fixes that PR(?) since it only addresses the width (and not the vertical height).
I'm going to say this fixes #304 since the discussion in that issue focuses on width (with some comments re height being tricky). Can create another issue for setting preferredHeight if there is appetite for that).

Thoughts and feedback welcome!

[jtaala]

@Gelbana @tadfisher @ccope @smichel17 - here's another quick fix to review when someone has time.

We could even combine this functionality into one winprop preferredWidth and have it handle both pixel or ratio values (e.g. if value is <= 1, treat as ratio).

Thoughts?

[smichel17]

I think combining them into one setting is a good idea.

From the user's perspective, I think it's a simpler interface. I would suggest defining it as a string.

This way, we keep the flexibility to add different units of measurement in the future, without complicating the interface further. The numerical behavior could be allowed but should be undocumented/undefined, since it would likely change if we added a new unit.

For the internal representation, it's easier to reason about when the property either exists or doesn't vs also having to handle the 3rd case of when both exist (this gets worse with additional units). The code itself isn't more complicated, but it increases the chance of some other part of the code accidentally depending on the order of priority, or something like that.

• For now, I think an internal representation as a number, with the fraction/pixel distinction you mentioned, is good. If more units are added, it would probably make sense to switch to an object with the shape { value: number, unit: string }.

• I would suggest parsing the user input to the internal representation as soon as it is defined (i.e. in the defwinprop function).

[jtaala]

@smichel17, yep, that makes a lot of sense. I hadn't considered other units, but yes that is a possibility.

If we make it a string input then there's really no reason why we can't parse units as part of that - e.g. like css 600px, or 4em etc. with the parsing like:

• if a unit is defined (e.g. 400px or 10em') then convert value into pixels (and normal >1 interpretation applies);
• if no unit is defined AND value is > 1 - treat as pixel value;
• else treat is as ratio value;

Do you think that might cover current (and future perceicable) use cases for this?

[smichel17]

• Just to be explicit (text is hard), I'm not suggesting you ought to actually add support for other units now. I mean, it's fine if you feel like it, but I think px and % will cover the vast majority of use cases.

• I think that sounds good. To nitpick, I could add the edge case: values below 0 are invalid and will be discarded. (edit: I'm talking about internal representation here. For external, I think officially only string values ending in px or % should be "officially" supported. Actually maybe it would be better not to support numeric values at all; people have a tendency to complain when things break even if they weren't supposed to work in the first place…).

• I don't think it covers all possible future use cases. That's a tall order. Fortunately, we can change the internal representation later if we need to, so covering all possible future use cases is not required. It doesn't even need to cover all present use cases; just the documented ones ;)

  • When I was retroactively trying to think of use cases to justify my gut-feeling that the width should be defined as a string, the one I came up with was something like a ratio, where the width would be based on the height (e.g. 8:5).

[jtaala]

Nitpicking is fine! (since I don't really like nits!). I agree though - I'll update external to support % and px and update documentation for this.

One thing though - you'll note a few other PRs like #456 and #454 do use standard notation for ratios (0.5 as opposed to 50%)... my undergrad was mathematics so I prefer standard notation for ratios (but then again, I'm biased there); but I do like the fact that px and % and string input is more akin to css's approach there.

Not sure what you think about consistency for those other PRs. Thoughts? (edit: at this stage, I'll just implement the changes there and we can discuss those other PRs when needed).

[smichel17]

I agree that consistency is good. I personally like standard notation. The "software engineer" part of my brain screams ONLY ALLOW ONE WAY TO DO IT AND MAKE UNITS EXPLICIT.

I'll sleep on it. As long as it's parsed to the internal representation right away, it's probably fine.
I think it's only a question of, "Is there a more useful thing we could do with numeric inputs later?"
It's easy to add support later; hard to remove it once people use it.

[jtaala]

Thanks @smichel17! See changes in latest commit in this PR.

Yes, this is a much cleaner approach. Currently accepting % or px units - anything else (or no unit) will not do anything and write a warning to extension log. Likewise for any value input <= 0 (or no value input given).

Please re-review.

P.S. I did end up going with an internal {value, unit} object structure that is processed in defwinprops - good suggestions!