The simplest example possible

Learn
1

I understand that it is difficult to produce good documentation. After all, not all of us are good at writing and, more important, we all have day jobs and other responsibilities. Still, it is difficult to learn how to use a crate when all you have is examples to work from. I’ve been trying to learn Iced anyway and have been browsing through the examples off of github, trying to learn how to make this crate work for me. Still, with each one I invariably bog down, always coming to a point where I really don’t comprehend what the code is doing. Is it possible that someone familiar with Iced could write an example that is absolutely the simplest possible application of the Iced GUI? It doesn’t even have to do anything. Maybe just open a window and let it sit there. Something like that would give me a framework that would let me experiment and explore adding widgets and text and making other modifications. It would also provide a great springboard for asking intelligent questions. Does anyone want to give that one a try?

2

https://docs.rs/iced/latest/iced/trait.Sandbox.html#a-simple-hello-world

I also start with this minimal example in my video-tutorial:

2 Likes
3

Ok, so I copied the simple “Hello, world!” code and compiled/ran it just fine. Thanks. Now, suppose I want to change the initial size of the window. I’ve played around with that a bit, and so far have come up empty. How would I do that? Here’s the code copied below:

use iced::{Element, Sandbox, Settings};

pub fn main() -> iced::Result {
    Hello::run(Settings::default())
}

struct Hello;

impl Sandbox for Hello {
    type Message = ();

    fn new() -> Hello {
        Hello
    }

    fn title(&self) -> String {
        String::from("A cool application")
    }

    fn update(&mut self, _message: Self::Message) {
        // This application has no interactions
    }

    fn view(&self) -> Element<Self::Message> {
        "Hello, world!".into()
    }
}
4
  1. We go to the docs and then search for “window”.
  2. We see that the second occurrence says that the Settings struct has a window field.
  3. We notice this field has a window::Settings type.
  4. We realize that this type has a size field.

So, we can write:

use iced::window;

Hello::run(Settings {
    window: window::Settings {
        size: (420, 69),
        ..window::Settings::default()
    },
    ..Settings::default()
})
5

Thanks! I’ve been having fun playing around, changing the various settings to see what happens. This has really helped. I do have questions, of course. Here’s one:

You end the ::Settings block with this line:

..window::Settings::default()

I’m assuming that is just a blanket way of leaving anything not specifically changed (like the size setting you demonstrated) with the default values. Am I right?

If that’s the case, why was it necessary for you to end your snippet with a repeat of, basically, the same thing?

..Settings::default()

Seems redundant to me, although I’m sure it’s not.

6

This is called struct update syntax in Rust. It’s not specific to iced.

In the snippet

Settings {
    window: window::Settings {
        size: (420, 69),
        ..window::Settings::default()
    },
    ..Settings::default()
}

we have 2 different structs: Settings and window::Settings. We use defaults for initializing both and use update syntax to overwrite the fields we are interested in: window and size, respectively.

Keep in mind that iced uses Rust to its full extent! Lifetime generics, associated types, asynchronous programming, etc. If you are not very familiar with the language, you will certainly struggle learning iced!

7

It was good to re-read that section from the book. It helped clarify some things for me.

Perhaps it would help if you understood my background. (Feel free to read the short bio I added to my profile.) As I noted there, it was decades between my early forays into coding during the late 1970s and early 1980s and this current attempt on my part to learn and apply Rust. I’ve made significant progress learning the Rust language, but likely still could be classed as a “novice” or, certainly, as an “amateur”. As a former math teacher, I am fully aware that no one really learns any technical topic until he/she attempts to apply it. That is what I am doing and that is why I am asking so many questions that someone more advanced than I am (which is mostly everyone :>) could easily view as too simple to be asked. One doesn’t simply absorb knowledge with one read through the Rust Book. Hence, as I said, it was good for me to re-read that section in Chapter 5 about using struct update syntax. My project has reached the point that I simply must pull in some sort of GUI and Iced seems like the best choice. And that’s why I’ve been bothering you here.

I realize that should you and your other core members choose to continue answering my questions, I will be using up your time and energy. So, I’ve been looking for a way for me to contribute and I might be able to do that when it comes to some of the documentation. I’m a pretty good writer (I’ve written three books) and am coming from the perspective of someone who is less familiar with the topic than a developer. That’s a good thing because anyone needing to work through the Iced documentation is doing so because he/she is also unfamiliar with Iced. So, as I am learning how to use Iced, I can also help build the crate’s documentation. I’ve already started doing that, but what I have so far isn’t really in any kind of shape ready for sharing. (I read through the contribution guidelines and will, of course, follow them.)

@hecrj you have been quite patient in answering my questions. I’d love it if you and maybe some of the other developers could continue your long-suffering ways :>) .

8

I completely understand. We were all beginners once.

I do get bothered and frustrated easily as of lately—and I’m working on that!—but at the end of the day I am really happy to help. I apologize if any frustration comes through some of my interactions.

It goes without saying, but all of our help is a gift and comes free of any expectations of you! That said, if you feel like you want to give something back, then that’s awesome.

Any kind of additional learning material is very welcome. The best form for that would be a tutorial or a series of blog posts that you can share with the community without any need for the core team to approve it. Not all contributions need to go through the core team, although suggestions for official documentation are also welcome!

I’ll be happy to help whenever I can!

1 Like
9

I’m curious – has anyone already started a tutorial? What I’ve been working on is modifications to the documentation for the iced::window::Settings documentation that, at least for me, would make it more readable/understandable. It could also be used to enhance a tutorial. If you already have a tutorial started, where can I find it?

10

Ok, now that makes some sense. I hadn’t caught that we were dealing with two different settings structs. So, am I right that the last line in your snippet

..Settings::default()

references the iced::settings::Settings struct, while the first default line

..window::Settings::default()

is limited to the window settings only?

11

https://brianch.github.io/iced-twentyone-tutorial/01intro.html

12

Sorry. I was thinking of a written tutorial. I have started working my way through that video tutorial and will get back to it soon.

13

I’m still playing with the window settings and have a couple of questions.

  1. When I change the transparent: field back and forth from true to false, I see no difference in the window. What should I be looking for?

  2. I’m clueless as to how to apply the icon: field. Could you give me an example?