A few questions regarding porting from Qt to CS
Posted: Sat Mar 06 2021 7:08 pm
Hi,
I have stumbled across the CS fork of Qt while reading some comments about the current Qt development direction. I am a software developer who in a team of 3 is developing and maintaining commercial buisiness applications that once were multiplatform and developed using Qt. We have migrated our software to newer Qt versions several times in the past (started off in 1999) but some design decisions in Qt 5 prevented this effectively because these things broke our ability to interface with 3rd party libraries and internal API of the Windows system (which now is our only platform we develop for).
As CS was derived from a Qt version that precedes those design decisions to me it seems that CS is a better foundation to migrate to than Qt-5 (yes, we will never consider Qt-6 in it’s current licensing state - so even the move to Qt-5 would be a dead end) would be. I have a few questions that I would need some help with in my evaluation of the feasibility of our port from Qt-4 to CS.
- In Qt-5 sources were supposed to be only acceptable to be UTF-8 encoded. All our attempts, to make our programs work, failed which we tracked down to this design decision as we are working with Latin-1 encoded sources - changing to Utf-8 broke the compile process as both the compiler and the Qt-translation routines can’t deal correctly with string literals that contain any character that is encoded in more than 1 byte. Funnily there are only two source files in all of Qt-5 that require Utf-8 encoding and they are only used on one of he many mobile platforms). I read through the documentation of CS and just want to be reassured that it didn’t follow the lead of Qt-5 and still allows Latin-1 (or locale) encoded sources.
- In later Qt-4 and Qt-5 versions access to pixmap resources was removed from programs which have no GUI (QCoreApplication derived, not QApplication). Part of our software operates as Windows services which does not allow for a GUI event loop but still needs access to QImage and QPixmap resources as well as the image format plugins. In that area we use a patch for Qt to allow the access to these kind of resources which works nicely. If the same restrictions apply to CS would I be correct to assume that to comply with the LGPL we only would need to make the patches we applied available to out customers (if they are not accepted into the CS code base)?
- The QString implementation of CS seems to store Utf-8, we rely heavily on having no conversion penalty (both speed and memory fragmentation issues would make life hard for us) when interfacing with external Utf-16 requiring libraries. Are we able to use QString16 throughout our development somehow? Or do we have to convert from QString16 to QString whenever using GUI elements (our software deals with high volume text that is coming from outside sources)?
- We made some essential fixes to some of the collection classes of Qt-4 which are not fully 64-bit code compatible on the Windows platform (integers of the compiler are 32 bit whereas the Qt code incorrectly assumes 64 bit integers). We made the patches available to the Qt developers but to my knowledge we still must apply these patches to the current Qt-4 although our patches were made available to them well before Qt-4 was EOL’ed by Digia/Trolltech. Should these errors have made their way into CS what would be your stance regarding possibly accepting our patches into the main code base?
- Lastly, looking through the sources it seems that CS still allows for access to platform specific native window and bitmap handles - this access is mostly preveted by the new rendering pipeline in Qt-5 which was one of the major roadblocks we faced in porting to Qt-5. Am I correct in this regard?
Thanks for bearing with me - but if my initial impressions are correct then CS may be our best way forward now. We may need some help porting our build system from Qmake to CMake but first things first, viability of a port regarding the above issues is the main concern at the moment...
I have stumbled across the CS fork of Qt while reading some comments about the current Qt development direction. I am a software developer who in a team of 3 is developing and maintaining commercial buisiness applications that once were multiplatform and developed using Qt. We have migrated our software to newer Qt versions several times in the past (started off in 1999) but some design decisions in Qt 5 prevented this effectively because these things broke our ability to interface with 3rd party libraries and internal API of the Windows system (which now is our only platform we develop for).
As CS was derived from a Qt version that precedes those design decisions to me it seems that CS is a better foundation to migrate to than Qt-5 (yes, we will never consider Qt-6 in it’s current licensing state - so even the move to Qt-5 would be a dead end) would be. I have a few questions that I would need some help with in my evaluation of the feasibility of our port from Qt-4 to CS.
- In Qt-5 sources were supposed to be only acceptable to be UTF-8 encoded. All our attempts, to make our programs work, failed which we tracked down to this design decision as we are working with Latin-1 encoded sources - changing to Utf-8 broke the compile process as both the compiler and the Qt-translation routines can’t deal correctly with string literals that contain any character that is encoded in more than 1 byte. Funnily there are only two source files in all of Qt-5 that require Utf-8 encoding and they are only used on one of he many mobile platforms). I read through the documentation of CS and just want to be reassured that it didn’t follow the lead of Qt-5 and still allows Latin-1 (or locale) encoded sources.
- In later Qt-4 and Qt-5 versions access to pixmap resources was removed from programs which have no GUI (QCoreApplication derived, not QApplication). Part of our software operates as Windows services which does not allow for a GUI event loop but still needs access to QImage and QPixmap resources as well as the image format plugins. In that area we use a patch for Qt to allow the access to these kind of resources which works nicely. If the same restrictions apply to CS would I be correct to assume that to comply with the LGPL we only would need to make the patches we applied available to out customers (if they are not accepted into the CS code base)?
- The QString implementation of CS seems to store Utf-8, we rely heavily on having no conversion penalty (both speed and memory fragmentation issues would make life hard for us) when interfacing with external Utf-16 requiring libraries. Are we able to use QString16 throughout our development somehow? Or do we have to convert from QString16 to QString whenever using GUI elements (our software deals with high volume text that is coming from outside sources)?
- We made some essential fixes to some of the collection classes of Qt-4 which are not fully 64-bit code compatible on the Windows platform (integers of the compiler are 32 bit whereas the Qt code incorrectly assumes 64 bit integers). We made the patches available to the Qt developers but to my knowledge we still must apply these patches to the current Qt-4 although our patches were made available to them well before Qt-4 was EOL’ed by Digia/Trolltech. Should these errors have made their way into CS what would be your stance regarding possibly accepting our patches into the main code base?
- Lastly, looking through the sources it seems that CS still allows for access to platform specific native window and bitmap handles - this access is mostly preveted by the new rendering pipeline in Qt-5 which was one of the major roadblocks we faced in porting to Qt-5. Am I correct in this regard?
Thanks for bearing with me - but if my initial impressions are correct then CS may be our best way forward now. We may need some help porting our build system from Qmake to CMake but first things first, viability of a port regarding the above issues is the main concern at the moment...