Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by close button
On 13 Sep 2013, at 7:53 AM, Duan Fugang-B38611 wrote: Hi, all, We use the X.Org X Server 1.14.0 + QT4.8.5 to do one demo, but I catch one issue: multi-touch message is not handled by “close” button. I use egalax touchscreen for the multi-touch test. After kernel up, evtest test the multi-touch message, all pass. Use xinput to do the test, also pass. Open one QT app, all multi-touch message can be processed, but the window of the app cannot be closed by click the “X” in the right-up region. I test GNOME destop with the same kernel, any apps’ window can be closed. So, It is strange, maybe it is KDE issue for multi-touch ? Any response is appreciative. This X button is the one provided by the window manager, right? If you are running KDE then it must be kwin. (Which is probably still using Qt 4) But it probably relies on mouse emulation at some level to detect pressing that button. Maybe the egalax driver or the X server does it, so that any legacy X11 apps will work. (You can try really old X apps that definitely don't support touch, like xman, xmessage etc.) If you have a widget-based application with a QPushButton, or a qml application with a MouseArea, can you press those via the touchscreen? because they also need to get mouse events rather than touch events (so far). Which driver is the X server using for the touchscreen? (check /var/log/Xorg.0.log) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by close button
From: Rutledge Shawn shawn.rutle...@digia.com Data: Friday, September 13, 2013 2:48 PM Which driver is the X server using for the touchscreen? (check /var/log/Xorg.0.log) ___ Shawn, thanks for your response. I have attached the Xorg log. Thanks, Andy Xorg.0.log Description: Xorg.0.log ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by close button
From: Rutledge Shawn shawn.rutle...@digia.com Data: Friday, September 13, 2013 2:48 PM We use the X.Org X Server 1.14.0 + QT4.8.5 to do one demo, but I catch one issue: multi-touch message is not handled by close button. I use egalax touchscreen for the multi-touch test. After kernel up, evtest test the multi-touch message, all pass. Use xinput to do the test, also pass. Open one QT app, all multi-touch message can be processed, but the window of the app cannot be closed by click the X in the right-up region. I test GNOME destop with the same kernel, any apps' window can be closed. So, It is strange, maybe it is KDE issue for multi-touch ? Any response is appreciative. This X button is the one provided by the window manager, right? Yes, I think any QT app windows are managed by window manager. If you are running KDE then it must be kwin. (Which is probably still using Qt 4) But it probably relies on mouse emulation at some level to detect pressing that button. From Xorg.0.log: [360470.340] (II) evdev: eGalax Touch Screen: No buttons found, faking one. The Linux egalax driver don't report button event. Close window of apps need BTN_TOUCH event ? The current egalax driver support multitouch events: root@ /# mtdev-test /dev/input/event0 supported mt events: ABS_MT_TOUCH_MAJOR ABS_MT_WIDTH_MAJOR ABS_MT_POSITION_X ABS_MT_POSITION_Y ABS_MT_TRACKING_ID Maybe the egalax driver or the X server does it, so that any legacy X11 apps will work. (You can try really old X apps that definitely don't support touch, like xman, xmessage etc.) If you have a widget-based application with a QPushButton, or a qml application with a MouseArea, can you press those via the touchscreen? because they also need to get mouse events rather than touch events (so far). Which driver is the X server using for the touchscreen? (check /var/log/Xorg.0.log) ___ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by close button
From: Rutledge Shawn shawn.rutle...@digia.com Data: Friday, September 13, 2013 2:48 PM To: development@qt-project.org Subject: Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by close button Importance: High On 13 Sep 2013, at 7:53 AM, Duan Fugang-B38611 wrote: Hi, all, We use the X.Org X Server 1.14.0 + QT4.8.5 to do one demo, but I catch one issue: multi-touch message is not handled by close button. I use egalax touchscreen for the multi-touch test. After kernel up, evtest test the multi-touch message, all pass. Use xinput to do the test, also pass. Open one QT app, all multi-touch message can be processed, but the window of the app cannot be closed by click the X in the right-up region. I test GNOME destop with the same kernel, any apps' window can be closed. So, It is strange, maybe it is KDE issue for multi-touch ? Any response is appreciative. This X button is the one provided by the window manager, right? If you are running KDE then it must be kwin. (Which is probably still using Qt 4) The KDE is not kwin, is matchbox-window-manager. But it probably relies on mouse emulation at some level to detect pressing that button. Maybe the egalax driver or the X server does it, so that any legacy X11 apps will work. (You can try really old X apps that definitely don't support touch, like xman, xmessage etc.) If you have a widget-based application with a QPushButton, or a qml application with a MouseArea, can you press those via the touchscreen? because they also need to get mouse events rather than touch events (so far). Which driver is the X server using for the touchscreen? (check /var/log/Xorg.0.log) ___ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New SceneGraph related issue
Ok, that stack trace doesn't tell me much as the interesting parameters are
optimized out :/
If this was a general bug, I suspect the issue would be present in a lot of
places though, so my immediate reaction is to point towards the emulator :) You
can compare the buffer size used in uploadBatches() to the offsets and sizes
used in the renderMergedBatch() function, but from what I can see, they are all
correct.
There is no way to disable optimizations or use the old renderer. The new logic
is here to stay.
cheers,
Gunnar
Fra: Tomasz Olszak [olszak.tom...@gmail.com]
Sendt: 12. september 2013 18:53
To: Sletta Gunnar
Cc: development@qt-project.org
Emne: Re: [Development] New SceneGraph related issue
I got stracktrace. It is as you predicted glDrwaElements. Is there any
possibility to make some kind of workaround patch to make it work on emulator
(I suppose it is emulator GL issue), perhabs by turning off some optimizations
and so on? I would like to add such patch to rpm emulator package until problem
will be fixed.
#0 0xb7fe1424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb69a0cc1 in raise () from /lib/libc.so.6
No symbol table info available.
#2 0xb69a40ee in abort () from /lib/libc.so.6
No symbol table info available.
#3 0xb6999888 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#4 0xb4866d2c in glGetBufferSubDataARB () from /usr/lib/host-gl/libGL.so.1.2
No symbol table info available.
#5 0xb4866d62 in glGetBufferSubData () from /usr/lib/host-gl/libGL.so.1.2
No symbol table info available.
#6 0xb6c20dec in glDrawElements () from /usr/lib/libGLESv2.so.1
No symbol table info available.
#7 0xb7cc3096 in QSGBatchRenderer::Renderer::renderMergedBatch (
this=0x84e6800, batch=0x84e8100)
at scenegraph/coreapi/qsgbatchrenderer.cpp:1863
draw = value optimized out
offset = value optimized out
i = value optimized out
e = value optimized out
__PRETTY_FUNCTION__ = void
QSGBatchRenderer::Renderer::renderMergedBatch(const QSGBatchRenderer::Batch*)
---Type return to continue, or q return to quit---
sms = 0x84e5420
g = 0x84e7bbc
attrNames = value optimized out
gn = 0xb7fc2e5c
material = value optimized out
program = value optimized out
#8 0xb7cc4e3f in QSGBatchRenderer::Renderer::renderBatches (this=0x84e6800)
at scenegraph/coreapi/qsgbatchrenderer.cpp:2008
b = value optimized out
i = value optimized out
__PRETTY_FUNCTION__ = void QSGBatchRenderer::Renderer::renderBatches()
renderOpaque = value optimized out
renderAlpha = true
#9 0xb7cc6718 in QSGBatchRenderer::Renderer::render (this=0x84e6800)
at scenegraph/coreapi/qsgbatchrenderer.cpp:2168
__PRETTY_FUNCTION__ = virtual void
QSGBatchRenderer::Renderer::render()
#10 0xb7cd5e10 in QSGRenderer::renderScene (this=0x84e6800, bindable=...)
at scenegraph/coreapi/qsgrenderer.cpp:274
profileFrames = value optimized out
bindTime = 0
renderTime = 0
---Type return to continue, or q return to quit---
__PRETTY_FUNCTION__ = void QSGRenderer::renderScene(const
QSGBindable)
#11 0xb7cd60dd in QSGRenderer::renderScene (this=0x84e6800)
at scenegraph/coreapi/qsgrenderer.cpp:231
b = warning: RTTI symbol not found for class
'QSGRenderer::renderScene()::B'
{QSGBindable = {
_vptr.QSGBindable = 0xb7fb4240}, No data fields}
#12 0xb7ce7e4c in QSGContext::renderNextFrame (this=0x845d620,
renderer=0x84e6800, fboId=0) at scenegraph/qsgcontext.cpp:367
No locals.
#13 0xb7d3273e in QQuickWindowPrivate::renderSceneGraph (this=0x848c870,
size=...) at items/qquickwindow.cpp:358
_qml_memory_scope = {pushed = false}
q = 0x845dc30
fboId = 0
devicePixelRatio = value optimized out
#14 0xb7d0bb04 in QSGGuiThreadRenderLoop::renderWindow (this=0x8498128,
window=0x845dc30) at scenegraph/qsgrenderloop.cpp:288
data = @0x8489ba4
current = value optimized out
alsoSwap = true
cd = 0x848c870
renderTime = 0
swapTime = value optimized out
---Type return to continue, or q return to quit---
__PRETTY_FUNCTION__ = void
QSGGuiThreadRenderLoop::renderWindow(QQuickWindow*)
syncTime = 0
renderTimer = {t1 = -4611697219702095867, t2 = 55969188728}
profileFrames = false
#15 0xb7d0c4ee in QSGGuiThreadRenderLoop::exposureChanged (this=0x8498128,
window=0x845dc30) at scenegraph/qsgrenderloop.cpp:335
No locals.
#16 0xb7d319be in QQuickWindow::exposeEvent (this=0x845dc30)
at items/qquickwindow.cpp:214
d = value optimized out
#17 0xb71f6b94 in QWindow::event(QEvent*) () from /usr/lib/libQt5Gui.so.5
No symbol table info available.
#18 0xb7d3dcb4 in QQuickWindow::event (this=0x845dc30, e=0xb880)
at items/qquickwindow.cpp:1241
d = value optimized out
#19 0xb6ec782a in
[Development] QT4.8.5 issue: multi-touch message cannot handled by close button
On 13 Sep 2013, at 9:44 AM, Duan Fugang-B38611 wrote: The KDE is not kwin, is matchbox-window-manager. OK I can reproduce it, so it seems to be an issue with matchbox (and matchbox is not using Qt). But it was designed for PDAs, so maybe there is a solution. The touch drivers for Linux PDAs back then (iPaq, Zaurus, Agenda etc.) only provided mouse events, because XInput didn't have touch until recently, and anyway a resistive touchscreen is just like a single-button mouse. But the evdev driver should be making your multi-touch screen emulate a mouse too, so then I wonder what matchbox is doing so that it doesn't work. Maybe it has been partially updated to support touch but doesn't do it correctly? But you can google and/or find a matchbox mailing list or forum to ask about that, or look at the source and see if it uses xinput or just the conventional old X11 mouse events. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by close button
From: Rutledge Shawn shawn.rutle...@digia.com Data: Friday, September 13, 2013 4:11 PM To: development@qt-project.org Subject: [Development] QT4.8.5 issue: multi-touch message cannot handled by close button On 13 Sep 2013, at 9:44 AM, Duan Fugang-B38611 wrote: The KDE is not kwin, is matchbox-window-manager. OK I can reproduce it, so it seems to be an issue with matchbox (and matchbox is not using Qt). But it was designed for PDAs, so maybe there is a solution. The touch drivers for Linux PDAs back then (iPaq, Zaurus, Agenda etc.) only provided mouse events, because XInput didn't have touch until recently, and anyway a resistive touchscreen is just like a single- button mouse. But the evdev driver should be making your multi-touch screen emulate a mouse too, so then I wonder what matchbox is doing so that it doesn't work. Maybe it has been partially updated to support touch but doesn't do it correctly? But you can google and/or find a matchbox mailing list or forum to ask about that, or look at the source and see if it uses xinput or just the conventional old X11 mouse events. The current Linux egalax driver locates: drivers/input/touchscreen/egalax_ts.c (you can get it from Linux-next git) When I disable multitouch in the egalax driver to let it work on single touch mode, the window of QT apps can be closed by clicked window X button at up-right region. The single touch mode report BTN_TOUCH event comparing with multi-touch. How to explain it ? Thanks, Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt WebEngine
12.09.2013, 16:04, Knoll Lars lars.kn...@digia.com: Hi, As many of you know, we've been doing some research on a (chromium based) new web engine for Qt during spring and summer. I wanted to let you know that we've now come to the conclusion that we want to continue these efforts in the future. Please check http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/ for all the details. IMHO, this is a really bad decision. WebKit is a meritocracy-driven community project with many large and small contributors, while Chromium seems to be driven solely by Google employees. If Google needs to do some ground-breaking changes in the engine, they will do it, and don't hope they to care about 3rd party products being broken. Chromium has a cross-platform focus, with the browser being available on all major desktop platforms and Android. The same is no longer true of WebKit, and we would have had to support all the OS’es on our own in that project. To run QtWebKit on embedded platform with unsupported native graphics API, it's enough to write gfxdriver for Qt 4, or QPA plugin for Qt 5. Basically, if Qt works, QtWebKit works too. To run Chromium I will also need to port Skia, and maybe other things. IIRC, it does not even support DirectFB out of the box. There are many things that are available out-of-the box from Chromium, which would require a lot of work for us to support ourselves in WebKit. One example, is the whole platform/OS adaptation that we can simply re-use. Multimedia and new HTML5 features such as WebRTC are working out-of the-box and don’t require any Qt-specific code. This implies larger size of binaries for embedded users because of massive duplication between Qt and Chromium cross-platfrom layers. As using Chromium simplifies handling the OS integration, this allows us to spend additional time to focus on the upper layers to provide a great and easy-to-use API and a seamless integration into Qt as possible. Does Chromium provide any C++ API warranties? You may end up overhaul your fancy integration layer each time you update. We are seeing that Chromium is being developed with very strict control on quality. WebKit also has solid testing infrastructure. Finally, we are seeing that Chromium is currently by far the most dynamic and fastest moving browser available WebKit is moving slower because it has to care about all its ports. All significant architecture changes are discussed by community. Chromium is fast because they don't care about anyone else. One of the fundamentals of Chromium is that all rendering of Web content happens in a different process for security and stability reasons. WebKit 2 multiprocessing model is much better designed and provides stable API. Also, single process mode of Chromium in unofficial and often breaks (and it's usually worthless to be multi-process on single-core embedded CPU). I hope there will be some folks to keep maintaining Qt port in WebKit upstream. Otherwise, NIX port looks like a good alternative, though it requires OpenGL-capable hardware. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Pointer aliasing problem in optimized gcc builds
Hi everybody
I'm using a custom build of Qt 5.1.1 compiled with GCC 4.8.1 on
Windows (MinGW builds x86_64). For some performance reasons I have to
enable -O3 flag until my project is ported out of Qt. The Qt was
built with C++11 support.
When program tries to append an item to a container it crashes.
Debuggers stops at this line in qlist.h:
template typename T
Q_OUTOFLINE_TEMPLATE void QListT::append(const T t)
{
if (d-ref.isShared()) { // == Here
Node *n = detach_helper_grow(INT_MAX, 1);
QT_TRY {
node_construct(n, t);
} QT_CATCH(...) {
--d-end;
QT_RETHROW;
}
// ...
Looking into functions that append calls, I found that node_construct
contains some unsafe code:
template typename T
Q_INLINE_TEMPLATE void QListT::node_construct(Node *n, const T t)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic) n-v = new T(t);
else if (QTypeInfoT::isComplex) new (n) T(t);
#if (defined(__GNUC__) || defined(__INTEL_COMPILER) ||
defined(__IBMCPP__)) !defined(__OPTIMIZE__)
// This violates pointer aliasing rules, but it is known to be
safe (and silent)
// in unoptimized GCC builds (-fno-strict-aliasing). The other
compilers which
// set the same define are assumed to be safe.
else *reinterpret_castT*(n) = t;
#else
// This is always safe, but penaltizes unoptimized builds a lot.
else ::memcpy(n, static_castconst void *(t), sizeof(T));
#endif
}
I guess problem is same in detach_helper_grow function. Tried adding
-fno-strict-aliasing to compile flags and defined __OPTIMIZE__. Also
removed -O3 from compile flags, but no hope. So I have a couple of
questions:
* How bad are -O3 compiles? I've read that it's completely safe for
well-written code but using optimization aggressively, may cause undefined
behavior or even runtime crashes for bad codes. How is Qt code?
* How can I solve this problem? (Using official builds is not preferred)
* Do I need to recompile Qt with -fno-strict-aliasing flag or defining
__OPTIMIZE__ ? Since templated classes are header-only and I already tried
both in my project, I guess the answer is no.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt WebEngine
Hi, On Fri, Sep 13, 2013 at 7:06 AM, Konstantin Tokarev annu...@yandex.ruwrote: 12.09.2013, 16:04, Knoll Lars lars.kn...@digia.com: Hi, As many of you know, we've been doing some research on a (chromium based) new web engine for Qt during spring and summer. I wanted to let you know that we've now come to the conclusion that we want to continue these efforts in the future. Please check http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/for all the details. IMHO, this is a really bad decision. WebKit is a meritocracy-driven community project with many large and small contributors, while Chromium seems to be driven solely by Google employees. If Google needs to do some ground-breaking changes in the engine, they will do it, and don't hope they to care about 3rd party products being broken. This is simply not true. Samsung, Intel, Adobe, Opera have been able to contribute a lot and influence the development in many ways since the fork date. I speak of experience. Adobe, Intel and Samsung already have reviewers (Owners). The problem of breaking was also happening in WebKit, for example Apple removed the support of Windows for WebKit2 letting QtWebKit alone broken if Digia didn't help. Chromium has a cross-platform focus, with the browser being available on all major desktop platforms and Android. The same is no longer true of WebKit, and we would have had to support all the OS’es on our own in that project. To run QtWebKit on embedded platform with unsupported native graphics API, it's enough to write gfxdriver for Qt 4, or QPA plugin for Qt 5. Basically, if Qt works, QtWebKit works too. To run Chromium I will also need to port Skia, and maybe other things. IIRC, it does not even support DirectFB out of the box. Yes that's one of the things that needs investigation. But in that particular case of custom hardware with custom graphics driver on a custom OS I believe QtWebKit is not best suited. Maybe you want to look at the Nix port of WebKit which is a low level WebKit port requiring Cairo and OpenGL to run : http://nix.openbossa.org/ There are many things that are available out-of-the box from Chromium, which would require a lot of work for us to support ourselves in WebKit. One example, is the whole platform/OS adaptation that we can simply re-use. Multimedia and new HTML5 features such as WebRTC are working out-of the-box and don’t require any Qt-specific code. This implies larger size of binaries for embedded users because of massive duplication between Qt and Chromium cross-platfrom layers. Yes but given the small amount of resources one needs to be pragmatic. Maintaining, releasing, updating a web engine is a very resource demanding task (and full time) and clearly the Qt project doesn't have the bandwidth to do so. Therefore it needs to seek for alternatives and help. What is better? A QtWebKit broken, outdated, unsecure or state-of-art engine (with maybe slightly less capabilities)? Or maybe just nothing? As using Chromium simplifies handling the OS integration, this allows us to spend additional time to focus on the upper layers to provide a great and easy-to-use API and a seamless integration into Qt as possible. Does Chromium provide any C++ API warranties? You may end up overhaul your fancy integration layer each time you update. You can build on top of the Content Shell module which is what Google is using to build Chrome, what they use to build their Android WebView and what Opera uses to build their browser. Crosswalk is also based on top of that. We are seeing that Chromium is being developed with very strict control on quality. WebKit also has solid testing infrastructure. The one of Chromium is the one of WebKit basically even improved. Every patch is tested (with LayoutTests) on Windows, Mac, Linux which is not the case in WebKit (it was only running with the Chromium port on Linux only and now run only on Mac OS). The QA team of Google is magnitude bigger than what QtWebKit had and the quality of the releases of Chromium proves it. Not to mention the amount of bots running the code in so many different configurations. Google has a dedicated security team working on Chromium, QtWebKit never had that (and all the fixes are not just in core code, but can be in port specific code). Finally, we are seeing that Chromium is currently by far the most dynamic and fastest moving browser available WebKit is moving slower because it has to care about all its ports. All significant architecture changes are discussed by community. Chromium is fast because they don't care about anyone else. Again a bold statement of somebody who has not participated to the projects. Before Google forked they were #1 in the project in term of contributions, many of CSS/HTML features were developed by them. Of course when they forked then the number of features in development in WebKit decreased a lot because
Re: [Development] More on QDateTime / QTimeZone
On Thursday 12 Sep 2013 19:24:15 Knoll Lars wrote: On 9/12/13 9:06 PM, John Layt jl...@kde.org wrote: The first is it means creating a QDateTime becomes a lot slower as we need to calculate the epoch offset up-front, instead of only when/if needed. We might be able to simply cache the time zone offset once and cache it. Then it should be at the same speed. No, because we don't know the rules for when to apply Daylight Time, that's why we'd need to call mktime for every new datetime creation. It can't be avoided. Besides, we already have a spec that offers this style behaviour: OffsetFromUTC. The second is it means that the behaviour of the local date/time staying constant over time zone changes will no longer be true. It would be up to the app to realise a time zone change has happened and to know what to do with the datetimes as a result. Well, IMO that's in most cases what you'd want in any case. I can't see how a date time specifying 5pm for a meeting should stay at 5pm when I fly to finland... You also don't say I want an appointment at 2pm UTC whatever that happens to be in local time, if you do and the daylight conversion rules change your local appointment time also ends up changing. You instead say I want an appointment at 3pm local time *in Oslo*. You only convert that to UTC if you need to see what that local time is in another tz. QTimeZone will give us a proper way to do that. You'd be crazy to currently be using LocalTime for such things, you'd use UTC or OffsetFromUTC or KDateTime instead. Where the local date/time stays constant is what's normally known as Clock Time or Wall Time, i.e. I want to wake up at 7am no matter where in the world I am. That's what LocalTime is closest to. If we switched LocalTime then we'd need to add a new spec for ClockTime/WallTime/SystemTime to replicate that behaviour. The problem with LocalTime is it's neither fish nor fowl, it's just This local time, if you want UTC just use whatever the system time zone currently is. We don't know what the most common use case is, but I suspect it's getting the current local time, and showing a local date as a string. Most other use cases will revolve around whatever the current system tz is, or even not care at all. It's the local time value they mostly want, not the UTC equivalent. The biggest problem I see with switching the behaviour is to define how to update a datetime if needed after a time zone change. If we cache whatever offset mktime returns at QDateTime creation, then when the tz changes any new dates will immediately be created with the new offset, but the old instances will still have the old offset, leaving things inconsistent and still not under the apps control. You would also then need api for the app to tell the old instances to update to the new offset, which seems ugly and inefficient and prone to failure. The alternative is to use a cached QTimeZone to look up the offset every time, that way the offset remains consistent until the app chooses to refresh the cached QTimeZone, but then you lose any efficiency gains and you might as well keep the old behaviour for now. We also need to think about the serialization behaviour: do we still serialize as the local time as we currently do, or as the UTC time? And how does that affect serializing a time expressed in a QTimeZone? Is it a time in UTC to be interpreted into a given tz, or is it a given local time to be interpreted into UTC? If I make an appointment for 3pm Oslo time then I want that to stay in Oslo time regardless if the rules for conversion to UTC change between serialize/deserialize, so that still needs to serialize as local. We'd also need to think about de-serializing old formats and how to convert them correctly. We may not need to implement all this in the first cut, but we at least need to think about how it will work, otherwise we could end up releasing something half-way there and then finding we can't actually make it work in teh full solution. If we do make the change, I'd also rather do it in a different way. Keep the LocalTime spec behaving as it does so legacy code can easily switch to using it, but create a new spec called something like SystemTime that behaves the way you want, then possibly change the default spec from LocalTime to SystemTime. Wouldn't the issues here be solved by storing all time values in UTC? In any case, I don't believe this is a showstopper for 5.2. No, because you still need to make that initial conversion from local time to UTC using mktime, so you'll still get the same inconsistencies. But yes, it's a problem for later. These are corner cases (as the OSes don't really solve them as well apparently). I'd not worry too much about this for 5.2. If we get this settled in 5.3 it's good enough. Corner cases, yes, thankfully most people don't schedule appointments for 2am in the morning of daylight time
Re: [Development] More on QDateTime / QTimeZone
On Thursday 12 Sep 2013 22:24:40 Robin Burchell wrote: On Thu, Sep 12, 2013 at 9:24 PM, Knoll Lars lars.kn...@digia.com wrote: We might be able to simply cache the time zone offset once and cache it. Then it should be at the same speed. This would also probably provide hidden wins in various places, making changes like b9ef4a9c3047228ec007ac81ff0a304f8cc274b7 in qtbase unnecessary. I'd like to see this for that reason :) Well, that patch is taking advantage of the fact that creating a LocalTime is currently cheap, as is calling setTimeZone, neither of those steps currently require a conversion to UTC. As explained in my reply to Lars with any change in storage you would always have to call mktime in the creation, so you immediately lose the speed-up from your patch. There's probably a lot of places this will happen in Qt, not to mention other people's code. There's no such thing as a free lunch :-) The real problem is that the file code uses LocalTime internally when it should use UTC and only convert to LocalTime as the last step in the public api. My understanding is Unix stores file times as time_t, and Windows as a FILETIME which is nsecs since 1601, both are UTC, so at the moment there is already a conversion from UTC to LocalTime required to create the LocalTime. Creating and passing them around internally as UTC could be a big saving, however I suspect that would take a large change to achieve. John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Binary incompatible change in dev branch.
Hello, Two changes which are binary incompatible compared to the state before them were just merged to dev: https://codereview.qt-project.org/#change,65263 https://codereview.qt-project.org/#change,65042 The changes are to APIs which were not present in Qt 5.1. This is a heads-up that you may need to re-build everything the next time you update your qtbase repo. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pointer aliasing problem in optimized gcc builds
On sexta-feira, 13 de setembro de 2013 17:22:32, Olivier Goffart wrote: * How bad are -O3 compiles? I've read that it's completely safe for well-written code but using optimization aggressively, may cause undefined behavior or even runtime crashes for bad codes. How is Qt code? I've only used -O3 for my optimised builds for 6 years. In fact, I only run Qt 4 with -O3 nowadays, except when I need to debug something. -- 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] Pointer aliasing problem in optimized gcc builds
On Friday 13 September 2013 15:55:45 Soroush Rabiei wrote:
Hi everybody
I'm using a custom build of Qt 5.1.1 compiled with GCC 4.8.1 on
Windows (MinGW builds x86_64). For some performance reasons I have to
enable -O3 flag until my project is ported out of Qt. The Qt was
built with C++11 support.
When program tries to append an item to a container it crashes.
Debuggers stops at this line in qlist.h:
template typename T
Q_OUTOFLINE_TEMPLATE void QListT::append(const T t)
{
if (d-ref.isShared()) { // == Here
Node *n = detach_helper_grow(INT_MAX, 1);
QT_TRY {
node_construct(n, t);
} QT_CATCH(...) {
--d-end;
QT_RETHROW;
}
// ...
Looking into functions that append calls, I found that node_construct
contains some unsafe code:
template typename T
Q_INLINE_TEMPLATE void QListT::node_construct(Node *n, const T t)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic) n-v = new T(t);
else if (QTypeInfoT::isComplex) new (n) T(t);
#if (defined(__GNUC__) || defined(__INTEL_COMPILER) ||
defined(__IBMCPP__)) !defined(__OPTIMIZE__)
// This violates pointer aliasing rules, but it is known to be
safe (and silent)
// in unoptimized GCC builds (-fno-strict-aliasing). The other
compilers which
// set the same define are assumed to be safe.
else *reinterpret_castT*(n) = t;
#else
// This is always safe, but penaltizes unoptimized builds a lot.
else ::memcpy(n, static_castconst void *(t), sizeof(T));
#endif
}
I guess problem is same in detach_helper_grow function. Tried adding
-fno-strict-aliasing to compile flags and defined __OPTIMIZE__. Also
removed -O3 from compile flags, but no hope. So I have a couple of
questions:
* How bad are -O3 compiles? I've read that it's completely safe for
well-written code but using optimization aggressively, may cause undefined
behavior or even runtime crashes for bad codes. How is Qt code?
* How can I solve this problem? (Using official builds is not preferred)
* Do I need to recompile Qt with -fno-strict-aliasing flag or defining
__OPTIMIZE__ ? Since templated classes are header-only and I already tried
both in my project, I guess the answer is no.
Hi,
It is much more likely that the problem is somewhere else in your program.
Especially if you can reproduce the problem without optimisation.
I bet you have a dangling pointer somewhere in your application.
The reinterpret_cast there should be safe as the node are only accessed as T.
(memcpy is builtin, even in debug mode so the comment is wrong and the code
could be simplified)
--
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] Pointer aliasing problem in optimized gcc builds
On sexta-feira, 13 de setembro de 2013 20:13:30, Konstantin Tokarev wrote: 13.09.2013, 19:51, Thiago Macieira thiago.macie...@intel.com: On sexta-feira, 13 de setembro de 2013 17:22:32, Olivier Goffart wrote: * How bad are -O3 compiles? I've read that it's completely safe for well-written code but using optimization aggressively, may cause undefined behavior or even runtime crashes for bad codes. How is Qt code? I've only used -O3 for my optimised builds for 6 years. In fact, I only run Qt 4 with -O3 nowadays, except when I need to debug something. Strict aliasing is enabled at -O2 as well. There are no known aliasing violations in Qt, outside of qtdeclarative. -- 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] Pointer aliasing problem in optimized gcc builds
13.09.2013, 19:51, Thiago Macieira thiago.macie...@intel.com: On sexta-feira, 13 de setembro de 2013 17:22:32, Olivier Goffart wrote: * How bad are -O3 compiles? I've read that it's completely safe for well-written code but using optimization aggressively, may cause undefined behavior or even runtime crashes for bad codes. How is Qt code? I've only used -O3 for my optimised builds for 6 years. In fact, I only run Qt 4 with -O3 nowadays, except when I need to debug something. Strict aliasing is enabled at -O2 as well. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt WebEngine
On Fri, Sep 13, 2013 at 1:39 PM, Alexis Menard ale...@webkit.org wrote: Qt integration will be on top of the Content Shell and this single process mode needs to work because Google needs it for their Android WebView. Alexis, I think you meant Content API here, not Content Shell, right? I didn't work on Android (I now work for Opera on the Mac platform mostly), and not quite familiar with the single process support status, but I have heard it getting broken from time to time and usually being used as a test / diagnose tool, instead of officially supported as a process model. (In Opera for instance we try not to break single process mode but no one is really actively developing for it or count on it.) Maybe it worked well enough for content module? Do you have any further information about that? (Proving that Qt WebEngine can safely use single process mode on platforms that requires it.) - Jiang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt WebEngine
On Fri, Sep 13, 2013 at 2:03 PM, Jiang Jiang gzjj...@gmail.com wrote: On Fri, Sep 13, 2013 at 1:39 PM, Alexis Menard ale...@webkit.org wrote: Qt integration will be on top of the Content Shell and this single process mode needs to work because Google needs it for their Android WebView. Alexis, I think you meant Content API here, not Content Shell, right? Yes sorry, my bad. I meant the Content API. I didn't work on Android (I now work for Opera on the Mac platform mostly), and not quite familiar with the single process support status, but I have heard it getting broken from time to time and usually being used as a test / diagnose tool, instead of officially supported as a process model. (In Opera for instance we try not to break single process mode but no one is really actively developing for it or count on it.) Maybe it worked well enough for content module? Do you have any further information about that? (Proving that Qt WebEngine can safely use single process mode on platforms that requires it.) Well talking with the people working on the Android WebView they decided to opt for the single process approach so at least up until the content API it needs to work. I'm not involved in the WebView work but you should clarify with them. - Jiang -- Alexis Menard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Heads up: QtAlgorithms to be deprecated in 5.2
Hello,
https://codereview.qt-project.org/#change,43441 (currently waiting for a
review) is going to mark most of the QtAlgorithms functions as deprecated.
The decision about this has already happened some time ago:
http://www.mail-archive.com/development@qt-project.org/msg01603.html
To summarize it up, there are several good reasons to do this, most notably:
- Qt 5 requires STL;
- STL algorithms are far better than ones in Qt;
- Due to the fact that Qt algorithms use qLess and qSwap, it's just not
possible to reimplement Qt algorithms in terms of the STL counterparts
and keep 100% compatibility with existing code.
=== Impact for user code ===
- A mere search-and-replace will fix most of the deprecation warnings.
Probably the most annoying bit is that Qt offers convenience overloads
taking a container instead of an iterator:
qSort(list); // needs to become: std::sort(list.begin(), list.end())
(If you're reading this and are in the C++ committee, please, you know
what to propose for the next Standard.)
- If you specialized qLessT for your type, you need to pass it
*explicitly* to the STL algorithm as the comparison functor:
QListFoo list;
std::stable_sort(list.begin(), list.end(), qLessFoo());
- If you specialized qSwapT for your type, you need to specialize
std::swapT to make it called by STL:
namespace std {
template void swap(Foo lhs, Foo rhs) { ... }
}
(Given you're at it, it's an *extremely good idea* to provide move
operators too. Sorting algorithms will use it in C++11.)
Note that Qt specializes std::swap for you if you use Q_DECLARE_SHARED
for your type, by requiring you to implement a swap() member function.
- Unlike qSort, std::sort requires the comparison functor to really
honour Strict Weak Ordering. This means that if comp(a, b) returns true,
then comp(b, a) *must* return false.
If you start to see crashes inside STL algorithms, please check the
functor. Common mistakes are:
1) functors returning true to express equivalent items
2) functors using the relative position of two items (in a list/array)
as sorting criterion
Example of 1) https://codereview.qt-project.org/65408
Example of 2) https://codereview.qt-project.org/65015
This also means that if the comparison functor is somehow user
provided and you can't trust that it's really enforcing SWO, then you
should stay with Qt algorithms (or maybe write one yourself), as the
Standard says that it's a requirement violation, leading to undefined
behaviour.
- C++03 has a broken wording about algorithms such as lower_bound /
upper_bound: in spite of them having two overloads (one with and one
without a comparison functor), §25.3.3.1.1 [lower.bound] for instance says:
Requires: Type T is LessThanComparable (20.1.2).
I.e. operator(T, T) must exist. The pitfall is that we're allowed to
pass a value of type V != T as the value to look for, and a functor with
signature
bool f(T, V)
to perform the search. This means that operator(T, T) might not exist
at all.
Some C++03 compilers (hello, MSVC 2008), when in debug mode, use the
requirement to ease development by checking if the iterator range is
indeed sorted by operator(T, T). Unfortunately, if the operator doesn't
exist, compilation fails (!). Adding a operator fixes the issue.
(Probably even a dummy one, which always returns false disclaimerI'm
not recommending it/disclaimer).
https://bugreports.qt-project.org/browse/QTBUG-33473 is tracking this
for qtbase itself.
(The wording has been corrected in C++11, cf. §25.4.3.1.1).
===
Comments?
--
Join us at Qt Developer Days 2013! - https://devdays.kdab.com
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A QtCore class for event-driven jobs
On 2013-09-12 08:07, André Somers wrote: Op 11-9-2013 17:19, David Faure schreef: Couldn't such a class be part of the hopefully coming QtConcurrent replacement? Can we forget about threads for a second? No, I'd rather not forget that huge pink elephant in the room... In this age of multi-core systems being the norm rather than exception, we simply cannot ignore threads when designing a generic API for asynchronous jobs. The main point of event-driven jobs is to have them use the event loop, NOT threads. That sounds pointless to me. Why would you design an API for asynchronous jobs, but limit that to those jobs that use the eventloop? What does the user of the API really care what the API does to pull of the async-ness? Compare with QNAM: it uses threading too in the background, doesn't it? To me, a generic job API only makes sense if the API makes sense for all async operations, no matter if the job itself uses threading or the eventloop to work. Both should work equally well, and have equal support IMHO. Seconded. I, too, have written Job-classes, but I wouldn't do so anymore. That concept is so 90's. I'd use a future. A future isn't (necessarily) the result of a thread. It's a placeholder for an asynchronously calculated result. That could be a UDP message. And Qt's future can even transport progress, and supports cancellation and stop/resume. It's not a QObject, except if you want it to (QFutureWatcher). All that's needed is to wrap QFutureInterface into a QPromise (and wrap that one into a QPackagedTask). And the future needs .then() support. Thanks, Marc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Validating JSON with schema?
Hello, I am wondering if there are any plans to support the validation of JSON data in Qt using a JSON schema. Qt supports the validation of XML using an XML schema with QtXmlPatterns (example: http://qt-project.org/doc/qt-4.8/xmlpatterns-schema.html). What is the likelihood that we will see similar functionality for JSON in the near future? Thanks, Alfonso ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Validating JSON with schema?
There is an example of JSON validation in the qtjsonstream playground project (http://qt.gitorious.org/qtplayground/qtjsonstreamhttp://qt.gitorious.org/qtplayground/qtjsonstream/source/2a435d1df0fc2bd351c0c9bb4bd72a0f8f6c64c7: or on codereview.qt-project.org). Please keep in mind that this project is dormant, and the code is almost certainly never going to go into Qt core in its present state. But you might find it useful if you are in need of some code now. Chris On Fri, Sep 13, 2013 at 5:00 PM, achart...@fastmail.fm wrote: Hello, I am wondering if there are any plans to support the validation of JSON data in Qt using a JSON schema. Qt supports the validation of XML using an XML schema with QtXmlPatterns (example: http://qt-project.org/doc/qt-4.8/xmlpatterns-schema.html). What is the likelihood that we will see similar functionality for JSON in the near future? Thanks, Alfonso ___ 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] Validating JSON with schema?
On Fri, Sep 13, 2013 at 11:00 PM, achart...@fastmail.fm wrote: Hello, I am wondering if there are any plans to support the validation of JSON data in Qt using a JSON schema. Qt supports the validation of XML using an XML schema with QtXmlPatterns (example: http://qt-project.org/doc/qt-4.8/xmlpatterns-schema.html). What is the likelihood that we will see similar functionality for JSON in the near future? Hi, in the case you're interested on code, I implemented a partially compliant JSON validator for Qt Creator a while ago (there's wasn't actually a standardised specification back then, only the draft - I'm not sure what's the state now). The code might not be that easily extracted though because it relied on the QML/JS model components. Originally this was not a documented feature, but if no one has done work in the area I'd guess it's still there. -- Leandro http://www.ltcmelo.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 11 September 2013 01:07, Laszlo Papp lp...@kde.org wrote: On Tue, Sep 10, 2013 at 4:46 PM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote: On 10 September 2013 14:27, Knoll Lars lars.kn...@digia.com wrote: Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars QtWin or QWin? QtWin, it's a namespace. I believe he is aware of that... I think, Sze please correct me if I am wrong, he just wanted to make sure because there was several emails last year about QFoo or QtFoo for the namespace, and it seemed that the suboptimal naming was chosen for other reasons. Laszlo is correct. Before Qt 5 was released, most public namespaces had the QFoo format -- QSsl, QDBus, QAudio, etc. A few had the QtFoo format -- QtMultimedia::MetaData (unreleased), QtMultimedia (unreleased), and QtConcurrent. I suggested making them uniform. [1] Lars said that he preferred QFoo - QtFoo, but that change was the much more intrusive one. Qt 5 was close to Beta 2 at the time, so he chose the lower-risk QtFoo - QFoo. [2] As of Qt 5.1, all public namespaces are QFoo, except Qt and QtConcurrent. Thiago blocked the latter on the basis that (i) development on that module has stopped, and (ii) QtConcurrent is quite different from all the other namespaces anyway. [3] With all that in mind, do we want QtWin or QWin? The benefit of QWin is consistency with existing conventions; the downside is having to wait till Qt 6 if we want to switch to the preferred QtFoo. QtWin has the benefit of introducing users to the preferred naming convention now (and a smaller list of namespace changes if/when the change occurs), at the cost of introducing more inconsistencies. I vote for QWin for consistency, and I'm not sure that an extra ':%s/QWin::/QtWin::/g' will make a difference to users if they're doing the same for all other namespaces in Qt 6. Regards, Sze-Howe [1] http://lists.qt-project.org/pipermail/development/2012-October/007421.html [2] http://lists.qt-project.org/pipermail/development/2012-October/007591.html [3] https://codereview.qt-project.org/#change,39375 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] More on QDateTime / QTimeZone
On Thursday 12 Sep 2013 13:48:24 Thiago Macieira wrote: On quinta-feira, 12 de setembro de 2013 21:06:03, John Layt wrote: * Choose either local msecs or epoch msecs, if epoch then that change can't be done for 5.2 Choose the easiest for you to implement. We're running out of time, so I'd rather stick to the implementation you have and your best recommendation. I've spent the evening writing and running some benchmark tests (amazingly we didn't have any before). Each benchmark creates a date a day for 10 years and calls the tested method, so 3650 consecutive dates. The numbers here are from 1000 iterations on my i7. As expected they're a mixed return with some things faster and some things slower (not all tests shown): Action BaseMsecs % -- - - create(): 0.294 0.39233 isValid(): 0.339 0.49245 date(): 0.313 0.632 102 time(): 0.311 0.639 105 timeSpec(): 0.311 0.40330 offsetFromUtc():7.466 9.00921 toMSecsSinceEpoch():6.690 8.83632 toMSecsSinceEpoch1950():7.522 3.642 -52 toMSecsSinceEpoch2050():8.618 10.79025 setDate(): 0.418 0.83299 setTime(): 0.385 0.820 113 setTimeSpec(): 0.340 0.50849 setOffsetFromUtc(): 0.347 0.43826 setMSecsSinceEpoch(): 6.020 2.564 -57 addDays(): 0.701 1.12961 addMonths():1.836 2.27024 addYears(): 1.826 2.25523 addMSecs():12.820 10.370 -19 toTimeSpec(): 6.900 9.24734 toOffsetFromUtc(): 7.251 9.29228 daysTo(): 0.365 0.953 161 msecsTo(): 13.510 17.78032 equivalent(): 0.367 0.43920 equivalentUtc():6.730 9.01834 lessThan(): 0.355 0.44425 lessThanUtc(): 6.714 8.90633 currentDateTime(): 1.118 0.314 -72 fromMSecsSinceEpoch(): 6.094 2.451 -60 * Things that start with an msecs value (i.e. use localtime) are 60-80% faster * Things that start with a date and time (i.e. use mktime) are 30% slower. * Focusing on optimising toMSecsSinceEpoch() will cause most other methods to speed up, if I remove a tzset call it runs faster than the baseline. * The getting and setting of the date and time are obviously slower as they now involve conversions. * Rather strangely timeSpec() is 30% slower despite now only returning the member directly instead of having to do a switch based on the member, a few other calls are equally confusing. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A QtCore class for event-driven jobs
Thanks Marc, that's exactly what I was saying about. The only difference is (seems to be) a user-visible manager that owns (or let's say locks) the task up until it gets processed so no deletion may occur in the middle of execution, i.e. What the manager is and where/how it executes the tasks is probably up to the user but having a standard interface with some guaranteed functionality is for good, IMO. Regards, Konstantin 2013/9/13 Marc Mutz marc.m...@kdab.com On 2013-09-12 08:07, André Somers wrote: Op 11-9-2013 17:19, David Faure schreef: Couldn't such a class be part of the hopefully coming QtConcurrent replacement? Can we forget about threads for a second? No, I'd rather not forget that huge pink elephant in the room... In this age of multi-core systems being the norm rather than exception, we simply cannot ignore threads when designing a generic API for asynchronous jobs. The main point of event-driven jobs is to have them use the event loop, NOT threads. That sounds pointless to me. Why would you design an API for asynchronous jobs, but limit that to those jobs that use the eventloop? What does the user of the API really care what the API does to pull of the async-ness? Compare with QNAM: it uses threading too in the background, doesn't it? To me, a generic job API only makes sense if the API makes sense for all async operations, no matter if the job itself uses threading or the eventloop to work. Both should work equally well, and have equal support IMHO. Seconded. I, too, have written Job-classes, but I wouldn't do so anymore. That concept is so 90's. I'd use a future. A future isn't (necessarily) the result of a thread. It's a placeholder for an asynchronously calculated result. That could be a UDP message. And Qt's future can even transport progress, and supports cancellation and stop/resume. It's not a QObject, except if you want it to (QFutureWatcher). All that's needed is to wrap QFutureInterface into a QPromise (and wrap that one into a QPackagedTask). And the future needs .then() support. Thanks, Marc ___ 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
