Decouple GUI in POS appliaction

so I want to make a POS application, I've dabbled in code for years, but I'm self employed in a different industry. As a result I don't work with code every day and I don't have vast experience working on projects.

The most difficult aspect of programming I find is not getting the opportunity to work on projects to learn how to apply different patterns. The information online is always vague and abstract, often leaving you with more questions than answers in terms of how to apply patterns in certain scenarios.

If anyone can recommend a book or an online resource where I can glean an insight into developing a modern GUI application from start to finish, that would be great. I've read Design Patterns, Reusable Object Oriented software and it was the first book I've ever read that tries to answers some real problem questions. Rather than just a vague impossible to follow dictionary regurgitation of abstract programming terms.

Anyway for my application I think I'm going to go down the road of an MVC type approach. I have a good idea of how I plan to implement certain things like data access/writing through factories and adaptors. I have a good idea of how I'm going to implement the model layer as that is fairly straight forward.

The part I'm struggling with is the GUI and the controller and view layers, more specifically how to decouple them? I plan to have a common menu on the left that launches different areas of the application displayed on the right, whether it be viewing/adding/deleting customers, viewing/adding/deleting products or processing sales.

Would a good approach be to create controllers and views with a common interface. The controller would only be a single type that implemented a common interface. The view on the other hand would have a common interface, but I would use factories and polymorphism in the controller to instantiate concrete classes targeting specific GUI frameworks/platforms. This way the controllers have a common interface for being passed commands by the view. The view has a common interface for being told when to draw itself and when to remove itself, moreover the concrete classes of view would encapsulate the specifics of how they actually do their thing on specific frameworks/platforms.

That feels right to me, but it adds another problem of how the view would communicate with the model, the information required would be different for each model+view combination, which makes it more difficult to implement a common interface. also there might be times when I need to disable a text box in the view from the controller but how would I do this without the controller knowing intricate details about the view.

Apologies for the really long post, but any guidance would be greatly appreciated.