Will widget-based Qt be deprecated?
-
Does anyone have information if widget-based Qt programming in C++ will further be supported in the future?
It would be important for me as I wouldn't invest time to learn Qt Widgets if the company will later excessively turn to QML. -
Though there's a lot of movement around QML widgets are still supported and AFAIK there are no official statements or plans to retire them in foreseeable future. The status of the module is "Done" i.e. it's maintained and tweaked but no revolutions are planned. It's been so from the beginnings of Qt 5 around 5 years ago.
Widgets are not going away anytime soon. Certainly not in Qt 5 time frame and I highly doubt in Qt 6 either. -
Though there's a lot of movement around QML widgets are still supported and AFAIK there are no official statements or plans to retire them in foreseeable future. The status of the module is "Done" i.e. it's maintained and tweaked but no revolutions are planned. It's been so from the beginnings of Qt 5 around 5 years ago.
Widgets are not going away anytime soon. Certainly not in Qt 5 time frame and I highly doubt in Qt 6 either.@Chris-Kawa Good to hear. Thanks.
-
Though there's a lot of movement around QML widgets are still supported and AFAIK there are no official statements or plans to retire them in foreseeable future. The status of the module is "Done" i.e. it's maintained and tweaked but no revolutions are planned. It's been so from the beginnings of Qt 5 around 5 years ago.
Widgets are not going away anytime soon. Certainly not in Qt 5 time frame and I highly doubt in Qt 6 either.@Chris-Kawa I certainly hope that is the case. I am moving from C# to QT and C++ in order to have three things: SPEED, more SPEED, and cross platform.
Based on my research QML represents the rejected notion that the simple smartphone interface will be used for everything. Sorry, but you cannot "simply" support a 5" screen the same as a 50" 4096x2160 monster like I am using, with many people in the real world using multiple 28" 4K UHD monitors.
As for speed, I understand that QML does an awful lot of code generation at run time. That has to be a slower startup and more importantly quite insecure, since my understanding is also that the QML source is needed at run time. That is just C# all over again.
My QT app is a HUGE learning experience, but it is anywhere from 5 to 50 times faster. It is actually more of a C# unlearning experience. I got pretty lazy with C#.
My vote is for BIG desktop support and compiled code. I hope they are listening. Phones are important but are not the only tool that people use.
Has anyone gathered some stats showing the use of QML in real world big applications? I'd be curious to see some real QML based programs, not just the simple examples in Creator. I've seen C# programs switch from Forms to WPF and simply go away because they were all new and buggy. Their development time would have been better spent improving what they had or simply taking an extended holiday.
Sorry for the long rant, but it would pain me to see QT do away with widgets and it never occurred to me that it was an option.
-
@Chris-Kawa I certainly hope that is the case. I am moving from C# to QT and C++ in order to have three things: SPEED, more SPEED, and cross platform.
Based on my research QML represents the rejected notion that the simple smartphone interface will be used for everything. Sorry, but you cannot "simply" support a 5" screen the same as a 50" 4096x2160 monster like I am using, with many people in the real world using multiple 28" 4K UHD monitors.
As for speed, I understand that QML does an awful lot of code generation at run time. That has to be a slower startup and more importantly quite insecure, since my understanding is also that the QML source is needed at run time. That is just C# all over again.
My QT app is a HUGE learning experience, but it is anywhere from 5 to 50 times faster. It is actually more of a C# unlearning experience. I got pretty lazy with C#.
My vote is for BIG desktop support and compiled code. I hope they are listening. Phones are important but are not the only tool that people use.
Has anyone gathered some stats showing the use of QML in real world big applications? I'd be curious to see some real QML based programs, not just the simple examples in Creator. I've seen C# programs switch from Forms to WPF and simply go away because they were all new and buggy. Their development time would have been better spent improving what they had or simply taking an extended holiday.
Sorry for the long rant, but it would pain me to see QT do away with widgets and it never occurred to me that it was an option.
@lonnie said in Will widget-based Qt be deprecated?:
@Chris-Kawa I certainly hope that is the case. I am moving from C# to QT and C++ in order to have three things: SPEED, more SPEED, and cross platform.
My QT app is a HUGE learning experience, but it is anywhere from 5 to 50 times faster. It is actually more of a C# unlearning experience. I got pretty lazy with C#.
C++ may be noticeably faster than C#, depending on just what your code does. However, in what sense are you saying that Qt is faster than (whatever framework, e.g. maybe .NET?) than C#?
-
@lonnie said in Will widget-based Qt be deprecated?:
@Chris-Kawa I certainly hope that is the case. I am moving from C# to QT and C++ in order to have three things: SPEED, more SPEED, and cross platform.
My QT app is a HUGE learning experience, but it is anywhere from 5 to 50 times faster. It is actually more of a C# unlearning experience. I got pretty lazy with C#.
C++ may be noticeably faster than C#, depending on just what your code does. However, in what sense are you saying that Qt is faster than (whatever framework, e.g. maybe .NET?) than C#?
@JNBarchan My application has a very noticeable speed improvement. I had been considering going back over the C# code to optimize some things but since I was also wanting cross platform I took a peek at QT.
Using the same basic framework of a tree picker and a layout to display the chosen file, which is compressed and encrypted with aes256, the QT is a hands down winner in speed and is so much faster I do not feel the need to optimize. So now I can continue developing.
The optimization was to eliminate compression and encryption for the file header to give an easier and quicker access to some basic info that tree item requires. By continuing to compress and encrypt all elements, I am more secure and do not need to experiment with a new data structure.
