Have we found a good UI paradigm to fit inside Ply?

[twilit-jack]

I'm at a bit of a wall with my current component system. Not really sure how to proceed. Main pain points have been:

• A signal/callback system, or a good way of getting a child component (state struct) to talk to its parent. No idea how to do this, I've thought of a few ideas, but nothing elegant.
• A config system. I'm trying to avoid plainly passing them down through the view methods of components, as that would probably lead to argument boilerplate hell, but a OnceCell<RwLock<Config>> static also isn't doing the trick.
• A theming/colour palette system. Not sure how to integrate it with config, and not sure on how many colours and variants of colours (e.g. highlighted, disabled) I should have (but that's nothing a bit of trial and error can't fix, most of the load is on the first two problems).

Red Dev, you're making a game using Ply yourself, do you feel like maybe sharing some knowledge of some systems you've come up with? Is any help of the above problems to be expected from the Ply engine itself?

[twilit-jack]

I'm starting to think that the Rc<RefCell<>> system (which I've abandoned in favour of passing down dependencies in view instead of new) might've not been so bad after all… The ironic part is that I wanted to get off RefCell so that I could get the borrow checker on my side, and to avoid runtime panics, but now I'm fighting against the reference rules, and thinking about why exclusive mutable access to data is even needed. Why not give everything a good helping of shared mutable state? :D

[TheRedDeveloper]

Both FungalEconomics, a real-time strategy game about mycelial expansion, and Stratum, a turn-based strategy game, are available under the Ply Noncommercial License 1 on my GitHub. I don't have any fancy component system going on. Just plain functions, parameters and variables.

[twilit-jack]

I think games can get away with simple systems like these better than non-game apps. But I'm at least delighted to see that the code for these games is open, and I can take a peek.

I think I'll stick to Rc<RefCell> in the meantime. I didn't really have any problems with it, and it scaled well. I think I was mostly just afraid of naught.

[twilit-jack]

Finally came to a good-ish way to handle multiple root screens. Optional children work well. I also just went and ditched Rc<RefCell<>> for good, I think that basic references in view(...) are fine enough, and they don't have the Rc and RefCell overhead. A bit of my solution can be seen here.

Components are really nice for having section-specific state data. But I'm also using plain &mut Ui-accepting widget functions more, for things that are basically parts of a big section/component. But I'm also not sure whether calling them "components" would make much sense anymore. Probably not.

Also, signals! Finally found a good way to represent those. Basically:

// src/gui/settings.rs
#[derive(Debug, Default)]
pub struct Settings {
	// ...
	pub request_close: Option<()>, // This is a signal
}

// src/gui.rs
impl Cadenzier {
	// ...
	pub fn view(&mut self, ui: &mut Ui) {
		// ...
			// This! `.take()`ing the option if it's there, and doing something with it.
			if let Some(()) = settings.request_close.take() {
				self.settings = None;
			}
		// ...
	}
}

It's a pretty nifty way of bubbling up updates to the parent.

Anyway, I'm going to be taking a bit of a hiatus from the GUI, and work a bit on the project format. I like working concurrently like this, once something becomes boring and I don't want to work on it, I switch to a different part of the big task. No team required!

[TheRedDeveloper]

Why can the option not be a boolean... cuz what you call "signal" is just a boolean. But whatever works for you I guess.

[twilit-jack]

To fit in. I'm using other kinds of signals, which hold values (e.g. pub open_project: Option<Project> in src/gui/home.rs). And I just want uniformity. .-.

[twilit-jack]

Also, .take() is nice.

[twilit-jack]

This was a bit of a bad example, I'll admit. Here's that value-holding signal:

// src/gui/home.rs
#[derive(Debug, Default)]
pub struct Home {
	pub open_project: Option<Project>,
}

// src/gui.rs
impl Cadenzier {
	// ...
	pub fn view(&mut self, ui: &mut Ui) {
		// ...
		if let Some(project) = home.open_project.take() {
			match Editor::try_new(project) {
				Ok(editor) => self.editor = Some(editor),
				// TODO: Make this use error popup system once added
				Err(err) => eprintln!("Error: {err}"),
			}
		}
	}
}