search

redox-os / orbtk

The Rust UI-Toolkit.
MIT License
3.78k stars 188 forks source link

Serializing/Deserializing widgets #290

Open uniformbuffer opened 4 years ago

uniformbuffer commented 4 years ago

Context

Hi, i'm developing a dnd-like managing app using Orbtk. The biggest part of this app is the Battlefield widget that is a basic 2d engine that use Orbtk widgets as drawing elements. I have also created a special ShapeWidget that is an Orbtk widget that draw a shape and at the same time have a physical shape that can interact with nphysics2d physic engine to get physic reaction from collisions and similar. Graphical components are drawn on layers, so that the user can decide which component should be drawn on top and what below. I'm also developing an editor that allow the user to create a map by setting an image as background and positioning obstacles on top. Everything placed on this map is represented by some Orbtk widget, so i need to find a way to save them, so i can save and load maps and all their content.

PS: I will soon share everything, i mentioned it as context.

Problem description & Solution

What i would like to do is to save the widgets as a whole, with all their property (and maybe state?). To do this i was thinking to serialize the widget iself, so that can be saved as ron and loaded by deserializing it. While thinking about serializing and deserializing widgets i have noticed that this could be a very useful and generally applicable feature. Think about the ability to load the Orbtk application from ron data instead of building it manually by code, allowing to load dynamically code. This is basically what GTK do with it's template base design, but using ron instead of xml. In future, thanks to this feature, could be possible to develop programs that graphically build Orbtk interfaces, similar to what Glade do for GTK.

Honestly i have no idea of the effort needed to develop such feature. Maybe is too soon to think about dynamically load code and similar. I don't know, i just shared a thought. What do you think?

Thanks for the attention, Have a good day

FloVanGH commented 4 years ago

PS: I will soon share everything, i mentioned it as context.

I'm looking forward ;-)

I'm working also on OrbGame a 2D game engine based on OrbTk. I think about to integrate the stuff of OrbGame in OrbTk and to make it available by a game cargo feature. I will soon do a survery on the redox chat about that topic. Maybe we could in this course integrate some of you widgets in OrbTk. What do you think?

What i would like to do is to save the widgets as a whole, with all their property (and maybe state?). To do this i was thinking to serialize the widget iself, so that can be saved as ron and loaded by deserializing it. While thinking about serializing and deserializing widgets i have noticed that this could be a very useful and generally applicable feature. Think about the ability to load the Orbtk application from ron data instead of building it manually by code, allowing to load dynamically code. This is basically what GTK do with it's template base design, but using ron instead of xml. In future, thanks to this feature, could be possible to develop programs that graphically build Orbtk interfaces, similar to what Glade do for GTK.

This is the second request for Serializing/Deserializing widgets in OrbTk. Someone on the redox chat is working on a xml parser for OrbTk UIs. I'm open for this topic.

uniformbuffer commented 4 years ago

I'm working also on OrbGame a 2D game engine based on OrbTk. I think about to integrate the stuff of OrbGame in OrbTk and to make it available by a game cargo feature.

I think it's a great idea. Since the game widgets are behind a cargo feature, they are not compiled unless the feature is used, so they do not affect compilation time for users that does not need game widget. At the same time a user could easily get all the game widget by simply setting a feature.

Maybe we could in this course integrate some of you widgets in OrbTk. What do you think?

Sure, I'm always happy to contribute. I'm still prototyping, but if you want i could load the code into a public repository so you can give a VERY VERY early look.