Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Gerald E Butler
    @gbutler69
    Hello all
    Matthias Tellen
    @madmalik
    hi o/
    Gerald E Butler
    @gbutler69
    There are 3 things I know of which should be looked at as a starting point for these discussions: Servo WebRender, Conrod, and OrbTK (from Redox).
    The Redox community has been making some pretty big strides on teasing out what a Rust GUI TK should look like.
    Matthias Tellen
    @madmalik
    @gbutler69 i just glanced over into the orbtk code. it seems to be pretty much based on callbacks. is that correct?
    Gerald E Butler
    @gbutler69
    Yes, as far as I know currently, but, there are a lot of ongoing discussions about where they are taking it.
    Gerald E Butler
    @gbutler69
    I agree that "Callbacks" are probably not the right ultimate answer though.
    That's why I mentioned Conrod.
    Matthias Tellen
    @madmalik
    conrod basically has a game-like event loop and leaves everything else to the user, is that right?
    Matthias Tellen
    @madmalik
    thanks!
    Gerald E Butler
    @gbutler69
    Yes, sort of. I'd liken it to input events updating the model and then at regular frame intervals the state of the GUI widgets are updated from changes to the model and then the entire GUI is repainted (at least logically).
    I think a design like this decouples the application logic and model from the rendering of the UI in a much cleaner fashion that traditional UI frameworks.
    Also, with modern rendering through the GPU, it takes more time (usually) to figure out expose events and what needs to be repainted than just repainting and compositing everything (or so Servo has seemed to have discovered).
    Matthias Tellen
    @madmalik
    and it's much simpler conceptually (even if incremental changes would be faster, state diffing und updating could be an implementation detail under the hood)
    Gerald E Butler
    @gbutler69
    Yes, I believe that is exactly what conrod is doing under-the-hood.
    Matthias Tellen
    @madmalik
    so, just to understand that properly. a text field in conrod is just a pretty box plus a &str. The actually owned string lives somewhere in the application model. editing the text box sends an insert event, the eventloop matches on that, change the String that the text fields &str points to und somewhere later on a new frame the text field is repainted
    Gerald E Butler
    @gbutler69
    Also, I think this sort of de-coupling will largely solve issues like, "How to handle I18n and Accessibility" as those crates/libraries could be developed independent of the UI and could even be designed to work with text input at the command-line (readline like) and/or text widgets (ncurses/forms-like).
    This spreads out that sort of development responsibility better in the Rust community.
    Yes, I believe your understanding of Conrod is correct.
    Though, to be clear, I'm not an expert on Conrod. It is just something I've come across in looking into what was already in progress/existing that seems promising.
    Matthias Tellen
    @madmalik
    mhh, i must say, i like the model in principle, but couldn't that lead to another kind of tight coupling between application logic and ui, if all UI state has to be handled explicitly in the model?
    Gerald E Butler
    @gbutler69
    Multiple "Models" in an applicaiton: UI Model, Business/Logic Model, Persistence Model, etc.
    Matthias Tellen
    @madmalik
    ok, that makes sense
    Gerald E Butler
    @gbutler69
    You can think of is this way: (Input Events - KB/Mouse/etc) => Input Event Logic => Update UI Model
    Every "Frame" current state of UI Model read and UI representation updated.
    Painting of UI and compositing handled separately every frame (by framework).
    Certain updates/changes to the UI Model cause logic to run to update the Business/Application Model.
    (basically messages/events from UI Model => Business/Application Logic)
    Business/Application Model Changes may send events/messages back to UI Model
    Business/Application Model Changes may send events/messages to persistence Model (or other Models) etc.
    This is very much the "n-tiered" design philosophy popularized in Web Applications, but, much faster and optimized locally.
    Matthias Tellen
    @madmalik
    sound very object oriented in the alan kay sense :D
    Gerald E Butler
    @gbutler69
    I guess it depends on how you look at it.
    It can also be thought of as very "functional".
    Matthias Tellen
    @madmalik
    it sounds like that would lead to a very composable system overall
    Gerald E Butler
    @gbutler69
    Every frame the current state of the UI model is passed to a function which yields and updated Business/Application Logic Model etc.
    Again, I think of WebRender, OrbTk, and Conrod (and there are probably some others) as starting points to look into "Pure Rust" GUI frameworks, not necessarily that the problem has been 100% solved (though as it is examined, it might be discovered that something like Conrod is pretty close to having it licked).
    Matthias Tellen
    @madmalik
    i never looked to closely into conrod because on it's focus on games, but i seem to have missed out ^^
    Gerald E Butler
    @gbutler69
    Yeah, I thought it was about games at first too, but, as I looked closer, I realized that that wasn't the case.
    Yes, it can be used for games, but, it can be used for anything (as long as there is a reasonably performant graphics stack behind it).
    Matthias Tellen
    @madmalik
    do you know anything about how it behaves in idle mode in respect to power consumption?
    Gerald E Butler
    @gbutler69
    No, I pretty much only know what I know from the docs. Haven't had time to play with it myself.
    I'd recommend inviting the author(s) to this discussion.
    Matthias Tellen
    @madmalik
    great idea
    Florian Blasius
    @FloVanGH
    Hi @all. Currently we working with a group of three people from my work on an update for OrbTk. We are one user experience designer and two ui developers (one Qt/Qml developer and one Qt/Qml + WPF developer). Our plan is to create a fast and easy to use pure Rust ui framework. We are strongly oriented towards https://reactjs.org/ and https://flutter.io/, because we think such an approach is good to implement with / for Rust. We've started with the planning and implementation last week.
    Noah Weninger
    @nwoeanhinnogaehr
    I think the tree-like approach OrbTk is well suited for Rust. It's a very similar design to what I coincidentally landed on for flow-synth. Basically I have the trait GuiComponent<Status> (essentially a widget) with a method fn handle(&mut self, event: Event) -> Status that allows children to return messages to their parents in response to events.
    Matthias Tellen
    @madmalik
    hi @FloVanGH and @nwoeanhinnogaehr
    (completely offtopic, flow-synth is very relevant to my interests :P)
    @FloVanGH does that mean OrbTk gets a completely new architecture?