AlexFagrell

Joined 8 years ago

Karma
93
Submissions
15
Member since
Sep 20
Software developer. Blogging on http://cleanqt.io . Exploring new countries. Londoner.
View on Hacker News

Recent submissions

Comment · 7 years ago
Thanks, great comment!

While outlining the post, I was uncertain what to call the particular group of classes (or concern) now called the Controllers. If you look through the GitHub project, you'll find that at one point they were called Routers. I agree with you that this design is not a MVC by the traditional definition (i.e. Smalltalk's), however there are many variants out there, see for example Apple's https://developer.apple.com/library/archive/documentation/Ge..., that I didn't think it would hurt 'to add' another. As long as it's clearly defined what it is. But perhaps it is not clear.

In this design, the 'traditional controller' is already part of the front-end. One of the goals of this design is to keep the front-end only concerned with styling and the layout of the application, and not the logic or the flow. So from the front-end, the user-interactions will be forwarded down to the 'back-end' Controllers. Those controllers are responsible for the flow of the application. The back-end includes logic and models in the traditional sense, see for example the DocumentsModel (https://github.com/Fagrell/clean-editor/blob/master/lib/publ...), however there are also models that correspond to specific Components. Those "Model Components" contain logic and a state, e.g. the MenuModel referred to in the post.

Perhaps an even better separation would be to add another layer?

- UI front-end - View/Component layer -> includes the 'view and controller by the traditional definition'.

- Router/Controller layer -> includes Models for specific components and Routers (as Controllers are defined in the post). Defines the flow.

- Back-end layer -> includes models by the traditional definition.

Thoughts?

Comment · 7 years ago
Hey buddy! I've meant to add RSS and email to the blog but haven't got around to do it yet. Sorry... Thanks for the reminder though, I'll see what I can do over the weekend! Cheers, Alex
Comment · 7 years ago
Comment · 7 years ago
Hi guys, This is the 7th post in the series "Crash course in Qt for C++ developers." Do you structure and architect your application in a similar way? Let me know what you think and I would appreciate if you have any feedback.
Comment · 8 years ago
Thanks again! I agree with you!
Comment · 8 years ago
Thanks, very true. Several people have pointed this out so I'm convinced I'll have to rearrange the order. Perhaps just start with a simple example and move the event loop/handling after Widgets/QML. I believe I'll also have to split Widgets and QML into two separate posts as those are big subjects.
Comment · 8 years ago
Hey there! Thanks, great comment. I'm considering rearranging the topics when it's finished.

My thinking was that the event loop is one of the first thing that you'll encounter, i.e. app.exec() in main, when using Qt. The fact that the flow of the app is event-driven is important to understand when working with a GUI toolkit and thought it would be good to introduce early on (even though you rarely use the actual event system itself). Perhaps not as a first topic though.

Yeah, I realised that it shouldn't be Shown HN, but can't find a way to edit it, thanks.

Appreciate the feedback, cheers!

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton