Re: [Development] QSurface handle is NULL
It is similar to that one, although a resize call won't solve it in my case. But the situation is same as what David Eller wrote in his comment. After a makeCurrent() call, QGLContext::currentContext() and QGLWidget::context() won't be the same. I forgot to mention that i use Win7, with msvc 11.0. Best regards, Csaba 2013/12/5 Sean Harmer sean.har...@kdab.com On 05/12/2013 14:56, Csaba Csernai wrote: Hi everyone! I am working on a project, which uses openGL, but there is some glitch when i create a new instance of QGLWidget. It seems that somehow the QSurface::surfaceHandle() returns NULL, thus can't make the context active. Can anyone suggest when can this handle NULL? Is it this bug https://bugreports.qt-project.org/browse/QTBUG-35342 ? If so, work around is to add an explicit resize() before show(). Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Csaba Csernai C/C++ Software Developer Mediso Medical Imaging Systems Ltd. Hungary, H-1022 Budapest, Alsótörökvész 14. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Request] Compiler warnings in Qt
When compiling applications with compiler flags on, a lot of warnings are generated for the Qt header files. It needs a lot of work to exclude them in our builds, and some of them can just not be excluded because they are located in macros or inline methods. The same holds for the moc generated code. I propose to change the build system of Qt to enable as much compiler flags as possible and fail the build when there are any warnings. Although most of them are more or less harmless, some could be potential errors (e.g. compiling with -Weffc++, generates a warning that the destructor of QSharedData is not virtual). The public API could be a good starting point. What do you think? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Compiler warnings in Qt
On Fri, Dec 06, 2013 at 11:16:20AM +0100, Kurt Pattyn wrote: When compiling applications with compiler flags on, a lot of warnings are generated for the Qt header files. It needs a lot of work to exclude them in our builds, and some of them can just not be excluded because they are located in macros or inline methods. the solution to that would be https://bugreports.qt-project.org/browse/QTBUG-7220 I propose to change the build system of Qt to enable as much compiler flags as possible and fail the build when there are any warnings. that change was already done (and not everybody approves of it). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtCreator 3.0.0-rc1 building
Hi!
I'm try to build 64-bit QtCreator-3.0.0-rc1 with mingw-w64 GCC-4.8.2
toolchain and got cast error:
C:/repo/mingw-w64-qt-creator/src/qt-creator-opensource-src-3.0.0-rc1/src/plugins/ios/iosdebugsupport.cpp:
In member function 'void
Ios::Internal::IosDebugSupport::handleGotInferiorPid(Q_PID)':
C:/repo/mingw-w64-qt-creator/src/qt-creator-opensource-src-3.0.0-rc1/src/plugins/ios/iosdebugsupport.cpp:163:15:
warning: ordered comparison of pointer with integer zero [-Wextra]
if (pid 0) {
^
C:/repo/mingw-w64-qt-creator/src/qt-creator-opensource-src-3.0.0-rc1/src/plugins/ios/iosdebugsupport.cpp:165:68:
error: cast from 'Q_PID {aka _PROCESS_INFORMATION*}' to 'int' loses
precision [-fpermissive]
m_runControl-engine()-notifyEngineRemoteSetupDone(int(pid),
m_qmlPort);
^
Makefile.Debug:4665: recipe for target 'debug/iosdebugsupport.o' failed
Is it fixed in repository?
Regards,
Alexey.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Compiler warnings in Qt
On Friday 06 December 2013 11:16:20 Kurt Pattyn wrote: When compiling applications with compiler flags on, a lot of warnings are generated for the Qt header files. It needs a lot of work to exclude them in our builds, and some of them can just not be excluded because they are located in macros or inline methods. The same holds for the moc generated code. I propose to change the build system of Qt to enable as much compiler flags as possible and fail the build when there are any warnings. Although most of them are more or less harmless, some could be potential errors (e.g. compiling with -Weffc++, generates a warning that the destructor of QSharedData is not virtual). The public API could be a good starting point. Hi, We aim at having clean public headers. There used to be a 'compilerwarnings' autotest that made sure there was no warning in the headers (in a more strict ways that the warnings we check while compiling Qt itself). But i think it's gone. Anyway, feel free to report bug about warnings in public header. Or better, fix them and submit patches to gerrit. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls Calendar
On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis mitch.cur...@digia.com wrote:
Hello.
At the beginning of this year I started work on a Calendar for Qt Quick
Controls as a sort of side project. After removing the WIP from the
commit message, I got some feedback from developers who either a) had
also wrote a Calendar for KDE stuff or b) suggested I ask for feedback
from plasma-devel. Rather than add to the already massive list of patch
sets for that change, I thought it would be better to truly open up the
Calendar for contributions before it goes in by creating a WIP branch
for it in the Qt Quick Controls repo [1]:
wip/calendar
It'll be a throwaway branch, so every commit must be atomic and follow
all of the normal Qt commit policies [2][3]. At the end, we'll resubmit
every individual change to qtquickcontrols' dev branch.
Please feel free to submit patches or provide feedback on what's already
there. For example, it has already been suggested that there should be a
C++ backend for the models, dates, etc.
Cheers.
[1]
https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a
[2] http://qt-project.org/wiki/Branch-Guidelines
[3] http://qt-project.org/wiki/Commit_Policy
Hi Mitch,
It's awesome that you pull in the KDE plasma folks. I wonder who gave
you that idea? ;)
Below is my feature list that i'd like to have in that calendar.
Since i have some experience in that area i will try to help out as
much as i can.
-- QML part --
* Controls for the calendar grid
* Controls for next/forward or just a few functions. This should at
least have a nextMonth/previousMonth. Perhaps also nextYear and
previousYear for convenience.
* Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
the ability to change the name to shorter/longer variants.
* Controls for the weeknumbers that are shown in the grid.
As far as i understand the QML code, all but the weeknumbers are in.
-- Locale --
In KDE there was already an issue with differences between the
JavaScript date object and the QDate object. I don't know the fine
details here, someone else will probably fill that in i hope. I know
there where issues, just not what exactly.
-- C++ part --
This is the part where i really would like some feedback. I have a
general idea of how it should be done, but i don't know the details or
implications it might have.
It is my hope that calendar controls like Mitch is proposing now will
be extensive enough to simply swap the models to another backend.
Akonadi comes to mind. However, there should obviously be a
non-akonadi based version for default Qt usage.
My idea on that is as follows. Again, i don't know the implications of
it or if it's really viable to take this route. Feedback is very much
welcome here!
The calendar model should be based on a new model that provides some
default functionality and properties. I would say:
QAbstractCalendarModel : public QAbstractListModel { ... }
This model should provide the default - should be implemented - properties:
* day -- INT number of the day in a current month
* isCurrentMonth -- returns true for the current month (aka, the month
you are viewing in the calendar). Returns false for the days before
and after the currently viewing month. Based on the position in the
grid you can then calculate if the entry where isCurrentMonth
returns false is before or after the current month.
* containsEvents -- true if the day contains events, false otherwise
day and isCurrentMonth should be convenience implemented in the
QAbstractCalendarModel.
Next there should be a model for core Qt calendar usage. Or in other
terms: no akonadi dependency.
That would be a class like:
QSimpleCalendarModel : public QAbstractCalendarModel { ... }
That class should probably have some basic storage in json files
somewhere? Or ini or sqlite or..? Just something so that it can be
used out of the box without any other requirements beyond Qt.
Till this point is what would probably go in Qt. Everything after this
line becomes Akonadi specific and should not be in Qt.
If a structure like the above is approved then Akonadi can be very
easily used in KDE with the Qt calendar components.
We'd just have to make out own QAbstractCalendarModel implementation
that uses akonadi data. That would be a class like:
(K)AconadiCalendarModel : public QAbstractCalendarModel { ... }
It can still use the base QAbstractCalendarModel implementation for
it's grid stuff and re-implement the containsEvents property to be
filled with data from akonadi.
Well, that's it for my idea thus far. I'm looking forward to some
opinions on this.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCreator 3.0.0-rc1 building
-Original Message-
C:/repo/mingw-w64-qt-creator/src/qt-creator-opensource-src-3.0.0-
rc1/src/plugins/ios/iosdebugsupport.cpp:165:68:
error: cast from 'Q_PID {aka _PROCESS_INFORMATION*}' to 'int' loses
precision [-fpermissive]
m_runControl-engine()-notifyEngineRemoteSetupDone(int(pid),
m_qmlPort);
^
Makefile.Debug:4665: recipe for target 'debug/iosdebugsupport.o' failed
Thanks for spotting!
Is it fixed in repository?
Not yet. I've a lame workaround though:
https://codereview.qt-project.org/#change,73437
(note that ios plugin is dysfunctional on Windows, and only there so we can
catch changes that break it while testing on other platforms.)
Regards
Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls Calendar
On 12/06/2013 03:08 PM, Mark Gaiser wrote:
On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis mitch.cur...@digia.com wrote:
Hello.
At the beginning of this year I started work on a Calendar for Qt Quick
Controls as a sort of side project. After removing the WIP from the
commit message, I got some feedback from developers who either a) had
also wrote a Calendar for KDE stuff or b) suggested I ask for feedback
from plasma-devel. Rather than add to the already massive list of patch
sets for that change, I thought it would be better to truly open up the
Calendar for contributions before it goes in by creating a WIP branch
for it in the Qt Quick Controls repo [1]:
wip/calendar
It'll be a throwaway branch, so every commit must be atomic and follow
all of the normal Qt commit policies [2][3]. At the end, we'll resubmit
every individual change to qtquickcontrols' dev branch.
I've been told that this is incorrect; the correct statement is:
even though this is a throw-away branch (whose commits will be
re-submitted to dev individually), the usual policies should be followed
Please feel free to submit patches or provide feedback on what's already
there. For example, it has already been suggested that there should be a
C++ backend for the models, dates, etc.
Cheers.
[1]
https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a
[2] http://qt-project.org/wiki/Branch-Guidelines
[3] http://qt-project.org/wiki/Commit_Policy
Hi Mitch,
It's awesome that you pull in the KDE plasma folks. I wonder who gave
you that idea? ;)
Below is my feature list that i'd like to have in that calendar.
Since i have some experience in that area i will try to help out as
much as i can.
-- QML part --
* Controls for the calendar grid
* Controls for next/forward or just a few functions. This should at
least have a nextMonth/previousMonth. Perhaps also nextYear and
previousYear for convenience.
* Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
the ability to change the name to shorter/longer variants.
* Controls for the weeknumbers that are shown in the grid.
As far as i understand the QML code, all but the weeknumbers are in.
Yep.
-- Locale --
In KDE there was already an issue with differences between the
JavaScript date object and the QDate object. I don't know the fine
details here, someone else will probably fill that in i hope. I know
there where issues, just not what exactly.
From the testing that I did with it [1], it has some differences when
it's a negative year, so the current implementation of the Calendar only
allows positive years, up to the year 275759; a significantly smaller
range than QDate [2].
-- C++ part --
This is the part where i really would like some feedback. I have a
general idea of how it should be done, but i don't know the details or
implications it might have.
It is my hope that calendar controls like Mitch is proposing now will
be extensive enough to simply swap the models to another backend.
Akonadi comes to mind. However, there should obviously be a
non-akonadi based version for default Qt usage.
My idea on that is as follows. Again, i don't know the implications of
it or if it's really viable to take this route. Feedback is very much
welcome here!
The calendar model should be based on a new model that provides some
default functionality and properties. I would say:
QAbstractCalendarModel : public QAbstractListModel { ... }
This model should provide the default - should be implemented - properties:
* day -- INT number of the day in a current month
* isCurrentMonth -- returns true for the current month (aka, the month
you are viewing in the calendar). Returns false for the days before
and after the currently viewing month. Based on the position in the
grid you can then calculate if the entry where isCurrentMonth
returns false is before or after the current month.
* containsEvents -- true if the day contains events, false otherwise
day and isCurrentMonth should be convenience implemented in the
QAbstractCalendarModel.
Next there should be a model for core Qt calendar usage. Or in other
terms: no akonadi dependency.
That would be a class like:
QSimpleCalendarModel : public QAbstractCalendarModel { ... }
That class should probably have some basic storage in json files
somewhere? Or ini or sqlite or..? Just something so that it can be
used out of the box without any other requirements beyond Qt.
Till this point is what would probably go in Qt. Everything after this
line becomes Akonadi specific and should not be in Qt.
If a structure like the above is approved then Akonadi can be very
easily used in KDE with the Qt calendar components.
We'd just have to make out own QAbstractCalendarModel implementation
that uses akonadi data. That would be a class like:
(K)AconadiCalendarModel : public QAbstractCalendarModel { ... }
It can still use the base
[Development] Changed qdebug stream operator output (qtbase/dev)
Hi, Just a small heads-up: I just managed to merge change https://codereview.qt-project.org/#change,69731 in qtbase , dev branch. That change gets rid of the trailing space that was added for every qDebug() ; statement. I guess nobody will really miss it ... but it might be that there are still auto tests checking for it! So, if you've mysterious autotest failures in somemodule/dev where expected output isn't found any more, this might be the reason. Actually QTest now takes this into account for a simple ignoreExpectedMessage(), but that ain't help you if you're e.g. comparing QProcess output ... Follow up patches for some modules are here: QtDeclarative: https://codereview.qt-project.org/#change,69735 Qtsensors: https://codereview.qt-project.org/69734 Qtmultimedia: https://codereview.qt-project.org/#change,69732 Qtquick1: https://codereview.qt-project.org/#change,69736 Kind regards Kai -- Kai Köhne, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changed qdebug stream operator output (qtbase/dev)
I will miss it. Why did we take it out? Now I have to puteverywhere. martin From: development-bounces+martin.smith=digia@qt-project.org [development-bounces+martin.smith=digia@qt-project.org] on behalf of Koehne Kai [kai.koe...@digia.com] Sent: Friday, December 06, 2013 4:29 PM To: development@qt-project.org Subject: [Development] Changed qdebug stream operator output (qtbase/dev) Hi, Just a small heads-up: I just managed to merge change https://codereview.qt-project.org/#change,69731 in qtbase , dev branch. That change gets rid of the trailing space that was added for every qDebug() ; statement. I guess nobody will really miss it ... but it might be that there are still auto tests checking for it! So, if you've mysterious autotest failures in somemodule/dev where expected output isn't found any more, this might be the reason. Actually QTest now takes this into account for a simple ignoreExpectedMessage(), but that ain't help you if you're e.g. comparing QProcess output ... Follow up patches for some modules are here: QtDeclarative: https://codereview.qt-project.org/#change,69735 Qtsensors: https://codereview.qt-project.org/69734 Qtmultimedia: https://codereview.qt-project.org/#change,69732 Qtquick1: https://codereview.qt-project.org/#change,69736 Kind regards Kai -- Kai Köhne, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] New Qt5.2 snapshot available
Hi all, We have new qt 5.2 snapshot available here: http://download.qt-project.org/snapshots/qt/5.2/5.2.0/2013-12-06_200/ These packages are considered to be really close to final release packages so please test these and report your testing effort via http://testresults.qt-project.org/forms/release-testing form and in case of new bugs report those in JIRA https://bugreports.qt-project.org . Qt5 changes after #194: https://codereview.qt-project.org/#change,73299 * qtbase 41dedab...835b821 (18): Announce the deprecation of platforms still using qoldbasicatomic.h enable path replacement in installed prl files on all platforms properly replace windows paths in installed meta files support s///i option in built-in sed dont install modules-inst dir Document that disconnectNotify may be called with a mutex locked QComboBox: Dont do anything if wheel event delta is zero QStyle: Fix painting of pixmaps with non-integer devicePixelRatio Android: Fix crash caused by QJNIs classLoader code. iOS: move infoPlistValue to qiosglobal iOS: dont show statusbar if hidden from Info.plist iOS: Handle statusbar changes to child windows Doc: Adjust description of the qreal typedef Revert Cocoa (OpenGL): If no view is attached, makeCurrent() should return false iOS: fix assert when using QOffscreenSurface iOS: Disable drag and drop completely instead of enabling simple dnd Improve expose event handling. Make layoutDirection pass with new expose behavior * qtdeclarative 4f08859...7251185 (3): Fix a crash in JSON.parse QQmlImport: Dont try use a dangling pointer. static builds: add classname entry to qmldir for QtQuick.Dialogs.Private * qtqa 22c7a1f...25851ea (1): Remove QtJSBackend_release_Integration CI. * qtserialport fdd3876...97bbe2a (1): Do not remove obsolete enum values for gcc and clang https://codereview.qt-project.org/#change,73173 * qtbase 9302169...41dedab (7): added buildsystem/qmake changelog iOS: fix crash when focusWindow changes while keyboard is open iOS: fix crash when application quits qdoc: Fix output filenames for QML basic type documentation Fix style animations to stop when the animation target is hidden qdoc: Replaced hard-coded href with computed href iOS: fix application hangs when opening keyboard * qtdeclarative 3b7a8d9...4f08859 (6): Revert Revert ffaf39e9a7f11d4e2800b3b37160a2a952795614 Fix binding loop in Maroon in Trouble QML demo Dont leave the GL context current after cleanup. Revert Load @2x images on high-dpi retina systems. Update changelog for change Icf323618 / QTBUG-35174 Release GL resources of ShaderEffectSource while we still have GL. * qtrepotools cf6b0e2...d8c8667 (1): recognize bison-generated parsers * qttools f7f37e7...f141efd (3): add 5.2 changelog stop interpreting Tr() and TR() as aliases for tr() disabuse translation system Br, Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Compiler warnings in Qt
On sexta-feira, 6 de dezembro de 2013 13:41:34, Olivier Goffart wrote: There used to be a 'compilerwarnings' autotest that made sure there was no warning in the headers (in a more strict ways that the warnings we check while compiling Qt itself). But i think it's gone. I still have a pending change that compiles each and every public header independently -Werror and defining the keywords. None of my builds with Clang or GCC have any warnings. There are a few with ICC because it's too eager on warning 177 (unused function). I have warnings in MSVC's own headers after we started using algorithms more, so I don't bother with MSVC warnings anymore. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Compiler warnings in Qt
On sexta-feira, 6 de dezembro de 2013 11:16:20, Kurt Pattyn wrote: When compiling applications with compiler flags on, a lot of warnings are generated for the Qt header files. I Which compiler? Which warnings? We're not supposed to have any warnings with GCC or Clang. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Compiler warnings in Qt
I get warnings with clang in OSX. It even treats an unused variable as an error. martin From: development-bounces+martin.smith=digia@qt-project.org [development-bounces+martin.smith=digia@qt-project.org] on behalf of Thiago Macieira [thiago.macie...@intel.com] Sent: Friday, December 06, 2013 6:16 PM To: development@qt-project.org Subject: Re: [Development] [Request] Compiler warnings in Qt On sexta-feira, 6 de dezembro de 2013 11:16:20, Kurt Pattyn wrote: When compiling applications with compiler flags on, a lot of warnings are generated for the Qt header files. I Which compiler? Which warnings? We're not supposed to have any warnings with GCC or Clang. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Compiler warnings in Qt
On sexta-feira, 6 de dezembro de 2013 17:18:02, Smith Martin wrote: I get warnings with clang in OSX. It even treats an unused variable as an error. Which makes you fix them, so we don't get warnings in the repository :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Compiler warnings in Qt
Well, yes, I fix the ones that are errors, but I have seen many warnings that are just warnings. I saw an uninitialized variable in one of the Qt hash collections, but I haven't seen that one lately, so someone might have fixed it. I can't recall the others at the moment. I have been ignoring them if I get a working QtBase, because I have assumed it is just my rarely up-to-date OSX environment. Should I report these warnings in JIRA? martin From: development-bounces+martin.smith=digia@qt-project.org [development-bounces+martin.smith=digia@qt-project.org] on behalf of Thiago Macieira [thiago.macie...@intel.com] Sent: Friday, December 06, 2013 6:25 PM To: development@qt-project.org Subject: Re: [Development] [Request] Compiler warnings in Qt On sexta-feira, 6 de dezembro de 2013 17:18:02, Smith Martin wrote: I get warnings with clang in OSX. It even treats an unused variable as an error. Which makes you fix them, so we don't get warnings in the repository :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Request] Compiler warnings in Qt
On 6 December 2013 19:30, Smith Martin martin.sm...@digia.com wrote: Should I report these warnings in JIRA? Yes, please. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
