Re: [Development] QtDriveInfo module in Playground
On sexta-feira, 1 de março de 2013 11.38.54, Иван Комиссаров wrote: Hello, i would like to request a repository in a playground for my QDriveInfo module. This class allows to retrieve information about a system volumes - like available size, filesystem, filesystem flags and so on. Right now, repo is located here https://gitorious.org/qdrive Also, i'm not sure about the name of a repo - should it be QtDriveInfo, or ышьздн QtDrive (as long as i also have QtDriveController class which can monitor/mount/unmount drives from userspace) PS: There's also exists issue about drive information https://bugreports.qt-project.org/browse/QTBUG-3780 Hello Ivan That project looks too small for a full module. It looks more like a class in QtCore. The controller class does not belong in QtCore, though. -- 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] QtDriveInfo module in Playground
On Fri, Mar 1, 2013 at 8:12 AM, Thiago Macieira thiago.macie...@intel.comwrote: On sexta-feira, 1 de março de 2013 11.38.54, Иван Комиссаров wrote: Hello, i would like to request a repository in a playground for my QDriveInfo module. This class allows to retrieve information about a system volumes - like available size, filesystem, filesystem flags and so on. Right now, repo is located here https://gitorious.org/qdrive Also, i'm not sure about the name of a repo - should it be QtDriveInfo, or ышьздн QtDrive (as long as i also have QtDriveController class which can monitor/mount/unmount drives from userspace) PS: There's also exists issue about drive information https://bugreports.qt-project.org/browse/QTBUG-3780 Hello Ivan That project looks too small for a full module. It looks more like a class in QtCore. +1. Also, I was thinking of a class for cars (automotive) first when reading drive. Perhaps it should use the term filesystem(info) or so instead? Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On 2013-3-1, at 上午9:12, Thiago Macieira wrote: On sexta-feira, 1 de março de 2013 11.38.54, Иван Комиссаров wrote: Hello, i would like to request a repository in a playground for my QDriveInfo module. This class allows to retrieve information about a system volumes - like available size, filesystem, filesystem flags and so on. Right now, repo is located here https://gitorious.org/qdrive Also, i'm not sure about the name of a repo - should it be QtDriveInfo, or ышьздн QtDrive (as long as i also have QtDriveController class which can monitor/mount/unmount drives from userspace) PS: There's also exists issue about drive information https://bugreports.qt-project.org/browse/QTBUG-3780 Hello Ivan That project looks too small for a full module. It looks more like a class in QtCore. The controller class does not belong in QtCore, though. In Qt 4, we have System Information in Mobility. I think they are QtSystems in Qt 5 world. But not sure about the latest status. The monitor/controller for drive should be there, I guess. http://doc.qt.digia.com/qtmobility/systeminfo.html https://codereview.qt-project.org/#admin,project,qt/qtsystems,info Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
Op 1-3-2013 8:38, Иван Комиссаров schreef: Hello, i would like to request a repository in a playground for my QDriveInfo module. This class allows to retrieve information about a system volumes - like available size, filesystem, filesystem flags and so on. Right now, repo is located here https://gitorious.org/qdrive Also, i'm not sure about the name of a repo - should it be QtDriveInfo, or ышьздн QtDrive (as long as i also have QtDriveController class which can monitor/mount/unmount drives from userspace) PS: There's also exists issue about drive information https://bugreports.qt-project.org/browse/QTBUG-3780 Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Or did all that get scrapped in Qt 5? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
Yes, it still exists somewhere in Qt5 code, but it's not maintained and
provides much less functionality compared to QtDriveInfo.
Also, it has flawed API, in my opinion:)
For example, it's hard to implement drive comparison (i.e. if 2 files are on
the same drive or not) using current QSystemStorageInfo API:
QSystemStorageInfo info;
if (info.compareDrives(file1, file2)) {
...
}
looks really awkward. Compare with:
if (QtDriveInfo(file1) == QtDriveInfo(file2)) {
}
This can be useful when you have to choose if you can simply rename file, or
you should use copyremove.
Иван Комиссаров
01.03.2013, в 12:42, André Somers an...@familiesomers.nl написал(а):
Wasn't there already similar functionality in QtMobility?
QSystemStorageInfo seems to provide similar functionality? Or did all
that get scrapped in Qt 5?
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On Fri, Mar 1, 2013 at 8:42 AM, André Somers an...@familiesomers.nl wrote:
Wasn't there already similar functionality in QtMobility?
QSystemStorageInfo seems to provide similar functionality? Or did all
that get scrapped in Qt 5?
Ah, you are both right:
http://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstorageinfo.h
I just tried to build QtSystems against Qt5 (dev), but I am getting build
issues. See the details below. I believe those are fixable, so perhaps Ivan
should check if something is missing? Any plans to bring this back for Qt
5.2 or later?
Actually, since it is not yet released with Qt5, even API issues can be
fixed in there.
Laszlo
=
qdisplayinfo_linux.cpp: In function
'{anonymous}::Q_QGS_BACKLIGHT_SYSFS_PATH::Type*
{anonymous}::Q_QGS_BACKLIGHT_SYSFS_PATH::innerFunction()':
qdisplayinfo_linux.cpp:50:1: error: lambda-expression in unevaluated context
qdisplayinfo_linux.cpp: In lambda function:
qdisplayinfo_linux.cpp:50:1: error: types may not be defined in 'noexcept'
expressions
qdisplayinfo_linux.cpp:50:1: error: 'Size' was not declared in this scope
qdisplayinfo_linux.cpp:50:1: error: template argument 1 is invalid
qdisplayinfo_linux.cpp:50:1: error: invalid type in declaration before '='
token
qdisplayinfo_linux.cpp:50:1: error: scalar object 'qstring_literal'
requires one element in initializer
qdisplayinfo_linux.cpp: In function
'{anonymous}::Q_QGS_GRAPHICS_SYSFS_PATH::Type*
{anonymous}::Q_QGS_GRAPHICS_SYSFS_PATH::innerFunction()':
qdisplayinfo_linux.cpp:51:1: error: lambda-expression in unevaluated context
qdisplayinfo_linux.cpp: In lambda function:
qdisplayinfo_linux.cpp:51:1: error: types may not be defined in 'noexcept'
expressions
qdisplayinfo_linux.cpp:51:1: error: 'Size' was not declared in this scope
qdisplayinfo_linux.cpp:51:1: error: template argument 1 is invalid
qdisplayinfo_linux.cpp:51:1: error: invalid type in declaration before '='
token
qdisplayinfo_linux.cpp:51:1: error: scalar object 'qstring_literal'
requires one element in initializer
make[2]: *** [.obj/debug-shared/qdisplayinfo_linux.o] Error 1
make[2]: Leaving directory
`/home/lpapp/Projects/qt/qtsystems/src/systeminfo'
make[1]: *** [sub-systeminfo-make_first-ordered] Error 2
make[1]: Leaving directory `/home/lpapp/Projects/qt/qtsystems/src'
make: *** [sub-src-make_first-ordered] Error 2
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
I don't think it's a good idea to try to fix QStorageInfo. The main argument is that QStorageInfo is a monitor+info provider, but monitor should depend on a DBus in Linux; however info provider doesn't require that. Also, monitor requires internal thread on Mac. My point is that in many cases, when you doesn't need monitor itself, it's too heavy to create such a huge object just to receive volume info. That's why i separated my solution into 2 different classes; so QtDriveInfo doesn't require external dependencies, like DBus. Next, QStorageInfo notification doesn't work for MingGW and Windows CE. Also QStorageInfo doesn't have internal caching. Иван Комиссаров 01.03.2013, в 12:51, Laszlo Papp lp...@kde.org написал(а): On Fri, Mar 1, 2013 at 8:42 AM, André Somers an...@familiesomers.nl wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Or did all that get scrapped in Qt 5? Ah, you are both right: http://qt.gitorious.org/qt/qtsystems/blobs/master/src/systeminfo/qstorageinfo.h I just tried to build QtSystems against Qt5 (dev), but I am getting build issues. See the details below. I believe those are fixable, so perhaps Ivan should check if something is missing? Any plans to bring this back for Qt 5.2 or later? Actually, since it is not yet released with Qt5, even API issues can be fixed in there. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Mar 1, 2013, at 8:27 AM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: Why are we discussing adding conversion operators from/to native objects in QtCore/QtGui? The methods that did so were removed in Qt 5 in order to increase modularity, why would we go the opposite direction again? The argument for would be along the lines of: We went too far in the name of modularity. Adding conversion operators to QtCore and QtGui makes it easier to mix Qt and native development. It makes Qt better. I'm positive to the idea myself, and so far I haven't seen really convincing arguments against. I don't think adjusting the course of Qt 5 is a big problem. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Copyright changes
Hi all, We would appreciate Your help in one quite trivial task. With a joint effort together it also should be reasonable small task for individual developer. Digia acquired all Nokia's Qt copyrights last year. We have already changed the copyrights in main branches. All non-Nokia copyrights remain unchanged. Next step would correct copyrights to qt-project labs/playground repository codes. Changing these copyrights is not the most urgent task, but we would appreciate Your help to get these corrected within next couple of months. Here is some examples: 1. Copyright (C) 2012 Nokia Corporation and/or its subsidiary(-ies) or something similar with different year. For example in: playground\alignedtimer playground\mimetypes playground\qlogger playground\qtbinaryjson playground\qtjsonstream playground\qtprocessmanager playground\qtsystemtest playground\scenegraph pyside qt-labs\jira2gv qt-labs\messagingframework qt-labs\photoshop-qmlexporter qt-labs\qtaddonmimetype qt-labs\qtest-qml 2. In some repositories company copyright is missing and there is only original author copyright. Example: ** Copyright (C) 2012 Firstname Surname em...@xyz.orgmailto:em...@xyz.org ** Contact: http://www.qt-project.org/ Still inside the License header QT_BEGIN_LICENSE and QT_END_LICENSE tags is the Nokia version, like in: playground\qtaudio3d playground\qtmof playground\qtserialport playground\uihelpers 3. There are repositories where copyright is right, but LGPL_EXCEPTION.txt is Nokia version. Examples: installer-framework\installer-framework playground\qtserialport qt-labs\messagingframework qt-labs\qtest-qml qt-mobility\qt-mobility The correct Copyright text is: Copyright (C) 2013 Digia Plc and/or its subsidiary(-ies) More detailed version on copyright texts below: LGPL: / ** ** Copyright (C) 2013 Digia Plc and/or its subsidiary(-ies). ** Contact: http://www.qt-project.org/legal ** ** This file is part of the XXX module of the Qt. ** ** $QT_BEGIN_LICENSE:LGPL$ ** Commercial License Usage ** Licensees holding valid commercial Qt licenses may use this file in ** accordance with the commercial license agreement provided with the ** Software or, alternatively, in accordance with the terms contained in ** a written agreement between you and Digia. For licensing terms and ** conditions see http://qt.digia.com/licensing. For further information ** use the contact form at http://qt.digia.com/contact-us. ** ** GNU Lesser General Public License Usage ** Alternatively, this file may be used under the terms of the GNU Lesser ** General Public License version 2.1 as published by the Free Software ** Foundation and appearing in the file LICENSE.LGPL included in the ** packaging of this file. Please review the following information to ** ensure the GNU Lesser General Public License version 2.1 requirements ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. ** ** In addition, as a special exception, Digia gives you certain additional ** rights. These rights are described in the Digia Qt LGPL Exception ** version 1.1, included in the file LGPL_EXCEPTION.txt in this package. ** ** GNU General Public License Usage ** Alternatively, this file may be used under the terms of the GNU ** General Public License version 3.0 as published by the Free Software ** Foundation and appearing in the file LICENSE.GPL included in the ** packaging of this file. Please review the following information to ** ensure the GNU General Public License version 3.0 requirements will be ** met: http://www.gnu.org/copyleft/gpl.html. ** ** ** $QT_END_LICENSE$ ** / LGPL-ONLY: / ** ** Copyright (C) 2013 Digia Plc and/or its subsidiary(-ies). ** Contact: http://www.qt-project.org/legal ** ** This file is part of the XXX module of the Qt. ** ** $QT_BEGIN_LICENSE:LGPL-ONLY$ ** GNU Lesser General Public License Usage ** This file may be used under the terms of the GNU Lesser ** General Public License version 2.1 as published by the Free Software ** Foundation and appearing in the file LICENSE.LGPL included in the ** packaging of this file. Please review the following information to ** ensure the GNU Lesser General Public License version 2.1 requirements ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. ** ** If you have questions regarding the use of this file, please contact ** us via http://www.qt-project.org/. ** ** $QT_END_LICENSE$ ** / BSD: / ** ** Copyright (C) 2013 Digia Plc and/or its subsidiary(-ies). ** Contact: http://www.qt-project.org/legal
Re: [Development] Qt Creator build fails
On Friday 01 March 2013 18:57:47 Majid Khan wrote: I have recently updated my local repo for Qt Creator and its failing now, :-1: error: No rule to make target `../../../qt-creator/share/qtcreator/templates/wizards/bb-qt5-quick2app/bar- descriptor.xml', needed by `templates/wizards/bb-qt5-quick2app/bar-descriptor.xml'. Stop. Is there anything that I need to do in order to build it? It was building alright before this update, Last update before this was yesterday. Re-running qmake should solve that problem. That wizard got removed recently. Regards, Tobias -- Tobias Nätterlund | tobias.naetterl...@kdab.com | 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
Re: [Development] Qt Platform Extras
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 on their corresponding Qt types, which I can think of off the top of my head: Windows: POINT RECT HICON HBITMAP Darwin (OS X + iOS): CGPoint CGSize CGRect NSPoint NSSize NSRect CGImageRef CIImage NSImage NSString and CFArrayRef/NSArray - QListT ? I'm not sure about other platforms/environments like X11, Wayland, or perhaps GNOME. Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Mar 1, 2013, at 4:24 AM, Sorvig Morten morten.sor...@digia.com wrote: On Mar 1, 2013, at 8:27 AM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: Why are we discussing adding conversion operators from/to native objects in QtCore/QtGui? The methods that did so were removed in Qt 5 in order to increase modularity, why would we go the opposite direction again? The argument for would be along the lines of: We went too far in the name of modularity. Adding conversion operators to QtCore and QtGui makes it easier to mix Qt and native development. It makes Qt better. I'm positive to the idea myself, and so far I haven't seen really convincing arguments against. I don't think adjusting the course of Qt 5 is a big problem. Morten ___ 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
Re: [Development] Qt Creator build fails
Great! Thanks :) On Fri, Mar 1, 2013 at 8:33 PM, Tobias Nätterlund tobias.naetterl...@kdab.com wrote: On Friday 01 March 2013 18:57:47 Majid Khan wrote: I have recently updated my local repo for Qt Creator and its failing now, :-1: error: No rule to make target `../../../qt-creator/share/qtcreator/templates/wizards/bb-qt5-quick2app/bar- descriptor.xml', needed by `templates/wizards/bb-qt5-quick2app/bar-descriptor.xml'. Stop. Is there anything that I need to do in order to build it? It was building alright before this update, Last update before this was yesterday. Re-running qmake should solve that problem. That wizard got removed recently. Regards, Tobias -- Tobias Nätterlund | tobias.naetterl...@kdab.com | 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 -- Majid Khan http://www.icplusplus.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On Friday 01 March 2013 08:51:16 Laszlo Papp wrote:
qdisplayinfo_linux.cpp: In function
'{anonymous}::Q_QGS_BACKLIGHT_SYSFS_PATH::Type*
{anonymous}::Q_QGS_BACKLIGHT_SYSFS_PATH::innerFunction()':
qdisplayinfo_linux.cpp:50:1: error: lambda-expression in unevaluated context
qdisplayinfo_linux.cpp:50 is:
Q_GLOBAL_STATIC_WITH_ARGS(const QString, BACKLIGHT_SYSFS_PATH,
(QStringLiteral(/sys/class/backlight/)))
And the new Q_GLOBAL_STATIC implementation does:
[...]Holder()\
Q_DECL_NOEXCEPT_EXPR(noexcept(Type ARGS)) \
: value ARGS\
QStringLiteral is implemented using labda expression to get an anonymous
scope. But lambda sexpression are not allowed in noexcept.
Is that something we should fix in Q_GLOBAL_STATIC_WITH_ARGS ? or should we
jsut say that lambda expressions or QStringLiteral are not allowed in
Q_GLOBAL_STATIC_WITH_ARGS ?
--
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] QtDriveInfo module in Playground
Op 1-3-2013 10:22, ?? schreef: I don't think it's a good idea to try to fix QStorageInfo. The main argument is that QStorageInfo is a monitor+info provider, but monitor should depend on a DBus in Linux; however info provider doesn't require that. Also, monitor requires internal thread on Mac. My point is that in many cases, when you doesn't need monitor itself, it's too heavy to create such a huge object just to receive volume info. I don't find that a convincing argument. The implementation could be such, that the heavy machinery is only instantiated when somebody actually connects to the monitoring signals. We have connectNotify and disconnectNotify available for that in QObject. That's why i separated my solution into 2 different classes; so QtDriveInfo doesn't require external dependencies, like DBus. I think I would prefer to have the controls and notification signals directly on the QDriveInfo class itself. That seems to be more consistent with the rest of the Qt API, where I can't think of other examples of a separate controller class. Next, QStorageInfo notification doesn't work for MingGW and Windows CE. Also QStorageInfo doesn't have internal caching. I am not saying that I think your classes look bad in any way. In fact, I think they look pretty neat! I do have my doubts about the refresh() method. Isn't there any way to automatically refresh without getting it too expensive? Thanks for your efforts so far! André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copyright changes
On Fri, Mar 01, 2013 at 09:28:13AM +, Hirvonen Olli wrote: 1. Copyright (C) 2012 Nokia Corporation and/or its subsidiary(-ies) or something similar with different year. For example in: several of these repositories are just dead (and will soon be moved and marked as such once we figure out which ones exactly these are). does it still make sense to adjust copyrights in these? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Mar 1, 2013, at 10:37 AM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: I suppose it would not be a detriment. Where do you draw the line? Which platforms, what functions and types? I would leave that decision to the platform maintainers. An initial minimal set would be good though, for example OS X/iOS and windows. Here are some candidate types for constructors and conversion operators on their corresponding Qt types, which I can think of off the top of my head: Windows: POINT RECT HICON HBITMAP Darwin (OS X + iOS): CGPoint CGSize CGRect NSPoint NSSize NSRect CGImageRef CIImage NSImage NSString and CFArrayRef/NSArray - QListT ? Seems like a good list to me. I would wait with the last one.. NSArray is really QListQVariant. I'm not sure about other platforms/environments like X11, Wayland, or perhaps GNOME. It does require a Q_OS define, so it might not make sense for those platforms. Morten ___ 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] Copyright changes
On Fri, Mar 1, 2013 at 9:28 AM, Hirvonen Olli olli.hirvo...@digia.comwrote: **2. **In some repositories company copyright is missing and there is only original author copyright. Example: ** Copyright (C) 2012 Firstname Surname em...@xyz.org ** Contact: http://www.qt-project.org/ Is that wrong? What if no one pays someone to work on a change? Also, perhaps you could make a qtqa checker script for these, run them, and publish the result so we can see the issues at a centralized place? For instance, we meant to fix everything in QtSerialPort a while ago, so I am wondering why it is still on your list. I guess this is a generic issue. Perhaps there could be a license checker bot, or just directly integrated into an existing bot like the sanity/doc checker? Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
2013/3/1 André Somers an...@familiesomers.nl: Op 1-3-2013 10:22, Иван Комиссаров schreef: I don't think it's a good idea to try to fix QStorageInfo. The main argument is that QStorageInfo is a monitor+info provider, but monitor should depend on a DBus in Linux; however info provider doesn't require that. Also, monitor requires internal thread on Mac. My point is that in many cases, when you doesn't need monitor itself, it's too heavy to create such a huge object just to receive volume info. I don't find that a convincing argument. The implementation could be such, that the heavy machinery is only instantiated when somebody actually connects to the monitoring signals. We have connectNotify and disconnectNotify available for that in QObject. That's why i separated my solution into 2 different classes; so QtDriveInfo doesn't require external dependencies, like DBus. I think I would prefer to have the controls and notification signals directly on the QDriveInfo class itself. That seems to be more consistent with the rest of the Qt API, where I can't think of other examples of a separate controller class. Consistent with what API? To me, QDriveInfo is just like QFileInfo (incl. the ability to control the cache) and the monitor is just like QFileSystemWatcher that can send you a changed/added/removed driveinfo (ideally, the user will be notified *before* the drive has been removed and will be able to decline dismounting from the slot -- that's easily doable on win, dunno about other systems). Next, QStorageInfo notification doesn't work for MingGW and Windows CE. Also QStorageInfo doesn't have internal caching. I am not saying that I think your classes look bad in any way. In fact, I think they look pretty neat! I do have my doubts about the refresh() method. Isn't there any way to automatically refresh without getting it too expensive? Same approach as QFileInfo has. regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
Op 1-3-2013 11:52, Konstantin Ritt schreef: 2013/3/1 André Somers an...@familiesomers.nl: Op 1-3-2013 10:22, Иван Комиссаров schreef: I don't think it's a good idea to try to fix QStorageInfo. The main argument is that QStorageInfo is a monitor+info provider, but monitor should depend on a DBus in Linux; however info provider doesn't require that. Also, monitor requires internal thread on Mac. My point is that in many cases, when you doesn't need monitor itself, it's too heavy to create such a huge object just to receive volume info. I don't find that a convincing argument. The implementation could be such, that the heavy machinery is only instantiated when somebody actually connects to the monitoring signals. We have connectNotify and disconnectNotify available for that in QObject. That's why i separated my solution into 2 different classes; so QtDriveInfo doesn't require external dependencies, like DBus. I think I would prefer to have the controls and notification signals directly on the QDriveInfo class itself. That seems to be more consistent with the rest of the Qt API, where I can't think of other examples of a separate controller class. Consistent with what API? To me, QDriveInfo is just like QFileInfo (incl. the ability to control the cache) and the monitor is just like QFileSystemWatcher that can send you a changed/added/removed driveinfo That's true, indeed. I did not think about QFileInfo (even though that's not my favourite part of the Qt API). André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
2013/3/1 Иван Комиссаров abba...@gmail.com: 01.03.2013, в 13:54, André Somers an...@familiesomers.nl написал(а): Op 1-3-2013 10:22, Иван Комиссаров schreef: I don't think it's a good idea to try to fix QStorageInfo. The main argument is that QStorageInfo is a monitor+info provider, but monitor should depend on a DBus in Linux; however info provider doesn't require that. Also, monitor requires internal thread on Mac. My point is that in many cases, when you doesn't need monitor itself, it's too heavy to create such a huge object just to receive volume info. I don't find that a convincing argument. The implementation could be such, that the heavy machinery is only instantiated when somebody actually connects to the monitoring signals. We have connectNotify and disconnectNotify available for that in QObject. The argument is that you can't use QStorageInfo class from QtCore itself or an application that uses only QtCore. You're forced to use external dependencies right now, while QDriveInfo class is must-have class for IO operations (you can check if there's enough space on a hard drive before copying file to if). Linking to DBus for that... hm... Not a best example, I can find some better ones ;) The three ones I need most often: 1. if (QDriveInfo(from) == QDriveInfo(to)) QFile::move(from, to); else QFile::copy(from, to); handles the symlinks, mounpoints and junction points as well 2. if (QDriveInfo(path).capabilities() ... ) -- one can check if the specified path belongs to a volume with filesystem that supports case sensitive names, symlinks, or hardlinks, w/o having to *guess*. 3. if (QDriveInfo(path).type() == QDriveInfo::RemoteDrive) /* VFS */; else /* Local */; That's why i separated my solution into 2 different classes; so QtDriveInfo doesn't require external dependencies, like DBus. I think I would prefer to have the controls and notification signals directly on the QDriveInfo class itself. That seems to be more consistent with the rest of the Qt API, where I can't think of other examples of a separate controller class. What about QFile/QFileInfo separation?:) Next, QStorageInfo notification doesn't work for MingGW and Windows CE. Also QStorageInfo doesn't have internal caching. I am not saying that I think your classes look bad in any way. In fact, I think they look pretty neat! I do have my doubts about the refresh() method. Isn't there any way to automatically refresh without getting it too expensive? So far, i didn't find any solution for that... Thanks for your efforts so far! André ___ 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copyright changes
I discussed with Tuukka Turunen and his opinion was that even something is not developed further, but it is available, copyrights should be the correct ones. But as said this is not the most urgent issue and priority is low. And sorry if the examples I used were fixed already. I got those examples from Janne Anttila over a month ago and this was just pending in my emails :/ I hope that someone more technical person could reply to Laszlo if license checker bot would be possible or a good idea? -Olli -Original Message- From: Of Oswald Buddenhagen On Fri, Mar 01, 2013 at 09:28:13AM +, Hirvonen Olli wrote: 1. Copyright (C) 2012 Nokia Corporation and/or its subsidiary(-ies) or something similar with different year. For example in: several of these repositories are just dead (and will soon be moved and marked as such once we figure out which ones exactly these are). does it still make sense to adjust copyrights in these? --- Laszlo wrote: ** Copyright (C) 2012 Firstname Surname em...@xyz.org ** Contact: http://www.qt-project.org/ Is that wrong? What if no one pays someone to work on a change? Also, perhaps you could make a qtqa checker script for these, run them, and publish the result so we can see the issues at a centralized place? For instance, we meant to fix everything in QtSerialPort a while ago, so I am wondering why it is still on your list. I guess this is a generic issue. Perhaps there could be a license checker bot, or just directly integrated into an existing bot like the sanity/doc checker? Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copyright changes
tests/prebuild/license in qtqa repo is just for that purpose though I am not sure how it got run on every qt5 module repo. http://qt.gitorious.org/qt/qtqa/trees/master/tests/prebuild/license Regards, Liang On 2013-3-1, at 下午12:24, Hirvonen Olli wrote: I discussed with Tuukka Turunen and his opinion was that even something is not developed further, but it is available, copyrights should be the correct ones. But as said this is not the most urgent issue and priority is low. And sorry if the examples I used were fixed already. I got those examples from Janne Anttila over a month ago and this was just pending in my emails :/ I hope that someone more technical person could reply to Laszlo if license checker bot would be possible or a good idea? -Olli ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Creator Debug - GDB error
I am trying to debug Qt Creator (working on #7044) but when I debug (its new linux mint 14 Nadia Cinammon) my gdb gives error Starting executable failed: /home/majid/projects/qtcreator-build/bin/qtcreator.sh: not in executable format: File format not recognised but all other pet projects build alright in debug mode. Can someone please help? -- Majid Khan http://www.icplusplus.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Creator Debug - GDB error
Thanks, ptrace: Operation not permitted. Could not attach to the process. Make sure no other debugger traces this process. Check the settings of /proc/sys/kernel/yama/ptrace_scope For more details, see /etc/sysctl.d/10-ptrace.conf and contents of file: kernel.yama.ptrace_scope = 1 On Sat, Mar 2, 2013 at 1:10 AM, Poenitz Andre andre.poen...@digia.comwrote: Majid Khan wrote: I am trying to debug Qt Creator (working on #7044) but when I debug (its new linux mint 14 Nadia Cinammon) my gdb gives error Starting executable failed: /home/majid/projects/qtcreator-build/bin/qtcreator.sh: not in executable format: File format not recognised That's the wrong run configuration (the one for the wrapper script, not the application itself). Select 'app', not 'bin' in the Target selector or under Projects/Run Run configuration. Andre' -- Majid Khan http://www.icplusplus.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Creator Debug - GDB error
Great! Thanks :) On Sat, Mar 2, 2013 at 1:34 AM, Mitch Curtis mitch.cur...@digia.com wrote: On 03/01/2013 03:20 PM, Majid Khan wrote: Thanks, ptrace: Operation not permitted. Could not attach to the process. Make sure no other debugger traces this process. Check the settings of /proc/sys/kernel/yama/ptrace_scope For more details, see /etc/sysctl.d/10-ptrace.conf and contents of file: kernel.yama.ptrace_scope = 1 This is a known issue: https://bugreports.qt-project.org/browse/QTCREATORBUG-3509 Feel free to vote for it. :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Majid Khan http://www.icplusplus.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On sexta-feira, 1 de março de 2013 10.52.41, Olivier Goffart wrote:
qdisplayinfo_linux.cpp:50 is:
Q_GLOBAL_STATIC_WITH_ARGS(const QString, BACKLIGHT_SYSFS_PATH,
(QStringLiteral(/sys/class/backlight/)))
Is that something we should fix in Q_GLOBAL_STATIC_WITH_ARGS ? or should
we jsut say that lambda expressions or QStringLiteral are not allowed in
Q_GLOBAL_STATIC_WITH_ARGS ?
It's just too much overhead the way it's written. It's much simpler as:
static QString backlightSysfsPath()
{
return QStringLiteral(/sys/class/backlight/);
}
QStringLiteral is optimised for that case.
--
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] magic number 0xf291
On sexta-feira, 1 de março de 2013 16.43.35, Joerg Bornemann wrote:
In qprocess_win.cpp there's this code for determining if the child
process crashed or not.
//### for now we assume a crash if exit code is less than -1 or the
magic number
crashed = (exitCode == 0xf291 || (int)exitCode 0);
Does anybody have an idea where this magic number 0xf291 comes from?
I cannot find it anywhere in the Windows headers. Neither can I produce
a crashing application that returns this code.
Hint: it is not the exit code for unsatisfied DLL dependencies.
That's STATUS_DLL_NOT_FOUND.
The value reappears:
void QProcessPrivate::killProcess()
{
if (pid)
TerminateProcess(pid-hProcess, 0xf291);
}
--
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] magic number 0xf291
On 01/03/2013 16:47, Pau Garcia i Quiles wrote: http://stackoverflow.com/questions/9187021/c-application-exit-error-code-62097-what-does-that-mean It means memory allocation failed. Yeah I also found this comment but I cannot make my memory allocator fail in a way that I get this exit code. When an MSVC program crashes, a first class exception is thrown. Every exception has a numerical code. This numerical code is used as exit code. And those codes have proper defines like EXCEPTION_ACCESS_VIOLATION. Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] magic number 0xf291
On 01/03/2013 16:53, Thiago Macieira wrote:
The value reappears:
void QProcessPrivate::killProcess()
{
if (pid)
TerminateProcess(pid-hProcess, 0xf291);
}
Oh it's Qt's magic number, no Windows sorcery. That explains it.
Thanks,
Joerg
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] magic number 0xf291
On Fri, Mar 1, 2013 at 4:59 PM, Joerg Bornemann joerg.bornem...@digia.comwrote: On 01/03/2013 16:47, Pau Garcia i Quiles wrote: http://stackoverflow.com/**questions/9187021/c-** application-exit-error-code-**62097-what-does-that-meanhttp://stackoverflow.com/questions/9187021/c-application-exit-error-code-62097-what-does-that-mean It means memory allocation failed. Yeah I also found this comment but I cannot make my memory allocator fail in a way that I get this exit code. When an MSVC program crashes, a first class exception is thrown. Every exception has a numerical code. This numerical code is used as exit code. And those codes have proper defines like EXCEPTION_ACCESS_VIOLATION. That error code is there at least since Qt 3. Is the history for that code available? The obvious solution seems to be to ask to whoever wrote that 10 years ago -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On 01/03/13 18:42, André Somers wrote: Op 1-3-2013 8:38, Иван Комиссаров schreef: Hello, i would like to request a repository in a playground for my QDriveInfo module. This class allows to retrieve information about a system volumes - like available size, filesystem, filesystem flags and so on. Right now, repo is located here https://gitorious.org/qdrive Also, i'm not sure about the name of a repo - should it be QtDriveInfo, or ышьздн QtDrive (as long as i also have QtDriveController class which can monitor/mount/unmount drives from userspace) PS: There's also exists issue about drive information https://bugreports.qt-project.org/browse/QTBUG-3780 Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. -- Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On 01/03/13 18:50, Иван Комиссаров wrote:
Yes, it still exists somewhere in Qt5 code, but it's not maintained and
provides much less functionality compared to QtDriveInfo.
wrong. it is maintained. by me. or rather, has a maintainer. I haven't
seen any bug reports or code reviews for it.
There's this though:
https://codereview.qt-project.org/#change,17698
Also, it has flawed API, in my opinion:)
For example, it's hard to implement drive comparison (i.e. if 2 files are on
the same drive or not) using current QSystemStorageInfo API:
QSystemStorageInfo info;
if (info.compareDrives(file1, file2)) {
...
}
looks really awkward. Compare with:
if (QtDriveInfo(file1) == QtDriveInfo(file2)) {
}
so its better to instantiate two instances of a class instead of one,
just to see if its on the same drive?
This can be useful when you have to choose if you can simply rename file, or
you should use copyremove.
Иван Комиссаров
01.03.2013, в 12:42, André Somers an...@familiesomers.nl написал(а):
Wasn't there already similar functionality in QtMobility?
QSystemStorageInfo seems to provide similar functionality? Or did all
that get scrapped in Qt 5?
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
--
Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. -- 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] QtDriveInfo module in Playground
On 01/03/13 19:54, André Somers wrote: Op 1-3-2013 10:22, Иван Комиссаров schreef: I don't think it's a good idea to try to fix QStorageInfo. The main argument is that QStorageInfo is a monitor+info provider, but monitor should depend on a DBus in Linux; however info provider doesn't require that. Also, monitor requires internal thread on Mac. My point is that in many cases, when you doesn't need monitor itself, it's too heavy to create such a huge object just to receive volume info. I don't find that a convincing argument. The implementation could be such, that the heavy machinery is only instantiated when somebody actually connects to the monitoring signals. We have connectNotify and disconnectNotify available for that in QObject. It already uses those classes. That's why i separated my solution into 2 different classes; so QtDriveInfo doesn't require external dependencies, like DBus. I think I would prefer to have the controls and notification signals directly on the QDriveInfo class itself. That seems to be more consistent with the rest of the Qt API, where I can't think of other examples of a separate controller class. Next, QStorageInfo notification doesn't work for MingGW and Windows CE. Also QStorageInfo doesn't have internal caching. I am not saying that I think your classes look bad in any way. In fact, I think they look pretty neat! I do have my doubts about the refresh() method. Isn't there any way to automatically refresh without getting it too expensive? Thanks for your efforts so far! André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On 01/03/13 20:50, Иван Комиссаров wrote: 01.03.2013, в 13:54, André Somers an...@familiesomers.nl написал(а): Op 1-3-2013 10:22, Иван Комиссаров schreef: I don't think it's a good idea to try to fix QStorageInfo. The main argument is that QStorageInfo is a monitor+info provider, but monitor should depend on a DBus in Linux; however info provider doesn't require that. Also, monitor requires internal thread on Mac. My point is that in many cases, when you doesn't need monitor itself, it's too heavy to create such a huge object just to receive volume info. I don't find that a convincing argument. The implementation could be such, that the heavy machinery is only instantiated when somebody actually connects to the monitoring signals. We have connectNotify and disconnectNotify available for that in QObject. The argument is that you can't use QStorageInfo class from QtCore itself or an application that uses only QtCore. You're forced to use external dependencies right now, while QDriveInfo class is must-have class for IO operations (you can check if there's enough space on a hard drive before copying file to if). Linking to DBus for that... hm... see my answer below. That's why i separated my solution into 2 different classes; so QtDriveInfo doesn't require external dependencies, like DBus. storageinfo does not _require_ dbus. It uses udisks by dbus if _available_. I think I would prefer to have the controls and notification signals directly on the QDriveInfo class itself. That seems to be more consistent with the rest of the Qt API, where I can't think of other examples of a separate controller class. What about QFile/QFileInfo separation?:) Next, QStorageInfo notification doesn't work for MingGW and Windows CE. Do any substantial number of people actually use Qt on Windows CE? There is a version of mingw that WMI should work on: MinGW64 I haven't tried it. Also QStorageInfo doesn't have internal caching. I am not saying that I think your classes look bad in any way. In fact, I think they look pretty neat! I do have my doubts about the refresh() method. Isn't there any way to automatically refresh without getting it too expensive? So far, i didn't find any solution for that... Thanks for your efforts so far! André ___ 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 -- Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On 02/03/13 07:59, Thiago Macieira wrote: On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. systeminfo works on all platforms, mobile or not. The udisks functionality would have to be removed if moved to core. -- Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDriveInfo module in Playground
On sábado, 2 de março de 2013 08.20.35, Lorn Potter wrote: systeminfo works on all platforms, mobile or not. I want the QtCore solution to work on all platforms too. I just want less emphasis on mobile (and especially Symbian-inspired) features and more focus on general use-cases. The udisks functionality would have to be removed if moved to core. Why? -- 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] submitting a multi-dimensional container class for Qt: QNDArray
Hello, On Wednesday 9 January 2013 Thiago Macieira wrote: I'm not sure it's out of scope for Qt. In fact, I don't know yet whether it should be part of Qt Core or not. I guess I am the person to make that particular call. So what I need from Glen is, at least, the proposed API docs with some proposed examples of how it will work. I need to review that to decide whether it fits Qt Core's purpose in life. snip To be accepted in QtCore, the contribution must be of a handful[*] of files in src/corelib/tools, including the documentation, with examples in examples/, tests in tests/auto/corelib/tools/qndarray. [*] by handful, I mean it literally: counted with the fingers of one hand. And I do not mean binary counting (2⁵ = 32 files). Yes, well there certainly are still quite a few files in this patch (perhaps it's more like a new shed than a patch), although I *have* consolidated several files together in the commit that I made a few minutes ago. I suppose that when I first brought up this concept, many of you envisioned a single header file and one or two .cpp files. That's funny because it's the same thing *I* envisioned when I started working on this effort some number of years ago. ;-) I didn't think it would be that hard to replicate in C++ the basic operations (yeah, I'll just stick with the basic operations, and it won't be too bad or take too long) available on numpy.ndarray class instances -- you've got to keep track of shape and strides, index appropriately, and provide a few mathematical operations. Famous last words. Anyway, as I contemplated Thiago's formal request for API docs, I concluded that this effort has become complicated enough that a quick cursory explanation would not do justice to the complexity of the implementation. At least, I think that the code has gotten progressively complicated, in order to cover the basic modes of operation that numpy provides. And without an ernest explanation of how it all fits together, I think that I would continue to meet with this patch is way to big or this patch has way too many files or I don't understand why you're submitting this to Qt. Now, I realize that there are situations where these answers are valid reasons for rejecting a patch, and I'm under no illusion that my efforts might yet be excluded from Qt; my current objective is still to just explain what I've done. To that end, I began formalizing the documentation into real .qdoc files (no, it's not finished yet -- it's still a WIP). Most notably, I have pushed numeric.qdoc which gives an explanation from the very beginning and tries to define all of the QNDArray-specific terms for the user (actually, they are numpy terms). So, I sincerely hope that several of you on this list will build and read the docs I have written -- I look forward to hearing what you think. Best Regards, Glen Mabey P.S. Yes, I have pushed these files to the dev branch prior to the cutoff date for 5.1, but no, I do not intend to request that it be merged for the 5.1 release -- it's still a WIP. P.P.S. Yes, I am certainly open to consolidating more of the source files -- I am very happy to receive specific feedback on this issue. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copyright changes
On Fri, Mar 1, 2013 at 9:29 PM, Qi Liang liang...@digia.com wrote: tests/prebuild/license in qtqa repo is just for that purpose though I am not sure how it got run on every qt5 module repo. http://qt.gitorious.org/qt/qtqa/trees/master/tests/prebuild/license The license header checker autotest is used by the CI system. You can also run it manually before you commit changes. For example, if I want to manually check qtdeclarative, I do: cd ~/dev/qt5 QT_MODULE_TO_TEST=qtdeclarative qtqa/tests/prebuild/tst_licenses.pl Things to note about the autotest: * It checks that the first few lines of the header match the predefined patterns. The old Nokia copyright line still matches the acceptable pattern, so the script won't complain about those. I can probably fix that if there's sufficient interest. * It checks the text inside the QT_BEGIN_LICENSE/QT_END_LICENSE markers against the reference copies in qtbase/LICENSE.*, so you need to have qtbase in your tree with the correct branch checked out as well as qtqa and the module you want to check. * For each file checked, the script will print a line beginning with ok or not ok depending on the result. When not ok, it will also print some detail about why it failed. For those in Digia, you may also want to have a look in the old non-public mkdist repo which contained the packaging scripts for Qt4.x. In that repo there's a script called bin/replace-licenses.zsh and a small Qt program called replacetags (or maybe replace-tags) that the script calls. This can be used to automatically update the text between the QT_BEGIN_LICENSE and QT_END_LICENSE markers to the current version for the corresponding license type. The script was originally written by Thiago and I later enhanced it to handle license headers in non-C++ files and those embedded inside string literals in programs that generate other source files. (There is one file the script doesn't work on: qtbase/tests/auto/tools/moc/os9-newlines.h. That files has to be carefully updated with a hex editor when the license text changes.) I'd suggest moving that script into the qtqa module and making it use the reference text in qtbase/LICENSE.* instead of the (by now very stale) copies in mkdist. If nobody in Digia has the time to do this, I can do it, but someone in Digia would need to get permission to give me a copy of the code because mkdist was never made public. -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copyright changes
On sábado, 2 de março de 2013 10.27.24, Jason McDonald wrote: * For each file checked, the script will print a line beginning with ok or not ok depending on the result. When not ok, it will also print some detail about why it failed. If you don't want to see the ok / not ok lines, simply redirect stdout to /dev/null. The reasons why it failed are printed on stderr. -- 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] Copyright changes
On Sat, Mar 2, 2013 at 12:27 AM, Jason McDonald macadd...@gmail.com wrote: cd ~/dev/qt5 QT_MODULE_TO_TEST=qtdeclarative qtqa/tests/prebuild/tst_licenses.pl bash: qtqa/tests/prebuild/tst_licenses.pl: No such file or directory I will take you meant QT_MODULE_TO_TEST=qtdeclarative qtqa/tests/prebuild/license/tst_licenses.pl Yeah, I used this script earlier, but I did not know it is already integrated into the CI. Couldn't this be integrated into a bot rather than CI? It would be nice to know even before pressing the staging button. It does not seem to run long either. * It checks the text inside the QT_BEGIN_LICENSE/QT_END_LICENSE markers against the reference copies in qtbase/LICENSE.*, so you need to have qtbase in your tree with the correct branch checked out as well as qtqa and the module you want to check. Yes, and that is likely the problem for several modules aforementioned unless they copy those into the qt5. However, that is not a clean solution either. Perhaps, qtqa should have the license headers stored on its own, and once there is a need to change it, it is changed there. Then, qtbase and others should be sync'd to that. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Failure in tst_qwidget
Hi all! The CI bot reported a failure in tst_qwidget when merging https://codereview.qt-project.org/#change,42990,patchset=8 (see the last comment from Qt Continuous Integration System). I can reproduce the same failure under ubuntu 13.04 running XFCE. Then I removed my patch (by checking out an older version of the dev branch, c65ecc50ae4c322294f01685a2b2d2a748a9c940), and ran make clean from the qtbase root directory. After having rebuild everything (by just running make), I tried running the tst_qwidget again, but I still get the same failure. Interestingly, the failure does not occur if I run the individual test which is failing (both with my patch and without): tests/auto/widgets/kernel/qwidget$ ./tst_qwidget showHideShowX11 * Start testing of tst_QWidget * Config: Using QTest library 5.1.0, Qt 5.1.0 PASS : tst_QWidget::initTestCase() PASS : tst_QWidget::showHideShowX11() PASS : tst_QWidget::cleanupTestCase() Totals: 3 passed, 0 failed, 0 skipped * Finished testing of tst_QWidget * So, I wonder: 1) Did I take to correct steps to rebuild qtbase? 2) Did someone else experience this failure as well? Or is it definitely related to my patch? 3) Any idea why the individual test works? Could it be a WM timing issue? TIA, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
