GUI Design patterns?

1

I'm building my first real GUI app which is a wizard, where each step contains a bunch of components that the user interacts with; which all may end up reading or writing to the filesystem one way or another.

Inside each step, various components of the GUI have their own purpose, and what happens later in the wizard may depend on what has come before it.

That's why I (think) I don't want something like MVC, where the job of the GUI is simply to return a list of the users desires to a central controller; I don't want the controller to be invoked only at the end of every step, when the user presses 'next', I want everything to be real time, and the 'next' button to automatically appear, only when everything is correct (rather than a static button that sends the data to the controller, who then returns a Result of the entire validation.

I.e. I want the state of each step to store a bunch of Options, which turn Some after user input and validation, and the next button to appear automatically when all of the struct is filled with Somes. This means we don't separate concerns between the front end and the backend. The front-end directly fires it's backend request (such as selecting a file) which I hear is a no-no, and so before I put too much investment into this strategy, I wanted to run it by the far wiser than me among you.

What do you think?

2

Not sure if that helps, but I can share a thing I’ve learned which makes GUI programming easier for me. It is the idea that GUI fundamentally shows a bunch of data. That is, the model that fundamentally backs a GUI is a bunch of strings, list and maps. It is not your application domain model, which is a rather more complicated beast.

So, when designing a GUI, a start with a POD which describes the state of the GUI and which is independent of the rest of the app:

struct GuiData {
  active_step: u32,
  step1_data: Step1Data,
  step2_data: Step2Data,
}

...

Then, I use framework reactive capabilities to draw this state on the screen, and to wire in the events. Finally, I bridge the POD and the internal domain model. Lowering the complex internal model to a simple data model is where you serve the dependency between GUI and the business logic.

I think this approach is know and model, view, view model (mvvm).

I don’t find MVC thinking useful — nobody knows what “controller” is.

1 Like
3

I am also new to gui programming. What you describe sounds similar to some behaviors that I saw on the iced repository readme as animation. GitHub - iced-rs/iced: A cross-platform GUI library for Rust, inspired by Elm maybe to look at their example code helps. (I think your interpretation of the implications of MVC is not correct. You can have a bunch of views in your gui at the same time, it doesn't have to be like a monolithic.)

4

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.