[Proposal] Abstract plane geometry library for GUI projects

[Eliah-Lakhin]

Would be nice if someone take an initiative to implement a render agnostic, widget agnostic and layout model agnostic library that will be responsible to just compute geometry of some abstract set of objects layout in plane based on their shape attributes specified restrictions/interconnections.

[madwareru]

First: a library is always better than a framework (in that sense that it does not constraint anything in terms of architecture in the end product)

Second: I think we need to be more precise in terminology. It would be nice if the set of rules been defined more formally.

For example:

• render agnostic: there won't be any constraints on what graphics API user decides to use with a library
• widget agnostic: there won't be any constraints on what widget hierarchy user can achieve as a result
• layout model agnostic: to be honest, I don't understand at all what this means

[Ralith]

It's also not clear to me what this is asking for. If it's layout model agnostic, it must not be a layout lib (and we have a few of those already anyway), so what is it?

[zakarumych]

Sounds like you want a generic solver for set of inequalities.

[Eliah-Lakhin]

Thank you for your responses!

@madwareru

a library is always better than a framework

Good point, I put a fix.

layout model agnostic: to be honest, I don't understand at all what this means

It shouldn't enforce hierarchy between shapes, and the way constraints between shape attributes specified should be flexible enough to build, for example, CSS Flexbox layout model as well as CSS Table layout or iOS Autolayout model on top of them.

@zakarumych, @Ralith In a nutshell this is an inequality solver, and the library implementation could use one from the Rust crates under the hood. However, my hope that due to domain specific restrictions(the library is till intended to be used by GUI projects specifically) the end implementation could be simpler and maybe more efficient than just a general purpose inequality solver, and also more API-friendly for such project purposes as well. Like cgmath or nalgebra are linear algebra libs intended to be used by practical computer graphics projects, but they however not general purpose(in mathematics sense) multi dimensional linear algebra solvers.

The reason I raised this topic and the reason I raised it in Rust Gamedev specifically is that first I think it would be good if there would be a general generic basis library that could be used by many GUI projects under the hood such that they wouldn't have to reinvent the wheel from scratch each time they are making computations of specific widget set system and their layout model. And the second reason(which is more important to Game development) is that unless one is going to build a User Interface of the "office"-like ordinary Desktop applications, most of the current Rust GUI projects are almost useless for advanced game development projects due to a lack of look&feel customization capabilities and the way their widgets are enforced to be rendered and laying out on the screen.

Consider these two examples:

(Bioshock Infinite menu UI)

(Deus Ex in game UI)

Hard to imaging one can render something like that using a library like egui, conrod or azule. The user interface examples above are rendering in 3D space driven by already built game engines and have very stylized set of widgets and specific user interaction behavior. So if the game developer is going to implement a video game user interface like the one above, one probably have to do it more or less from scratch. And the general purpose layout solving library that I proposed in this Issue topic could be handy too.

[zakarumych]

I guess UIs on screenshots above have pretty much fixed layout. It's not like they need to adapt to particular sizes and dynamically appearing and disappearing widgets like application UIs do.
In that sense in-game GUI layouting is simple, especially when they are rendered into 3d scene.

[Eliah-Lakhin]

@zakarumych Even if the layout is fixed it's not so bad idea to have an automatic way to (pre-)compute this layout. Also the game could be run in window mode as well as in full-screen mode with different screen resolutions. In this case adaptive("responsive") design might still be relevant even for the games that are rendering UI into 3d scenes.

[zakarumych]

Size of the in-game monitor does not depend on resolution in which game is rendered.

[Ralith]

You might be interested in https://github.com/dylanede/cassowary-rs.

[Eliah-Lakhin]

@Ralith Thank you. I didn't know about this project, but it looks close to something I was trying to explain, yes. Not sure if it could become a basis for the vast majority of the end GUI frameworks in the Rust ecosystem as I was thinking of, but anyway I like their approach.

Anyway, I hope the topic I raised in the Working Group could be helpful and maybe it would initiate a new work towards implementation of the generalized basis for the Rust GUI projects in the future.

[Eliah-Lakhin]

@ozkriff Do you think we should keep the Issue open? Maybe label the thread as long-term-goal to keep/continue discussion in the future?

[Eliah-Lakhin]

I have published a follow-up article on this topic, elaborating on the problem in more detail.