To wait till Qt 6 if we want to switch to the preferred "QtFoo". "QWin" is consistency with existing conventions the downside is having QtFoo for the namespace, and it seemed that the suboptimal naming Make sure because there was several emails last year about QFoo or I think, Sze please correct me if I am wrong, he just wanted to Makes IMO to keep the 'Extras' in the name. To me it would make sense to enforce the QtFoo naming convention for such module-wide enums, but still allow QFoo style naming for "targeted" namespaces. The scope of that particular namespace is to provide enums for a small set of SSL classes, whereas namespaces like QtWin and QtMac are module-wide. One could also argue whether for example the QSsl namespace is that bad after all. That would give us cute names and less changes needed in the future while porting to Qt 6. ':%s/QWin::/QtWin::/g' will make a difference to users if they'reĭoing the same for all other namespaces in Qt 6.Ĭonsistent or not, do we want to introduce more namespaces with suboptimal names? IMHO it would be better to go for the optimal naming with new namespaces, and eventually fix the old remaining ones in Qt 6. I vote for "QWin" for consistency, and I'm not sure that an extra The change occurs), at the cost of introducing more inconsistencies. Naming convention now (and a smaller list of namespace changes if/when "QtWin" has the benefit of introducing users to the preferred Having to wait till Qt 6 if we want to switch to the preferred "QWin" is consistency with existing conventions the downside is With all that in mind, do we want "QtWin" or "QWin"? The benefit of Thiago blocked the latter on the basis that (i)ĭevelopment on that module has stopped, and (ii) QtConcurrent is quiteĭifferent from all the other namespaces anyway. Īs of Qt 5.1, all public namespaces are "QFoo", except "Qt" and Qt 5 was close to Beta 2 at the time, so heĬhose the lower-risk "QtFoo" -> "QFoo". Lars said that he preferred "QFoo" -> "QtFoo", but that change was the QtMultimedia::MetaData (unreleased), QtMultimedia (unreleased), and Namespace, and it seemed that the suboptimal naming was chosen for otherīefore Qt 5 was released, most public namespaces had the "QFoo" format I think, Sze please correct me if I am wrong, he just wanted to make sureīecause there was several emails last year about QFoo or QtFoo for the Thus I do not see a way to solve this problem using preprocessor directives.Ok, let's use QtWin for the namespace. There does not seem to exist a common preprocessor directive that is understood by both. So in summary, moc does understand some preprocessor directives but the ones it does understand are different between versions before and after qt 5.4. Most funnily, if under qt 5.5.1 I turn the version check macro mack to using #if QT_VERSION >= QT_VERSION_CHECK(5, 4, 0) $ moc foo.h | grep QGL > /dev/null & echo "found" $ moc glwidget.h | grep QOpen || echo "not found" This time I'm using moc from qt 5.5.1 in Debian unstable and I get: $ moc -v So we think that we found the solution and try running moc from a more recent qt distribution on the same code. If we try again with that check, then moc in qt 5.2.1 in Ubuntu trusty generates the right results We can change the version check to the much simpler #if QT_VERSION >= 0x050400 So you see that even though qt 5.2.1 does not have QOpenGL, moc interpretes the preprocessor directive that way $ moc glwidget.h | grep QOpenGL >/dev/null & echo "found!" $ moc glwidget.h | grep QGL || echo "not found" #if QT_VERSION >= QT_VERSION_CHECK(5, 4, 0) Then create glwidget.h containing: #ifndef GLWIDGET_H
QT PLATFORM CONTRACTOR INSTALL
apt-get install libqt5opengl5-dev build-essential qttools5-dev qt5-default.on a Ubuntu trusty system which comes with qt 5.2.1 (you can create a chroot using sudo debootstrap trusty ubuntu-trusty) do:.To test this problem, try out the following: Must I resort to having two nearly identical header files (except for two lines) and then choose the right one at build time in cmake? But that doesn't seem to work either as the preprocessor will remove the magic Q_OBJECT line, indicating that indeed moc must be run before the C preprocessor is run. I tried to work around the problem by adding a add_custom_command directive to my CMakeLists.txt which would run $" -E -P -x c++-header.
QT PLATFORM CONTRACTOR CODE
I thought I could write code like this to support both: #if QT_VERSION >= QT_VERSION_CHECK(5, 4, 0)īut that will not fly because moc does not seem to understand the preprocessor directives and will generate code for the wrong class. My code is supposed to compile and run on platforms before and after Qt 5.4 where QOpenGLWidget was introduced, superseding QGLWidget.