Blog: Learn SixtyFPS - Memory Game Tutorial

[tronical]

This is the discussion thread for the second blog post Learn SixtyFPS: Memory Game Tutorial in Rust and C++.

[gondolyr]

I really enjoyed the Rust post that you two published!

I didn't deviate much from your example except reduce the amount of magic numbers used.

For example, in the MainWindow Window element; I added row_count and column_count properties to make it more readable and extensible.

MainWindow := Window {
    property <int> row_count: 4;
    property <int> column_count: 4;

    property <length> tile_size: 80px;
    property <length> tile_spacing: 5px;

    // Before: `width: 4 * tile_size + 5 * tile_spacing;`.
    width: (column_count * tile_size) + (tile_spacing * (column_count + 1));
    height: (row_count * tile_size) + (tile_spacing * (row_count + 1));

    // ...
}

For the right curtain, I utilized the rectangle's border-radius property rather than hard-coding it. I wasn't sure it would work but thankfully it was easy to try it out and it did work as I had hoped.

// Right curtain.
right_curtain := Rectangle {
    border-radius: 4px;
    // Before: `width: open_curtain ? 0px : parent.width / 2 + 4px;`.
    width: open_curtain ? 0px : ((parent.width / 2) + border-radius);
    x: open_curtain ? parent.width : ((parent.width / 2) - border-radius);
    // ...
}

I want to use this toolkit to develop an application for the Librem 5 (https://puri.sm/products/librem-5/) and hope that fluid layouts for mobile-sized screens will be a feature I can use.

I'm excited to see this project grow and hope to see more posts and updates from you! As far as I know, your project is the only one written in Rust to support a templating(?) language to separate design from the application logic. There is Qt and GTK but they aren't written in Rust and have some baggage when trying to using them in Rust that makes them not ergonomic in my eyes. Druid and iced seem promising but as mentioned before, I like separating my design code from the logic.

[tronical]

Thank you for reading and going through the tutorial - glad you enjoyed it!

Your idea of introducing row_count and column_count properties is good - I agree that it improves the readability. Want to submit a pull request to change the example code in the master branch? :)

Regarding layouts, do you have an idea how you would like to express the different screen sizes?

[gondolyr]

I've opened up #136 to add row_count and column_count properties . 🙂

Regarding different screen sizes, I don't have any ideas as I'm new to native application GUI development. I am familiar with CSS and your 60 language feels like a mix between QML and CSS. Something like media queries could be easy to get into initially, however, I have my doubts about the ergonomics with this approach for the long-term. I don't specialize in frontend web development so I can't speak too much on responsive design best practices with CSS.

Some of my current influence is from the libhandy library for GTK. Based on the few tutorials I've attempted using libhandy such as this one, I feel out of control by not being able to set the break points when it should shrink for phone portrait, tablet, or desktop; it is possible that there are ways to set them, however, I'm not familiar with GTK, or libhandy in this case.

Screenshot from the libhandy tutorial:

I will have to get back to you if I come up with any ideas, however, as of this moment, I'm not certain what would feel ergonomic.

[tronical]

(Ah, I’m only learning about Threads here heh)

Yeah the media queries I also find a bit awkward, maybe too opaque. I really like bootstrap’s responsive grid and flex box, when it works.

Perhaps it would make sense for the users to define screen profiles in one central place, give them names and allow the user to re-use those names in individual layouts (flex box etc) when declaring break points, row counts etc.

The existing global properties mechanism might be a tool on the way.

[jlgerber]

I know that I am probably in the minority, but, as someone who would prefer to not have to jump between a DSL and Rust, I am wondering whether it is possible to author the ui totally in Rust and not use .60?

I really enjoy Rust, and find the experiencing of bouncing back and forth between two languages distracting. This seems like a perfectly decent example of the approach mind you. Just not my cup of tea. (Feel the same way about QML).

[tronical]

At the moment we don't really have a pure Rust API in mind, but in theory it's doable - and I think it's perfectly fine to prefer that over a markup. I think it's a bit of a question of ergonomics perhaps. What do you have in mind as an API for building and manipulating the scene?

That said, today you can use sixtyfps::sixtyfps!{ ... } to use .60 markup inside .rs files, as a compromise.