Move `.width(…)` and `.height(…)` into `ui.element()`

[twilit-jack]

Summary

Looking for feedback about moving the .width(…) and .height(…) methods directly into .ui.element().

Motivation

.width(…) and .height(…) are two of the most frequently seen methods in a Ply codebase. Almost every element has them. And omitting them is a bit unclear on functionality (I believe the default is fit-sizing, though this seems more like an implementation detail rather than something to rely on, and is a bit unclear to the reader anyway).

Furthermore, rustfmt formats long method chains vertically, and .width(…) and .height(…) takes up two extra lines. And if our brains might want to do something like ui.element().width(…).height(…) on one line, but rustfmt won't exactly allow that. And turning off rustfmt for this one single thing has in my experience been not worth it.

And both of the properties mostly show up in the same order, or at least, it's clearer if they do. So why not get rid of the .width and .height parts and inline them directly in the ui.element() method?

Proposed API

ui.element(fixed!(180), grow!()) // Sizing defined inline here
	.background_color(0xaaa0be) // Rest of the methods continuing down here
	.layout(|l| l.direction(TopToBottom))
	.children(|ui| {
		ui.text("My cool sidebar without any buttons", |t| t.font_size(14).color(0xffffff));
	});

// Currently it would be this long method chain
ui.element()
	.width(fixed!(180))
	.height(grow!())
	.background_color(0xaaa0be)
	.layout(|l| l.direction(TopToBottom))
	.children(|ui| {
		ui.text("My cool sidebar without any buttons", |t| t.font_size(14).color(0xffffff));
	});

// Or this workaround while disabling rustfmt
ui.element().width(fixed!(180)).height(grow!())
	.background_color(0xaaa0be)
	.layout(|l| l.direction(TopToBottom))
	.children(|ui| {
		ui.text("My cool sidebar without any buttons", |t| t.font_size(14).color(0xffffff));
	});

Notes

• This is just looking for feedback. I see a few reasons why someone might not want this (e.g. being a slight bit opaque to people looking at the lib for the first time, though this one is a bit of a minor concern in my opinion).
• I was unsure how to label this issue, I just went for copying the feature request template (though this isn't a feature per se), and putting this as an idea.

[TheRedDeveloper]

Sadly, I'll have to say no. It's just not how I like my sizing to be defined. Did you know they default to fit!()? Pretty cool huh.

[TheRedDeveloper]

Oh actually you make a good point about the "though this seems more like an implementation detail rather than something to rely on", I might think about it. I guess most people don't know the default is fit and they are not sure they can rely on that. But it does say that in the documentation. Whatever. I've been up for 24h pushing out ply-locales.

[twilit-jack]

No worries, do whatever you want to do. But the bit of boilerplate does slightly pinch. Even if the default is fit, and that works for elements that need fit, it still has the boilerplate for elements that need any different sizing strategy.

[twilit-jack]

Also, a bit of a status update on my situation (if it interests you).

Just figured out a good system for CDNZ – the format Cadenzier uses – and I'm now going to work on the GUI again. I have a couple of ideas for the workflow I want to achieve (a bit different from what I currently have in crate::gui::editor). I'm thinking about going more keyboard-driven, and putting data first instead of toolbars and menu bars (which can be keybinds instead).

And also, I think Cadenzier might be able to actually make, edit, and open files soon. Not yet music data, and not yet seeing music data, but at least editing metadata and setting up the structure of a project.

And I'm also quite excited about Ply 1.2, and in the general direction Ply is going in. It seems like I have found the Rust GUI lib for me.

[TheRedDeveloper]

The "odd default values" is apparently one of the most frequent critiques. People seem to not like that they can leave their element unspecified, and it will be fit!(). Maybe we should put the font size and color into ui.text() too... I think that would actually somehow circumvent the problem of choosing defaults by just not having any defaults. I like this!

[twilit-jack]

Actually, yeah! I frequently forget about specifying font size and colour in ui.text(), so an immediate demand of them in the paramaters would also be a good way to mitigate that.