A Map widget for egui: review needed

[Maximkaaa]

Hey, guys. I've been working lately into integrating Galileo map rendering engine into egui applications by creating a simple widget. And here is the usage example of the widget.

I'm not that fluent with egui so if someone would like to take a look at the code and give a suggestion or two on how to make it more eguily, I would greatly appreciate it.

In particular, I am not fond of the fact that the application state must explicitly store EguiMapState somewhere, especially considering the fact that this state cannot be serialized/deserialized. This makes storing/loading the state of the app trickier. But I could not figure out a good way to hide this implementation detail from the user. (e.g. egui storage also requires the state to be serializable AFAII)

[YgorSouza]

The way egui widget usually work is that they store their state in a hashmap inside the Context. Sometimes the methods to load and store the state are also made public, so users of the widget can also edit the state between frames for advanced behaviors. Here is an example from the ScrollArea:

egui/crates/egui/src/containers/scroll_area.rs

Lines 66 to 74 in 9936966

	impl State {
	pub fn load(ctx: &Context, id: Id) -> Option<Self> {
	ctx.data_mut(|d| d.get_persisted(id))
	}
	pub fn store(self, ctx: &Context, id: Id) {
	ctx.data_mut(|d| d.insert_persisted(id, self));
	}

Of course, each widget needs a unique Id to get its state. Often egui tries to make this transparent by getting the id from the UI, but if there is more than one widget of the same type in the same UI, the caller has to provide a unique id for each of them:

egui/crates/egui/src/containers/scroll_area.rs

Lines 313 to 318 in 9936966

	/// A source for the unique [`Id`], e.g. `.id_salt("second_scroll_area")` or `.id_salt(loop_index)`.
	#[inline]
	pub fn id_salt(mut self, id_salt: impl std::hash::Hash) -> Self {
	self.id_salt = Some(Id::new(id_salt));
	self
	}

When you use get_persisted, if the persistence feature of egui is enabled, the thing you're storing must be serializable, and then it gets persisted between sessions. Otherwise you can use get_temp, then your state only has to implement Clone (usually you'd just put it in an Arc). You can of course split your state into a part that is persisted and a part that isn't.