Re: [Development] Using string literals in autotests
Hi, I'd say performance should be a consideration for autotests since they are compiled and run over and over again in the CI. So, string theory should be applied to avoid unnecessary conversions and allocations. Even it is considered a minor optimization, it will have an impact on energy consumption & CO2 emission in the end, IMO. Of course, writing a sophisticated template squeezing out the last bit of runtime performance on which the compiler has to chew for a while does not help either, since the test is typically compiled and run once. Surely, the Foundation Team is in the process of creating instructive documentation on string theory? Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Widget Designer: Using fully qualified enumerations in .ui file properties
Hi,
I am planning to migrate Qt Widget Designer towards using fully
qualified enumerations when writing .ui files in 6.7. That is, instead of
QFrame::Box
it will then generate:
QFrame::Shape::Box
The motivation behind this is that it should support scoped enumerations
and this will be required at some point by Qt for Python.
For properties, uic just generates these values into C++; so it should
mostly work transparently. There are some corner cases though where some
checking code in uic/QtUiLoader/Designer needs to changed from
if (v == "Qt::Horizontal") to something like if
(v.endsWith("::Horizontal"))..
These modifications are planned to trickle through to 6.5 so that tools
embedding older versions of Qt Designer can handle it.
The question is; do you see any problems with this? Is there tooling out
there that would trip over this? Would it be worth to make it optional?
Thanks,
Regards Friedemann
--
Friedemann Kleint
The Qt Company GmbH
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Adrian Herrmann as approver for the Qt project
Hi, +1 from me as well. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Compile error on MSVC: '/RTC1' and '/O2' command-line options are incompatible
Hi, this is https://bugreports.qt.io/browse/QTBUG-114925 . Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )
Hi, quick status update: I think the major part of source code changes is done, few changes are still in the works or waiting for review. Thanks for the reviews and proposals. I think most changes were actually for the better and quite some cruft and duplication was unearthed. We are hoping to get it all in + a change adding an option to configure so that it can be used. I am now able to build Qt (qtbase/qtdeclarative and additional modules) in 10min (home-office), whereas before, qtdeclarative alone would have taken longer than that. This shows the potential; also for the projects depending on us in terms of server load, time and energy consumption. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )
Hi, thank you for the reponses; so we conclude that we should support it and use it partially in COIN, ideally for slow platforms. I will try to focus on qtbase and qttools. qtdeclarative would also be a worthy goal; would someone be up for it? Basically the changes linked to https://bugreports.qt.io/browse/QTBUG-109394 and https://bugreports.qt.io/browse/PYSIDE-2155 give you an idea what to do. As for Shawn asking whether the concatenation is deterministic; in my experience, it is. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Hi, we also need to agree on whether the Qt library rules apply to the full extent; for example: - Do we use the modern string literals (u"bla"_s, previously, example code just constructed QString from ASCII and did not care about -DQT_NO_CAST_FROM_ASCII, IIRC) - Should tr() be used for all user-facing messages (although examples mostly do not have translations set up) - Do we use std::as_const to avoid detaching containers in loops (mostly missing for code ported from Q_FOREACH) and probably some more? Generally, when polishing examples, I found that member initialization greatly simplifies code. Regards, Friedemann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] CMake UNITY_BUILD ( QTBUG-109394 )
Hi, I would like to propose considering making Qt suitable for CMake UNITY_BUILDs ( https://bugreports.qt.io/browse/QTBUG-109394 , https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html ) . This has originally been proposed for Qt for Python ( https://bugreports.qt.io/browse/PYSIDE-2155 ). It has greatly benefited from it; builds are much faster; particuarly for us in home-office where no distributed build environment exists. It is basically what webengine has been using for a long time: Source files are concatenated to jumbo files which are then compiled. For Qt for Python with its lots of generated files, the speed-up is drastic (~10x); for an average module (qttools), less so, but still: Initial build of qttools: Standard (675 files): real 3m26,016s / user 19m4,352s / sys 1m48,346s Unity (203 files) : real 2m2,557s / user 9m40,147s / sys 0m47,144s (CMAKE_UNITY_BUILD_BATCH_SIZE=16) with CCACHE/warmed up: Standard (675 files): real 1m50,605s / user 8m9,512s / sys 1m9,187s Unity (203 files) : real 1m30,990s / user 5m11,773s / sys 0m39,687s Increasing CMAKE_UNITY_BUILD_BATCH_SIZE might also give better results. Some modifications of the source code are required, though. The majority is actually improvements; things like missing header guards and macro re-definitions immediately show up; also Q_DECLARE_METATYPE() can be removed (see https://lists.qt-project.org/pipermail/development/2022-July/042744.html ). But there is also a part that is more questionable; static functions need to be disambiguated; "using namespace" can cause clashes; class member fields from anonymous namespaces cause errors ( -Werror=subobject-linkage producing qerrormessage.cpp:38:7: error: ‘QErrorMessagePrivate’ has a field ‘QErrorMessagePrivate::pending’ whose type uses the anonymous namespace ) and similar. Some things are not fixable; exclusions can be done on a source file or project level. Alternatively, one can group suitable source files together; but this requires more work. In development work, if COIN uses UNITY_BUILD, there is also a small risk of changes with missing header files being accepted. Summmarising: we stand to gain a speed-up of compilation; particularly for clean builds like in COIN; but it requires some work. We might do a step-by step approach process enabling modules one by one. What do you think? Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Shyamnath Premnadh as approver
Hi, +1 from me as well. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How to do deprecation
Hi, > TL;DR: there's a new [[Deprecation]] wiki page, please review. It misses an important part, IMO: Try to get an idea of the impact of your planned deprecation by building all of Qt and ideally Qt Creator (producing patches fixing the deprecation warnings). If that turns into an huge exercise taking several days, it becomes clear that the deprecation is not feasible. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows maintainer change
Also +1 for the new maintainers from me and I wish them great success. -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Confused about HiDPI scaling and fonts
Hi, it seems there is a misunderstanding here: Qt High DPI scaling preserves the point-size of the fonts; they are sized according to the system metrics. All it does is pretend a lower resolution to the application so that apps written for 96DPI continue to work. It is not a means of zooming the application (as opposed to QT_SCALE_FACTOR ). Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Hi, > QProperty can be exposed to the meta object system, and behaves just like a getter/setter/signal property there. > Rather, the focus is currently on classes in QtCore, QtNetwork, and QtGui QtGui's QAction is relevant for Qt Designer. This would be a test case for the compatibility. Regards, Friedemann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Hi, > 3) how QProperty is source-compatible with Qt 5 user code. Specifically, it needs to be transparently visible in QMetaObject like old-style properties and setting/retrieving properties via name and QVariant needs to work for Qt Designer's property editor. Code generation via uic also needs to work transparently. Regards, Friedemann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.13 & 5.14 add device-independent pixels to device-dependent
Hi, > But the case of linear arrangement of screens can be solved. The only questions are whether it's necessary to solve it to get the currently-broken applications fixed and if it is, how to detect the cases where we can and when to give up. Just for the record: If you switch Windows to DPI awareness = 1 (system DPI aware) as opposed to Qt's default (2, per monitor DPI aware), you will also get screen arrangements with gaps from the system when differently sized monitors are connected. So, Qt needs to deal with that situation and I don't think we should be trying to rearrange screens. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Plans of platforms in the CI and released binaries
Hi, > I did not know about ticket https://bugreports.qt.io/browse/QTBUG-74687 where discussions about Windows 7 in Qt6 have been discussed. Nor did apparently no one else in our meetings, > since we were not told about those discussions. Neither did we know that you were making plans when discussing this ... ;-) > So without anyone really responding to this thread, am I still to understand that you wish to have Windows 7 in Qt 5.15 CI? (and even if I get 2 replies that say “hell yeah”, those 2 might be the only 2 people in the world using that ) Hell, yeah, in 5.15 at least until RHI is stable... Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Plans of platforms in the CI and released binaries
Hi, for Win32, my 2c would be: - As already stated at https://codereview.qt-project.org/c/qt/qt5/+/285317 , we still need Windows 7 since as it stands today, it will still be supported (for some time) in Qt 6. Since it is very easy to break it by using some too-new API (especially in the light of RHI), this needs to be tested in some form - For static builds, it seems that -static , -static-runtime now works with MSVC2019, so, from the Win32 perspective, there is no need to keep MS 2015? - Clang should be clang 8 or 9, clang-cl preferably Regards, Friedemann Kleint -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QAction in Qt 6 - next step proposal
Hi,
> I didn't know that there is going to be one more subclass. Will
QQuickAction be a public class?
In Qt 5, AFAIK it exists with duplicated code in QuickControls1,2 as a
class exposed to QML (no public C++ class). The duplication (and also
need for the functionality for WebAction) is one of the reasons for the
change.
In QML3, it could become a public class indeed.. it could be sth like
namespace Quick { class Action ...};
>in QtGui/qaction.h
> // forward declare classes from QtWidget
> class QMenu;
> class QWidget;
Again, this poses huge problems for Qt for Python (besides being a
questionable design).
Regards, Friedemann
--
Friedemann Kleint
The Qt Company GmbH
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QAction in Qt 6 - next step proposal
Hi, as discussed on the change, there is not much one can do with the newly introduced QGuiAction; it serves as a base class for QAction and QQuickAction, The naming follows the Q(Gui)Application pattern. > QMenu *menu() const; > -> static QMenu *QMenu::menuForAction(QAction *action); > void setMenu(QMenu *menu); > -> static void QMenu::setMenuForAction(QAction *action, QMenu *menu); This in my opinion is a no-go, we cannot do source-incompatible changes in this area because there have been many deprecations already and code needs to compile against 5 and 6 with minimal changes. Ofc, having one QAction class in QtGui is desirable; but it must not infer source-incompatible changes (and no, hacks like forward declaring QWidget from QtGui or similar are also a no-go since it causes trouble for Qt for Python). Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QTCS2019 Notes from Qt Solutions session
at https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_Solutions -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QTCS2019 Notes from the Qt 6 Changes / Migration session
at https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QTCS2019 Notes from the High DPI session
at https://wiki.qt.io/Qt_Contributors_Summit_2019_HighDpi -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI
Hi, >Could at least a note at the official documentation be added stating that the method generates an invalid UI file and it must not be used? Note proposed: https://codereview.qt-project.org/c/qt/qttools/+/279377 > It is for sure a bug, so please report it. I'm not sure how much love the widgets designer gets these days, though. As explained before, it cannot be guaranteed that changing all properties in random order works in Widgets. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI
Hi, >Just a little follow up. Can this (invalid widget being generated by QFormBuilder.save ) be considered a Qt issue and fixed?The "all properties changed" is not a big deal, the incorrect form is. This cannot realistically be supported, I am afraid. Simply changing all properties from bottom to top may hit on a number of corner cases where properties are not orthogonal and have interactions causing misbehavior. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI
Hi, > I am trying to use the QFormBuilder to load and later save a ".ui" file. > The issue is that the generated file shows all properties as modified but the code just open the file and save it with a new name. QFormBuilder writes out all properties since plain Qt properties do not store whether they were modified. The book-keeping required for this only exists in Qt Designer. Some unsupported properties/flags may then be encountered. > Is there a better approach to save QWidgets as ".ui" from code? No, unfortunately. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6: inline namespace Qt
Hi, just for the record, I would like to point out that the implications on tooling need to be considered: The clang-C-API (libclang) as used by Qt for Python, qdoc (and potentially lupdate) does not know about inline namespaces AFAIK; the code would have to ported to the Clang C++ API. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Dev branch moving towards Qt 6
Hi, >To reflect that and help us all understand that the development focus is now towards Qt 6, I would like to propose that dev becomes the > Qt 6 branch after we branched away 5.14 How long do we keep merging 5.14->dev? At what point do we go into cherry-pick mode for 5.14->dev? This should probably be done after 5.14 API review and initial testing at the earliest? Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Supported compilers for Qt 6
Hi, > VC++ 2019 Just for the record, this compiler still has a number of optimizer bugs, see https://bugreports.qt.io/browse/QTQAINFRA-2875 . Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Hi, AFAIK Gatis is working this (see https://bugreports.qt.io/browse/QTBUG-69414 ). There is a magic define widgets/widgets/qcombobox/qcombobox.pro:4:DEFINES += QTEST_QPA_MOUSE_HANDLING widgets/widgets/qmenu/qmenu.pro:9: DEFINES += QTEST_QPA_MOUSE_HANDLING which apparently changes behavior. Alternatively, the overloads of QTest::mouse*() that take a QWindow * can be used, which should act more sane. This might require some coordinate mapping, though. Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] New \nullptr qdoc macro in 5.12, please start using it
Hi, in Qt 5.12; there is a new \nullptr qdoc macro to be used for nullptr (see "Documentation: Add \nullptr macro and use where applicable" 3eac688ec005833509bffc7097c378af9c5b515f https://codereview.qt-project.org/#/c/249583/ ). The underlying motivation (besides using modern C++) is that Qt for Python users trip over the documentation stating "0 can be passed to this pointer * parameter...), thinking they can pass (int) 0 (see https://bugreports.qt.io/browse/PYSIDE-903 ). I would like to encourage the maintainers to go through their documentation and look for things like "void *foo() \** returns 0 when..." or "0 can be passed to this pointer * parameter") and change this to \nullptr (see fex https://codereview.qt-project.org/#/c/249610/ ). This will then expand to None in the Qt for Python documentation. Thanks, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Christian Ehrlicher for Approver
+1 from me as well; many thanks for your contributions! -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Cristián Maureira-Fredes for approver
+1 from me -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Noninating André de la Rocha for Approver
Hi, +1 from me, too, (same office though); UI and Pointer message handling were great jobs. Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why Widget::grabMouse() installs WH_JOURNALRECORD hook on Windows in Qt 4.8.x
Hi, > journalRec = SetWindowsHookEx(WH_JOURNALRECORD, (HOOKPROC)qJournalRecordProc, GetModuleHandle(0), 0); > Since this clearly a hack that was obviously needed to make mouse grabbing working, I would very much like to know why it was done in this way and what was the original problem. some digging in the history failed to reveal any information on why this done; the code can be safely removed, I think. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clazy results for Qt codebase
Hi, interesting - would it it be possible to provide it as a Creator task file (simple tab-separated file to be loaded into Creator's issue pane, see http://doc.qt.io/qtcreator/creator-task-lists.html )? That would it make it easy to click through and fix. Thanks, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Writing good tests
Hi, here is the link to the Wiki on "Writing good tests" as requested at QtCS: http://wiki.qt.io/Writing_good_tests . Regards, Friedemann The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog entries and reverted commits
Hi, have a look at https://codereview.qt-project.org/#/c/201164/ for the Perl script. Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Automatic detection of Visual Studio Compiler
Hi, please make sure you don't have QMAKESPEC set in the environment (see https://bugreports.qt.io/browse/QTBUG-60016 ). Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qdoc for C++ and QML
Hi, btw, we are facing a similar problem when generating the documentation for the PySide2 project (Python bindings for Qt). The code snippets are different; most of the text is similar. So, the issue could be generalized for any language bindings of Qt. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qdoc for C++ and QML
Hi, For starters, take a look at the script: http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/scripts/qdoc2tasks.pl?h=4.3 You can pipe the error output of qdoc through it to convert it to a Qt Creator task file. Opening it in Qt Creator will show the issues as build issues (see http://doc.qt.io/qtcreator/creator-task-lists.html ) and you can then click through them. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QUIP for choosing a branch
Hi, as a result of the QtCon 2016 discussion on Managing Qt's Branches ( http://wiki.qt.io/QtCS2016_Managing_Qt_Branches ), we would like to provide some guidelines on which branch to choose for a change. Please find attached a QUIP which is available for review at https://codereview.qt-project.org/#/c/178906/ . Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH QUIP: 5 Title: Choosing a Branch Version: $Revision$ Last-Modified: $Date$ Author: Jędrzej Nowacki, Friedemann Kleint Status: Draft Type: Process Created: 2016-12-05 Choosing a Branch Motivation -- This QUIP aims to provide some guidelines on what branch to choose for a change. It originated from the `QtCS2016 Managing Qt Branches <http://wiki.qt.io/QtCS2016_Managing_Qt_Branches>`_ session. Goal of the LTS branches (5.6 at the time of writing) - - Support slower moving OSes - Fix bugs in applications that were already shipped bundling the LTS and continue to build against the LTS - Have a low regression risk - Add new minor platforms (if and only if changes are minimal like win8 => win8.1) - Documentation clarifications We divide the LTS into 3 periods (assuming cherry-pick contribution model): - 5.6.0 *relaxed*: We assume that people still develop applications with the LTS or they are porting to it, so they are more willing to take a risk of regressions or general brokenness in Qt. - 5.6.x *strict* At that point applications should be working with the LTS or be shipped. It is not allowed to break existing bug workarounds, even if the bug is fixed. For people using the LTS release, there is no real gain in rewriting working code. - 5.6.y *very strict* 2 years after the .0 release, we believe that there are no more P1, P0. where x = 1 year from .0 release and y = 2 years from .0 release Goal of the stable branches (5.x) - - Bug fixes - Performance fixes - Documentation fixes - As a special case, pre-release stabilization of the dev branch Goal of the dev branch: --- - New feature development - Major refactoring - Risky changes, requiring longer testing period (moc, qmake...) - Completely new platforms (WinRT) Approach The table below lists typical code changes and points to which branch the change should be pushed. In all cases, we need to estimate impact of the change. For example, a fix for a performance problem may end-up in a different branch depending on: how many users are affected, how big is the improvement and what is the risk of regressions. The table shows the most stable branch, for every case. If a change is risky or it has lower impact, then it should be placed in a less stable branch. ++-++-++-+-+ ||LTS || | | |+-++-+ Stable | Dev | Notes | | Issue | Relaxed | Strict | Very Strict || | | ++-++-++-+-+ | Security | x |x |x| x| | | ++-++-++-+-+ | 3rd party update | x |x |x| x| | | ++-++-++-+-+ | Test improvement | x |x |x| x| | | | (reduce flakiness) | || || | | ++-++-++-+-+ | Adapt to minor OS/ | x |x |x| x| | | | Compiler updates | || || | | ++-++-++-+-+ | Memory leak| x |x | | x| | | ++-++-++-+-+ | Fix to feature added | x |x | | x| | | | in LTS | || || | | ++-++-++-+-+ | Undefined behavior | x |x |
Re: [Development] A new approach for Qt main()
Hi, from the Windows POV, support for wmain() with wide arguments would be a nice thing to have (see https://bugreports.qt.io/browse/QTBUG-46118 ): int wmain( int argc, wchar_t *argv[ ], wchar_t *envp[ ] ) Maybe that can be implemented by some smart modularization. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A new approach for Qt main()
Hi,
> Q_GUI_MAIN(appInit, appExit);
Magic macros for main should be avoided, IMO.
A typical application main() can look like
main()
{
QApplication a();
Initialization code for other libraries
parseArguments(), return if failed
show some FileDialog prompting for argument if sth was missing
try {
app.exec()
} catch (exception) {
}
De-Initialize something
}
There is no way to shoehorn this into some macro; this can already be
observed when trying to adding some initialization to a test.
Regards,
Friedemann
--
Friedemann Kleint
The Qt Company GmbH
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression
Hi, >My try to build qt 5.8.0 from git using vs2017 rc (CL 19.10.24629) failed already when building configure. (commit 2c27ccd1c9a821edd071cae6336ecb2066ce2ab7) >the qt 5.8 beta did work. Using CL 19.00.24213.1 (vs2015 upd3 + kb) also works. >does anyone have the same problem? Probably constexpr was activated for this compiler but not tested. Please make sure you have "Fixed build using Visual Studio 2017" a103992f49045323a3aaa4970eb1ee5f65a378dd https://codereview.qt-project.org/#/c/177743/ applied. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Hi, technically speaking: is using the .rst format set in stone? I find this difficult to handle; one needs a local web server to view it AFAIK. .md comes to mind as alternative? Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Notes on "Managing Qt's branches" session @ QCS 2016
Hi,
the notes are at: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches
* Number of existing branches (5.6LTS, 5.7.,5.8 dev) causes a number of
problems
** Strain on COIN which also has release branches
** Merging becomes increasingly difficult
** Hard to manage for individual developers
* Branches
** Close 5.7 after 5.7.1. We then have LTS, stable, dev.
** After 5.7 is closed and sanity bot is upgraded (to handle
cherry-picking), go into cherrypicking mode for 5.6. Developer is
responsible for doing the cherrypicking
** Cherry-picking technicalities need to be figured out: Let sanity bot
verify source ("cherrypicked from") the SHA1
** In the future, exact time for closing stable branches will be
discussed for each one individually
* Submit Policy
** Target which branch?
** Long Term Support (5.6) Branch
*** Initially equal to stable, increasingly strict over time: Fix only
severe issues, avoid regressions.
*** Bugs: For example, P2 for the first year, P1 for year 2, rest
Security. Try to further objectify that: Jedrzei + Friedemann
*** Tests: Fix/stabilize tests itself, add tests
*** No performance improvements unless really significant
(relevant/reduces O(n))
*** Upgrading 3rd party (including WebEngine)
*** Support new OS versions unless introducing new platforms, no rewrite
of QPA
*** No cleanups, positively: -> dev
*** To aid customers with issues, patches for issues in LTS to be
locally applied can be provided, but the fixes will be pushed to higher
versions of Qt.
Regards,
Friedemann
--
Friedemann Kleint
The Qt Company GmbH
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Programs crashing left and right in the CI
Hi, to summarize for Windows: - Crashes have been observed over time in various tests, mostly in QtCore (QDir,QFile, QProcess see fex https://bugreports.qt.io/browse/QTBUG-47370 - It only affects 64bit (!) (correct me if you have observed otherwise) - It never has been observed for MinGW (most likely since we don't have 64bit MinGW builds?) >It's also possible that the Windows code is simply recovering, and that >QTest::toString is actually causing the crash. In other words, it's possible >the code that deals with crashes in QtTest is causing the crash. I think the QTest::toString appearing is an artifact of the code that walks the stack. We know that it seems to depends on some obscure CI parameters (load?), so far, we have not been able to see anything useful in the stack traces. Regards, Friedemann -- Friedemann Kleint, The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] MSVC2012 in CI
Hi, >I'd love to remove it, but it's blocked by https://bugreports.qt.io/browse/QTBUG-51934 >We cannot just remove test coverage without testing some of the features on more modern platforms. We blacklisted the test for the moment, so, we could switch to MSVC2015 now. Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Security bulletin: Deprecating QRect
Hi, as discussed in the thread "Re: [Development] Fixing QRect::width() / height()", QRect can be misused to trigger undefined behaviour. This pattern has been observed in recent ransomware attacks using the new High DPI feature in Qt 5.6 to place windows at bottom right positions on High DPI screens inducing undefined behaviour. To fix this, the class QRect will be deprecated as of now in a patch release 5.6.0.1. The maintainers are kindly asked for a quick review of https://codereview.qt-project.org/154371 and the release team to prepare the patch release. Regards, Friedemann -- Friedemann Kleint The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] High-DPI on Win
Hi, >(3) Don't calculate the scale from the display resolution (QPlatformScreen::pixelDensity()). >In QT5.5 the devicePixelRatio is obviously set to either 1.0 or 2.0 depending on the >resolution of the display. I'm not sure for Qt5.6, but it seems to be alike here. However, in Win the >user can set a scaling such as 100%, 125%, 150%, 200%, and 250%, and the user >can do so - and may want to do so - for whatever display she/he is using (anyone with ailing eyes is >happy to use 125% on regular screens, or 250% on HDPI screens ;)). So - IMHO - >the devicePixelRatio should actually be set to exactly this value, independent on any display resolution. The Windows setting is not related to any scaling done by Qt. It only changes the return values of the metrics functions (logical DPI, font + icon sizes, etc); no devicePixelRatio scaling is done there. >Sadly, I must agree with you that Qt does indeed not handle high-dpi windows very well L I have Qt applications that I cannot use on my system, and have resorted to qt.conf to >turn off DPI-awareness for them; fuzzy scaling was preferable to not being able to use the application. There is a restriction currently in that the Windows styles are not suitable for scaling. We recommend using Fusion style for High DPI. Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pixelated UI elements in Windows HiDPI mode (5.6)
Hi, >I don't see tickets in Jira for any of these. Please do not create unrelated, single tickets for each issue. Previously, we had https://bugreports.qt.io/browse/QTBUG-40277 "Adapt styles to High DPI" (related to https://bugreports.qt.io/browse/QTBUG-46615 "Implement High DPI scaling v2 (5.6)"). QTBUG-40277 could be cleaned up listing the remaining items or a new report linked to QTBUG-46615 could be created in a similar fashion. Also note that the Windows styles do not support scaling (and will not for the foreseeable future); we recommend using Fusion style (or Mac style on OS X). Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtbase 5.5 CI broken again ?
Hi, As far as I know, no. No one has a clue why the creation of a temporary directory is failing. It is simply running out of patterns to try since the mime DB tests leaked temp dirs. https://codereview.qt-project.org/#/c/121381/ fixed QDir::removeRecursively() to try harder removing files and https://codereview.qt-project.org/#/c/121383/ fixed the test to set write permission on the temp files it creates; the test should no longer leak. All that remains to be done is reboot the Windows CI nodes and clean out their temp directories. Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.5 CI having problems on tst_qmimedatabase-xml
Hi, the log says it all when running it: QTemporaryDir: Unable to remove D:\\temp\\tst_qmimedatabase-l9Mfi9 most likely due to the presence of read-only files. That is, either there are readonly files left behind or some sub-process of the test is sitting on some files in the temp dir and QTemporaryDir runs out of patterns to try for a unique name next time...I will check. Rebooting that CI node and cleaning its temp dir may help for the moment. Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 5.5 CI having problems on tst_qmimedatabase-xml
Hi, the test leaves a tempdir containing read-only test files behind, but I fail to see where they come from ATM. Could the maintainers have a look, please? IIRC, there was a change in testlib unpacking resources to a temporary dir that initially had this issue (creating read-only files), but that was fixed and I don't see the respective macro here. Anyways, since this issue occurs every now and then in some test, I am proposing https://codereview.qt-project.org/#/c/121381/ to ensure deletion of the temp dir succeeds in this case as well. Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Testability Driver
Hi, adly we're not using it in Canonical any more. TDriver did a good job with Qt4 apps. But it was desired to have a single tool to test multiple toolkits (Qt GTK Html5) using python, so we ended up building our own: AutoPilot [1]. IMO TDriver is more powerful though. Does this mean the code introduced by https://codereview.qt-project.org/#/c/66513/ can be removed ? - No need to keep dead code? Thanks, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rotating JPEG images by default
Hi, If we go with the QImageReader level, it could be an QImageIOHandler::Option, and possibly be set different between JPEG and TIFF by default. The real problem is what we decide the default for JPEG should be now. Can we add an API making this settable until the beta? - I think automatic rotation is a really cool feature for any viewer-like application and saves writing a lot of quite advanced code (using memory mapping of files and endian-dependent word fiddling on platforms that don't have libexif or similar). Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why is QTBUG-27186 closed?
Hi, the behavior of the widgets-based dialog is equivalent to Qt 4.X and that was the end of the story back then. As reading material for Easter, I pushed up a proposal to gerrit ( https://codereview.qt-project.org/#/c/109815/ ). I expect KDE 5 will (again) provide a spectactular native file dialog? Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt3d examples with qt5.5 crashing
Hi, When i try to run any of the compiled qt3d application's release version.The application crashes, and this are the error details collected by windows: I don''t see any crashes with MSVC2013 64bit/5.5. Can you please provide a stack trace and the output of the qtdiag tool? Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Please update the maintainer table at http://wiki.qt.io/index.php?title=Maintainers
Hi, I recovered the tables of the maintainer page which was clobbered in the Wiki transition process, but it still needs some updating content-wise. Please take a look at: http://wiki.qt.io/index.php?title=Maintainers . Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qtbase 5.5 branch is blocked
Hi, there is https://bugreports.qt.io/browse/QTBUG-44434 describing the issue, but there does not seem to be a conclusion yet. It is unlikely that the issue is fixed by the merge or goes away magically; it would be appreciated if the accessibilty experts could take a look. Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem porting app from Qt4 to Qt5 with multiple X-screen
Hi, Ok, now at least all widgets with a desktop widget as parent are created on the correct screen. But as soon as I open a child window (e.g. the file open dialog on my example) this is created on the applications primary screen. Should I fill a bug report for this? Yes please, with a small example (see http://qt-project.org/wiki/ReportingBugsInQt ) . Do you pass a parent widget to the dialog? Qt4 I'm using QX11EmbedWidget/EmbedContainer. In Qt5 I use QWidget::createWindowContainer() + QWindow::fromWinId(). The simple testcase (a QWidget on client and server side) works as expected but I my application it does To my knowledge, the window container functionality is not intended for this purpose ( see related issue https://bugreports.qt.io/browse/QTBUG-34771 ). btw: Is it correct that QScreen::geometry() returns 0/0 every time (openSUSE 13.2/Qt 5.3.2 rpm) As size? - it should report the correct geometry. Which desktop environment is this? Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem porting app from Qt4 to Qt5 with multiple X-screen
Hi, we've multiple X-screens configured (:0.0 ... :0.3) but Qt5 seems to have lost the ability to display something on another screen than the default QMainWindow *wm = new QMainWindow(dw-screen(1)); Change https://codereview.qt-project.org/#/c/105285/ for https://bugreports.qt.io/browse/QTBUG-44070 should improve that. embedding an application window into another application doesn't work correct - the embeded window gets resized with the master but as soon as I click somewhere in the master, the embedded window is hidden by the master. How do you embed the window? Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Event loop of Qt window in DLL injected into another process
Hi, https://bugreports.qt-project.org/browse/QTBUG-40881 might be related? Regards, Friedemann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 Beta snapshot available
Hi, To avoid further delaying of the final release, I'm going to pull QVersionNumber from 5.4. careful: it is already used in: qtactiveqt/examples/activeqt/webbrowser/main.cpp Regards, Friedemann -- Friedemann Kleint Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: friedemann.kle...@theqtcompany.com | www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Change in qt/qtactiveqt[5.4]: Update license headers and add new license files
Hi, That said, he surely has less time for Qt. Is the cmake integration creating any problems? Every now and then, we hit on a failure (fex with dynamic GL). So far, these have been simple compile/link errors in the tests, but the issue is that we might hit a wall once we really need to adapt some Cmakelist.txt, etc. Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt High-dpi QtCS report and patch status (on hold)
Hi, https://bugreports.qt-project.org/browse/QTBUG-38858 is there to track progress . Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Guidelines for reporting bugs in Qt
Hi, as a result of internal discussions at Digia, I have updated http://qt-project.org/wiki/ReportingBugsInQt a bit. The motivation behind this is that we want the bug reports as good as possible since many roles in the Qt project deal with them (developers, code reviewers, release managers, people trying to check for regressions, ...) and thus it is important that bug reports are easy to understand and to reproduce. I would like to have more opinions on the guidelines at http://qt-project.org/wiki/ReportingBugsInQt . Is there anything missing that would make fixing bugs easier in the modules you maintain? Once we have the guidelines in a good shape, they will be shown prominently on the JIRA-landing page. Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Windows QtCS Session, MSVC compiler versions
Hi, here are the notes from the Windows session: https://qt-project.org/groups/qt-contributors-summit-2014/wiki/Qs2014Windows We had a bit of discussion around whether to update the compilers during the lifetime of a minor release. This is relevant for 5.3 since it is planned to be supported for a longer time. For example, for MSVC-2013, options are: - Stick with the RTM / original version of MSVC-2013 for the lifetime of 5.3 since 5.3.0 was shipped with it - Update now to MSVC-2013 Update 2 and leave it as is for the lifetime of 5.3 - Keep updating continuously There are pros and cons for all options. With MSVC, it has happened that the runtime was changed by service packs in incompatible ways causing breakage. On the other hand, sticking to one version means that at some point it no longer matches what everyone else out there is using. What do you think? Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bringing Qt's high-dpi support to more platforms
Hi, for Desktop Windows, this is tracked by https://bugreports.qt-project.org/browse/QTBUG-38993 . On Windows, the application can choose between several levels of DPI-Awareness. The idea is right now to leave the choice to the programmer and make sure Qt does not get in the way and does scaling behind the scenes where needed. Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating JIRA components relating to events.
Hi, Can we get a few volunteer default assignees for the components I suggested? I am volunteering for QPA: windows Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] utf-8 BOM and parsers
Hi, this is tracked by https://bugreports.qt-project.org/browse/QTBUG-37423 - keeping an eye on the release blocking bugs https://bugreports.qt-project.org/browse/QTBUG-37065 occasionally helps to minimize surprises ;-) . Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QWindow::setScreen() and QQuickWindow
Hi, actually re-creating the window is a bit wasteful given that the screens are part of a larger virtual desktop in most cases. A move() would be sufficient. The QWindow/QScreen logic as it is is somehow not well suited for virtual desktops in which the screen is determined by the geometry. Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Hi, Thank you. Sorry this means it gets reverted for now. I think we all agree that having the common ES2 / desktop 2 subset magically work everywhere on Windows Ok, technically speaking, how do we get this through the CI (considering the modules which have follow-up changes ..can we leave the functionality providing the isES() function in place? Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: [Logging] Add quote(), noquote() stream modifiers to QDebug
Hi, how about omitting quotes automatically for anything else but Q[C]Debug? The common problem seems to me that warning messages automatically get quotes which looks semi-professional: qWarning() Cannot open: file.name() : file.errorString(); typically results in: Cannot open: foo.txt : No such file It is also conceivable to use quotes only for empty strings in qWarning/qCritical/qFatal. Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Hi, the intention was here to pave to way for a software renderer for platforms that have no GL at all (virtual machines, remote logins, etc, see https://bugreports.qt-project.org/browse/QTBUG-36091 ). The initial versions of https://codereview.qt-project.org/#change,76732 had a separate QOpenGLProxy module, but we decided to move it into Qt5Gui since otherwise the user would have to deploy yet another library. But having a separate module would not help in the scenario you described (3rd party renderer of some sort e.g. VTK, OpenSceneGraph...), either? Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Ameliorate API Reviewing (Was: On the effectiveness of time based releases)
Hi, - Have an API review board, and for A review board would indeed be a good thing to have, not necessarily restricted to API reviews only. The problem also currently is that reviewers are distracted by a lot of mundane things (check for compilation, compiler warnings, check indentation style, style issues, check for potential performance issues, messages, spelling, functionality smoke testing, checking autotests...), potentially over quite a few review rounds. If there was a review board (supported by more automated testing) making sure each change passes all those criteria before a developer gets to see it, it would be a lot easier to focus on the API. Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
Hi, The main issues outstanding I see: My finding using Windows 8.1 / HP Color LaserJet 6030 MFP PS Class Driver is that the default paper size is B5 (instead of letter/A4) and it simply does not print (using A4), although the code calling EndPage/EndDoc is executed. Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintanance break in CI on Saturday
Hi, There is also a fix for the failing tst_qquicktrailemitter in declarative/stable (see https://bugreports.qt-project.org/browse/QTBUG-33421 , https://codereview.qt-project.org/#change,60072 ) , so, a merge stable-dev for qtdeclarative might further improve things. Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 release integration build
Hi, I suppose that the warnings in the list beneath are still unsolved. Is that correct? How critical is it to solve those warnings? If they are critical for the release, I want to give a helping hand to remove them (after all there are more than 900, the list below is a synopsis). The libraries and examples should be fairly clean; we keep an eye on it (MSVC2012 or MinGW64, typically). Fixing all warnings in the tests is a different matter. Warnings there are not that critical and things like 'unsafe std::copy()' or similar can be safely be ignored there. Talking about tests: The test .pro-files still have a lot of DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0 . Getting rid of those (unless the test actually tests deprecated API) is IMO more important than fixing other warnings since that is going to hit us at some point (in Qt 6 at the very latest). The usual technique for fixing warnings is to push one change per warning type for easier review (for example, fix all signed/unsigned comparisons in one change). Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Virtual GUI framework
Hi, there is a QPA platform plugin named minimal, which roughly does that (run with -platform minimal). It is currently used by tools like qmlplugindump. It dumps out images if the environment variable QT_DEBUG_BACKINGSTORE is set. There also is a plugin named offscreen, which is intended for testing, but is not currently being developed. Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Beta, possible memory leak(s)
Hi, I dislike those because we're incurring overhead at shutdown to do something that doesn't need doing, except to keep tools happy. For the platform printer support, it makes sense since it can potentially have handles open or similar. Not sure about the ICU leak, though? Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Beta, possible memory leak(s)
Hi, here is a fix for printing: https://codereview.qt-project.org/69686 Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Win32 API] Windows 8.1 deprectaed GetVersion(Ex) - QSysInfo should be fixed!
Hi, for your information, we are working on a patch for this: https://codereview.qt-project.org/#change,69129 . Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Vsd: Change in qt/qtdeclarative[stable]: Some minor optimizations
Hi, https://codereview.qt-project.org/#change,68579 might fix the link error? Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 timelines
Hi, We had some good discussions around Qt Connectivity, Mac/Win Extras and Location during the contributor summit, and should conclude on these modules very soon now. For the QtWinExtras, I can say that we have added documentation and tests and are now in the final stages of polishing the API. I think it is in good shape and ready for 5.2. Feel free to have a look ( git clone ssh://codereview.qt-project.org/qt/qtwinextras ). Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Advice for Wacom Tablet support
Hi, For your information, we are planning to re-add tablet support (larval stage at https://codereview.qt-project.org/#change,58971 ). Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI status as of 22. May 2013
Hi, 4) Windows 8’s cmd.exe problem – NOT FIXED This has been a problem since last year. Randomly Windows 8 fails builds due to this. Won’t go any deeper on that one here. Just thinking aloud, sharing what I found when I also ran into this problem when toying with https://codereview.qt-project.org/#change,54814 in the hopes it rings a bell : This change contains a perl script that crawls the examples folders, builds and executes the examples one after the other using a special launcher written in Qt / C++. The launcher launches the example, waits for a toplevel window to show up, sends it a WM_CLOSE after a while and records crashes, stderr, etc. The interesting part is that the launcher code calls the WinAPI function WaitForInputIdle() to wait for the the application to become responsive. If that fails, it kills the application (note: older versions of the patch set just left the QProcess running, this did not matter). Whenever such failures occur, the next invocation of some command by the perl script will report the infamous Can't spawn cmd.exe message. These failures are caused by: - The example application is console application with GUI (CONFIG += console). WaitForInputIdle() then fails with return code WAIT_FAIL and GetLastError() == ERROR_NOT_GUI_PROCESS - More interesting: I have also seen WaitForInputIdle() fail with error 997: Overlapped I/O operation is in progress (typically when the tool processes the tools/customtype, tools/customtypesending examples). This might provide some clue .. maybe at some point some process times out/is killed that does overlapped I/O? Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 combined source package - Perl dependency
Hi, One of the most commented problems has been Perl dependency, especially on Windows. I have to admit I do not really see the point of it as long as QtWebKit requires Ruby and Python. In my view, requiring a scripting language it is acceptable as long as a single, unified language is used. Most projects on Windows require scripting languages for test automation, packaging, etc. For people building from git on Windows, the Perl problem will disappear in the moment the msysgit project decides to update the outdated Perl version it ships (currently 5.8 or so, which currently has problems with syncqt). This would make Perl an ideal candidate. Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
Hi, tst_qdatetime on Windows with a European time zone throws up 8 failures for me on a clean build without my changes. Does this happen for anyone else? Is this test disabled in CI, because I don't see how anything could be passing otherwise? It fails for me, too; the tests are off by 1 hour, it seems. This is indeed a mystery. Is the CI in a European timezone? Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Hi,
I suppose it would not be a detriment. Where do you draw the line?
Which platforms, what functions and types? Here are some candidate types
for constructors and conversion operators...
The thing to keep in mind is basically that the decision to remove the
pixmap conversion functions was mainly motivated by the situation on
Linux. With Qt 5, it is possible to run executables by the same build of
Qt with different platform plugins (XCB/X11 or Wayland, for example).
QtGui no longer links against libX11/libXCB and thus for example
QPixmap::x11PictureHandle() can no longer be provided within #ifdefs in
Qt 5.
The situation on Mac and Windows is different, though, in that there is
basically only one platform plugin (running Windows/Mac with Wayland is
a slightly theoretical possibility). QtGui already links against the
libraries that provide the image conversion functions and it is easily
possible to provide the image conversion functions within #ifdef Q_OS_XX.
The image conversion functions are now in the platform extras, and the
question is whether to bring them back and in which way. Pros are
customer convenience; cons are basically #ifdef clutter and hacks.
I personally think operators are too magic (except for the QRect stuff),
given that the conversions can potentially fail. From the QPA
perspective, we could introduce something like
void *QPixmap::toNativeFormat(enum Format {} ) const
which would then call #ifdefed code or into the platform backend.
Regards,
Friedemann
--
Friedemann Kleint
Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
Hi, we also plan to start Qt Windows Extras to bring at least the missing image conversion functions ( QTBUG-27103 ) back provided we can find someone to create the repository ;-) . Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] which branch for a bugfix
Hi, https://bugreports.qt-project.org/browse/QTBUG-28196 For that particular bug, there is already a fix in the works at https://codereview.qt-project.org/#change,41537 . Accidentally, I got it prototypically to work today with MSVC. As it is a bit involved, it is in the 'dev' branch. Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Hi, quickly trying it out, I found: - qplatformdefs.h of Android has a Nokia License of 2009 - surely that was not intended? - Nokia is also mentioned along with names of former employees in the json style parser under widgets/styles. Btw, I am generally wondering about it, it seems to add a new Json parser. Could it be replaced by the Json classes of QtCore? - Compilation of the branch under Windows fails with the attached log. Something is probably wrong with #ifdefing/profiles? Regards, Friedemann -- Friedemann Kleint Digia, Qt c:\qt\qt-5-vs\qt\qtbase\include\qtcore\../../src/corelib/tools/android/cpu-feat res.h(31) : fatal error C1083: Cannot open include file: 'sys/cdefs.h': No such file or directory qglengineshadermanager.cpp Generating Code... jom: C:\qt\qt-5-vs\qt\qtbase\src\opengl\Makefile.Debug [.obj\debug_shared\qglgr dientcache.obj] Error 2 c:\qt\qt-5-vs\qt\qtbase\include\qtcore\../../src/corelib/tools/android/cpu-feat res.h(31) : fatal error C1083: Cannot open include file: 'sys/cdefs.h': No such file or directory Generating Code... jom: C:\qt\qt-5-vs\qt\qtbase\src\opengl\Makefile [debug] Error 2 jom: C:\qt\qt-5-vs\qt\qtbase\src\Makefile [sub-opengl-make_first] Error 2 jom: C:\qt\qt-5-vs\qt\qtbase\Makefile [sub-src-make_first] Error 2 jom: C:\qt\qt-5-vs\qt\Makefile [module-qtbase-make_first] Error 2 C:\bin\jom.exe failed 512: at C:\qt\qt-5-vs\qt\qtrepotools\bin\qt5_tool line 22 . ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI autotest failures for MinGW
Hi, We created task https://bugreports.qt-project.org/browse/QTBUG-29014 to track the MinGW test failures. We (Digia) will primarily focus on getting MinGW compile tests enabled since the tests are already covered by the MSVC ones. You are welcome to submit fixes, though, please refer to the above mentioned task in the commit message and update it similar to https://bugreports.qt-project.org/browse/QTBUG-28611 or create a subtask for larger issues. Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms
Hi, I am wondering if windows-7-64-msvc2010-angle should become a reference platform and windows-7-32-msvc2010-angle a tier 1 instead, given that Windows is 64bit now and running 32 bit applications is not really native. I understand there are practical problems to getting that tested in the CI as there are no distributing compilers for 64bit? It would be nice to have it tested though, since compiling on 64bit reveals additional warnings about casting between different ints/pointers, etc, that might one day be caught by a compiler warnings check (which I am still hoping for). Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5-Beta build from Git on Windows -- Failed to load platform plugin windows
Hi, on Windows XP, the load error is most likely caused by https://bugreports.qt-project.org/browse/QTBUG-27741 , for which the fix https://codereview.qt-project.org/#change,38566 is pending. Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8 autotests need attention; over 100 insignificant tests!
Hi, to emphasize, the situation is quite serious and there were already regressions like https://bugreports.qt-project.org/browse/QTBUG-25906 (QFile::append no longer working). In most cases, the problem is that most tests using test data files were written assuming those files can always be accessed from the working directory ./test.data. This was true for the old autotest system used in Qt 4. The new test infrastructure of the Qt Project executes 'make check' from the test root directory, causing the working directory to be set to the location of the binary. Since they are located in the 'debug' or 'release' subfolders on Windows or in the application.app/MacOs... folder on Mac, respectively, they can no longer find the test data files from there. In Qt 5, this was solved by introducing the QFINDTESTDATA macro, but porting it to Qt 4 is a non-trivial task. https://codereview.qt-project.org/#change,28579 (Fix QLibrary test) and https://codereview.qt-project.org/#change,27579 (QApplication) illustrate what needs to be done for such cases: - Removing CONFIG -= app_bundle causes the Mac binary to be created in the test root folder - On Windows, cd up one level if the current working directory is 'debug' or 'release' in the test constructor - Remove the insignification from the test profile Additionally, it would be nice if the test printed a nice error report about the missing files. In case the test cannot be completely fixed, it already helps to restrict the insignification to the offending platform or move it to the code (QSKIP, QEXPECT_FAIL). Thanks, Friedemann -- Friedemann Kleint Qt Open Source Team Nokia, Qt Development Frameworks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Nominating Miikka Heikkinen for Approver status
Hi, I would like to nomimate Miikka Heikkinen from Digia for Approver status. He has been working on Qt 5 on Windows for a quite a while and has fixed numerous issues and failing test cases in the areas QWidget/QWindow, fonts, Vista style and QML and is currently working on the daunting task to breathe life into the Active X module. I think this would benefit the project given that the Windows platform is slightly underrepresented among the developers. His dashboard can be found at https://codereview.qt-project.org/#q,miikka.heikkinen%2540digia.com,n,z . Regards, Friedemann -- Friedemann Kleint Qt Open Source Team Nokia, Qt Development Frameworks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Quick2 and Directx11 backend (Angle)
Hi, With Corentin's permission, I have pushed a rebased and slightly polished version of the patch up to https://codereview.qt-project.org/#change,26797 for everyone to play around. The build instructions are inside the class documentation of QWindowsEGLContext. Angle can also be built with qmake, as Morten pointed out: https://gitorious.org/qtangle/qmakeangle . Regards, Friedemann -- Friedemann Kleint Senior Software Engineer Qt Open Source Team Nokia, Qt Development Frameworks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of ActiveQt module?
Hi, the status of the module is that we are trying to keep it compiling, such that it does not totally fall apart. Apart from the meta object issues, it needs another major refactoring due to the Lighthouse architecture (it previously used widgets with native handles). We (at Nokia) do not have the resources to bring it to a working state, however it is conceivable that for example Digia or others step up. I would suggest that, if you do changes, add some #fixme comments to its code pointing the potential developer/maintainer in the right direction. Regards, Friedemann -- Friedemann Kleint Senior Software Engineer Qt Open Source Team Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
