Re:Krita, OpenGL and Qt
by Moru on Saturday July 18, 2020 @08:07AM
(#23880827)
One of the problems with using a framework for a non-trivial project is that you get locked into the framework. If the framework decides to change something in an update that you depend on, it can mean non-trivial rewrites unless you could expect the development already. Most frameworks tries to be close to 100% backwards compatible and grow in complexity because of it. Others change a little at a time. And then some does big breaking changes or rewrites and calls it version 4.0. That makes it increasingly hard to find help online.
[ Parent
| on HN ]
It really depends how you structure your code. While my Qt apps are very much coded against Qt, it’s actually pretty easy for me to currently switch them to other UI frameworks as needed. I’ve done this with some of my bigger tools going to other frameworks.
If you keep your logic separate from your UI, and interact via method calls, it’s not very hard to swap out the underlying object. Arguably, it’s the pattern Qt encourages anyway so that you can flexibly change your UI design in the future
> While my Qt apps are very much coded against Qt, it’s actually pretty easy for me to currently switch them to other UI frameworks as needed.
Are yours apps open-source or do you know some architectured in the same way ? Curious and interested to dive into a well designed Qt application with logic and UI separation.
Unfortunately none of my Qt code is open source.
Re:Krita, OpenGL and Qt
by freedomben on Saturday July 18, 2020 @11:49AM
(#23882163)
Second this. I love context-based organizations like newer versions of Phoenix default to. I've been using that in apps for years.
Basically all of the application UI is in framework-independent code. When plugging in the UI portion, you never do logic on stuff, you just call functions/methods to get it done.
It's not perfect, but it makes it much easier to port to a different framework/toolkit in the future.