Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Matthias Tellen
    @madmalik
    hi @frol and @gbutler69
    Matthias Tellen
    @madmalik
    the impl-period working groups used google docs for collaborating i think. Something similar could be useful for us too
    imo a simple etherpad would be sufficient and a little bit less headache
    Matthias Tellen
    @madmalik
    i just thrown a few points in there https://public.etherpad-mozilla.org/p/rust-gui-wg
    Vlad Frolov
    @frol

    not rely on native component

    When I think about reimplementing e.g. textarea with all its features (accessibility, right-to-left languages support, selection, navigation, etc) it freaks me out. I hope you know what you are doing as I have little experience with this level of GUI. As far as I understand, you need a canvas / window handler created by a "native framework" to be able to put a "native component" on it.

    Matthias Tellen
    @madmalik
    @frol that is actually a really good point... just for discussions sake, do you know how servo handles that?
    Vlad Frolov
    @frol
    @madmalik I have no idea how servo is implemented, but that is a great idea to check them out.
    Matthias Tellen
    @madmalik
    i more and more understand why electron just reuses chrome :D
    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?