search

PistonDevelopers / conrod

An easy-to-use, 2D GUI library written entirely in Rust.
Other
3.35k stars 296 forks source link

Less boilerplate #969

Open est31 opened 7 years ago

est31 commented 7 years ago

It would be really great to be able to make GUI based applications with less boilerplate than now.

Just compare this: https://github.com/PistonDevelopers/conrod/blob/master/examples/hello_world.rs

to this: https://github.com/redox-os/orbtk/blob/master/examples/list.rs

I appreciate if the main conrod API is intended to be kept as powerful and low level as it is, but then maybe some higher level crate could be created?

I don't really want to use orbtk as it depends on SDL.

mitchmindtree commented 7 years ago

I agree this would be really nice!

I think you're right - the best bet for approaching this with conrod at the moment would be to have a higher level crate that settles on one set of window and graphics backends. I think I'd personally go with winit + glium as they're pure rust, designed to inter-operate nicely and are simple to use. In sacrificing some of the "backend-agnostic-ness" and flexibility of conrod, a crate like this could focus on providing a much simpler, high-level API.

I've considered working on something like this, though what I have in mind is more of a general "creative coding" style framework along the lines of openFrameworks or Cinder rather than just GUI. Something where devs and artists do not have to worry about the low-level/backend choices and can just focus on making nice creative tools and apps together on top of a common set of gui, audio, video, CV and graphics tools. I've been holding off as some of the openFrameworks devs have been working on a new rust framework in private for quite a while and are planning on sharing it soon, so I'll probably look to focus my efforts on that.

Paluth commented 7 years ago

Would it be possible to port Relm (https://github.com/antoyo/relm) to Conrod? Relm sounds like the type of high level stuff you guys are talking about.

daboross commented 7 years ago

Looking at relm, it seems to be much more a retained mode GUI library than an immediate mode one like conrod is. Could definitely be used, but I don't think it's most effective abstraction.

karan-ta commented 7 years ago

@mitchmindtree - do you mean that conrod will stop being worked on soon and the new framework will be focussed on ? I am using conrod from months and so far am enjoying to code using it. :) Please let me know.

mitchmindtree commented 7 years ago

do you mean that conrod will stop being worked on soon and the new framework will be focussed on ?

@karan-ta I will continue to work on conrod either way. If I were to begin contributing to a framework along the lines of what was mentioned above, my hope is that I could contribute gui functionality based on conrod. If not, I'd likely continue to work on conrod anyway as I'm enjoying it and currently using it in multiple projects.

I am using conrod from months and so far am enjoying to code using it.

Great to hear!

karan-ta commented 7 years ago

Yessss!

Thanks. I love conrod. And would love to contribute soon.

Cheers, Karan

Paluth commented 7 years ago

@daboross I don`t know what retained mode means :(. Anyways, the idea would not be to rewrite conrod or something, just to make a high level, easy to use api on top of conrod. If people want to dig in they can use conrod, but if they just want to trow together a a gui, conrod can be a hassle. I would love to be able to create a gui with a few lines of code, something like tcl/tk provides. But to also have to ability to make custom, more complicated stuff when needed. I think qml is the benchmark for the type of stuff I'm talking about.

daboross commented 7 years ago

@Paluth Ah, by immediate mode I just mean it conrod you "create" each widget on every redraw, while in a retained mode GUI like relm or gtk, you create the widgets at the start of the program and then only update the existing state and create / destroy widgets when things change.

Conrod does have a retained state underneath, but almost all of the API is used as if you were creating the widget state independently each draw. Wrapping this in a library like relm, which has the completely different "retained" API surface would imho be almost as much more as completely rebuilding a new framework and would sacrifice one of the best parts of using conrod.

Conrod's API allows for super easy and logical state transitions just through running different code to construct the GUI, wrapping it in a retained API like relm would really just be an entirely different library.