Re: [Development] Situation with QMacCocoaViewContainer / QMacNactiveWidget in Qt 5
On Mar 11, 2013, at 5:12 AM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: Are QMacCocoaViewContainer and QMacNativeWidget going to be implemented in some Qt 5.x? I understand we currently have some implementation in QtMacExtras, however the header files are still there in Qt 5 Widgets, and documented (but you obviously can't link since they are not implemented) - https://qt-project.org/doc/qt-5.0/qtwidgets/qmaccocoaviewcontainer.html, https://qt-project.org/doc/qt-5.0/qtwidgets/qmacnativewidget.html. I imagine we will be letting QtMacExtras provide these widgets. If that's the case why are the headers still in Qt 5 and why are they documented as being part of QtWidgets? Because we forgot to remove them for 5.0. I'm considering enabling the classes in QtWidgets again. They would then use the QWindow-based implementation in the platform plugin which the QtMacExtras classes are already a thin wrapper around. The benefits are Qt 4 compatibility and less widgets outside of QtWidgets. I think we'll have to wait for the outcome of the native type converters discussion before deciding. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Access lazy Models from within QML
On Monday, March 04, 2013 16:51:32 Alan Alpert wrote: This is not a bug, ListView does not currently support canFetchMore (which only claims to be used by QAbstractItemView, so the docs are accurate already). What a strange justification to not support canFetchMore. It boggles the mind that that would be the justification for you. It should be obvious that any view should support canFetchMore. The mention of QAbstractItemView is obviously historical. Other mentions of canFetchMore in the QAIM docs do not mention it: To create models that populate incrementally, you can reimplement fetchMore() and canFetchMore(). I've uploaded a patch to try to clarify the docs. Thanks, -- 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 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
[Development] Qt for iOS - iOSStyle
By the way, I don't know if you saw my comments on your Qt for iOS Preview blog post, but... You stated that because there is no HITheme-like API on iOS, that creating QiOSStyle would be not possible. However, we can render any UIView into a buffer using [UIView drawInRect:] which we should utilize to provide as much support for native styling as that allows us to. Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. Apple users are commonly noted to be extremely particular about very small UI defects. If we spend the time to go oh, the text alignment in QLineEdit is one pixel too low on OS X, and actually take the time to fix it, iOS should be no different. So... why can't we use [UIView drawInRect:]? Qt 5 uses the same approach with NSScroller on OS X for drawing the Lion/ML scrollbars (10c6f015f45092040c281bb90a65179f598a00b1). Native styling is important wherever you are. Not everything is a fancy web app or fancy QML game with custom graphics. Although I've not tested it extensively, Qt seems to have a completely functional style implementation for Android that look like native controls for the theme my phone uses, and the themes that other phones use, on those phones. We wouldn't want Qt/Android apps to look the same on every device, or like something else. Same idea with iOS. It has a theme. That theme should be adhered to in order to maintain the same level of quality and refinement that Qt applications are able to achieve on other platforms. Apple should give us headers and documentation for CoreUI.framework and the _UIClassNameAppearanceStorage classes in UIKit. That would make life a bit easier. :) -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problems with win8 nodes in ci
CI nodes are back up . Hopefully problems are over for now. The problems during the weekend were caused by a one process consuming all cpu time from nodes. It is fixed now and at least the monitored nodes are working correctly. Simo From: development-bounces+simo.falt=digia@qt-project.org [mailto:development-bounces+simo.falt=digia@qt-project.org] On Behalf Of Fält Simo Sent: 11. maaliskuuta 2013 6:59 To: Qi Liang; development@qt-project.org Subject: Re: [Development] Problems with win8 nodes in ci Hi, Yep. All the ci nodes are done again. Investigating. Simo From: Qi Liang Sent: 9. maaliskuuta 2013 12:17 To: Fält Simo; development@qt-project.org Subject: RE: Problems with win8 nodes in ci Looks like still no success since Thu Mar 7 14:17:21 CET 2013 http://lists.qt-project.org/pipermail/ci-reports/2013-March/005401.html And latest fail time is Sat Mar 9 11:12:00 CET 2013 http://lists.qt-project.org/pipermail/ci-reports/2013-March/005564.html More details in http://lists.qt-project.org/pipermail/ci-reports/2013-March/thread.html Maybe we should not stage any change before the issue was resolved. Regards, Liang From: development-bounces+liang.qi=digia@qt-project.org [development-bounces+liang.qi=digia@qt-project.org] on behalf of Fält Simo [simo.f...@digia.com] Sent: Friday, March 08, 2013 3:08 PM To: development@qt-project.org Subject: Re: [Development] Problems with win8 nodes in ci Moi, Win8 nodes are back online. All win8 nodes were re-cloned and that caused some additional load to the host machines, which was shown as lack of resources, making builds to fail. Hopefully things get normal once the build queue gets shorter. Simo From: development-bounces+simo.falt=digia@qt-project.org [mailto:development-bounces+simo.falt=digia@qt-project.org] On Behalf Of Fält Simo Sent: 8. maaliskuuta 2013 10:44 To: development@qt-project.org Subject: [Development] Problems with win8 nodes in ci Hi, Unfortunately all windows 8 nodes in CI are currently offline. Due to that, all otherwise succeeding jobs are pending those nodes to come up. At the moment there are following jobs in queue: QtBase_dev_Integration QtDeclarative_dev_Integration QtDesktopComponents_dev_Integration We are working on to get those back up. Simo Fält Digia, Qt Visit us on: http://qt.digia.comhttp://qt.digia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Touch not working with QtQuick1 (event handling issue in QGraphicsView)
Hi, I'm debugging a major issue with QtQuick1 I'm seeing with both 5.0.0 and the current stable branch: Touch events don't work with QtQuick1's MouseArea element. As QtQuick1 items don't handle touch directly, they they rely on on the touch-mouse fallback in QApplication which creates mouse events if a touch event wasn't accepted. That works or TouchBegin events, but fails for subsequent TouchMove and TouchEnd events as QGraphicsView silently accepts touch events if it doesn't find an item that waits for touch. If a series of TouchBegin, TouchMove, TouchEnd events is sent to QGraphicsView containing QQ1 items, the following happens: 1) GraphicsScenePrivate::touchEventHandler receives a TouchBegin event. As the QQ1 items don't accept touch, the event is ignored. That triggers the touch-mouse fallback, which works fine. 2) GraphicsScenePrivate::touchEventHandler then receives TouchMove/TouchEnd events. The touch handler looks for items needing touch events (items which previously accepted a TouchBegin event), but doesn't find any. (because the QQ1 items received the fallback mouse events, not the touchBegin event) In that case, it just accepts the touchMove/touchEnd event. As the event is accepted, the touch-mouse fallback in QApplication isn't triggered. I see two ways to fix it, one is a one-liner, one's more work: * Don't silently accept touch events if no item is waiting for them. Ignoring the events triggers the touch-mouse fallback. That's the approach the attached patch takes and seems to work fine (tested with the QQ1 hello world example). * Make QQ1 items accept touch events and do the touch to mouse mapping internally Do you see issues with the first approach? I don't see why TouchMove and TouchEnd should be accepted if not handled, but TouchBegin is ignored if not handled. touch-qquick1-graphicsview.diff Description: Binary data -- Frank Osterfeld | frank.osterf...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. 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] Qt for iOS - iOSStyle
On segunda-feira, 11 de março de 2013 07.41.02, Jake Thomas Petroules wrote: Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. The whole point is that you shouldn't use QtWidgets at all on mobile platforms. Just don't. -- 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] Qt for iOS - iOSStyle
On Mon, Mar 11, 2013 at 08:37:19AM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 07.41.02, Jake Thomas Petroules wrote: Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. The whole point is that you shouldn't use QtWidgets at all on mobile platforms. Just don't. The point is that the current alternative is far from perfect as well. I don't find it hard to accept that not everyone is happy to shift compile time effort to runtime effort, or is willing or even able to drop his established workflows and tools, even on mobile platforms. Combined with the insight that the old widgets don't cut it in the animated touch space and there's no resources to maintain two stacks one might have expected a single, fully compilable stack with optional script bindings on top as primary goal. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mon, Mar 11, 2013 at 08:37:19AM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 07.41.02, Jake Thomas Petroules wrote: Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. The whole point is that you shouldn't use QtWidgets at all on mobile platforms. Just don't. Why not? I agree that QtQuick is usually the way to go for implementing mobile UI, but that doesn't exclude QtWidgets for any reasons a developer may wish to use it. When we did the BlackBerry port, we did implement a BlackBerry style, which could achieve native look and feel decently. This comes really handy when you are porting apps from the desktop. I think implementing a native iOS style wouldn't be hard. I don't know much about iOS development, but if what Jake says about being able to render controls to off-screen buffers, then it should be completely feasible. Of course, even better would be a set of QML components, but these are not mutually exclusive approaches. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roque...@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 smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On segunda-feira, 11 de março de 2013 19.45.48, André Pönitz wrote: On Mon, Mar 11, 2013 at 08:37:19AM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 07.41.02, Jake Thomas Petroules wrote: Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. The whole point is that you shouldn't use QtWidgets at all on mobile platforms. Just don't. The point is that the current alternative is far from perfect as well. Indeed, but the current solution is not an option either. QtWidgets will not get the full look and feel of iOS. It was not meant to do animations and the effects required by their LF. So we have no solution at this point. And I'd argue that QtWidgets will not ever be good enough, whereas the Qt Quick solution can be. Combined with the insight that the old widgets don't cut it in the animated touch space and there's no resources to maintain two stacks one might have expected a single, fully compilable stack with optional script bindings on top as primary goal. If that's possible, sure. But it's possibly even easier to write a single Qt Quick-based solution, with no C++ API. Given the lack of manpower, that's an alternative to consider. -- 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] Qt for iOS - iOSStyle
On segunda-feira, 11 de março de 2013 16.54.31, Rafael Roquetto wrote: Why not? I agree that QtQuick is usually the way to go for implementing mobile UI, but that doesn't exclude QtWidgets for any reasons a developer may wish to use it. When we did the BlackBerry port, we did implement a BlackBerry style, which could achieve native look and feel decently. This comes really handy when you are porting apps from the desktop. I think implementing a native iOS style wouldn't be hard. I don't know much about iOS development, but if what Jake says about being able to render controls to off-screen buffers, then it should be completely feasible. That will give you the right static look, but not the feel. In order to implement the right feel, with animations, shadows, etc., you need a lot more. If things glow, slide, bounce, it will be extremely hard to implement with QtWidgets. -- 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] Qt for iOS - iOSStyle
On Mon, Mar 11, 2013 at 01:40:18PM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 16.54.31, Rafael Roquetto wrote: Why not? I agree that QtQuick is usually the way to go for implementing mobile UI, but that doesn't exclude QtWidgets for any reasons a developer may wish to use it. When we did the BlackBerry port, we did implement a BlackBerry style, which could achieve native look and feel decently. This comes really handy when you are porting apps from the desktop. I think implementing a native iOS style wouldn't be hard. I don't know much about iOS development, but if what Jake says about being able to render controls to off-screen buffers, then it should be completely feasible. That will give you the right static look, but not the feel. In order to implement the right feel, with animations, shadows, etc., you need a lot more. If things glow, slide, bounce, it will be extremely hard to implement with QtWidgets. It is *harder* than with QML - but possible. And I don't think it is that hard. I am not saying that is easy, though. We used QtScroller (kineticscroller) for instance, to implement smooth list view animation. If you can render using the native API to an off-screen buffer, than it is doable. I would even risk to say that hard is not the proper adjective here, but instead laborious. To implement things like glowing, one can for instance implement an event handler inside the style that monitors mouse events and does the job of animating. Well at least it worked well for BlackBerry but I can't say anything about Mac since I don't know the API. If someone decides to give it a shot, though, I would be happy to help. Having said that, I agree QML components are the most sensible way to go. Just my $0.02 Rafael -- Rafael Roquetto | rafael.roque...@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 smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
here is one other solution http://docs.appcelerator.com/titanium/latest/ javascript and native looking widgets under ios Raul On Mar 11, 2013, at 10:58 PM, Rafael Roquetto rafael.roque...@kdab.com wrote: On Mon, Mar 11, 2013 at 01:40:18PM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 16.54.31, Rafael Roquetto wrote: Why not? I agree that QtQuick is usually the way to go for implementing mobile UI, but that doesn't exclude QtWidgets for any reasons a developer may wish to use it. When we did the BlackBerry port, we did implement a BlackBerry style, which could achieve native look and feel decently. This comes really handy when you are porting apps from the desktop. I think implementing a native iOS style wouldn't be hard. I don't know much about iOS development, but if what Jake says about being able to render controls to off-screen buffers, then it should be completely feasible. That will give you the right static look, but not the feel. In order to implement the right feel, with animations, shadows, etc., you need a lot more. If things glow, slide, bounce, it will be extremely hard to implement with QtWidgets. It is *harder* than with QML - but possible. And I don't think it is that hard. I am not saying that is easy, though. We used QtScroller (kineticscroller) for instance, to implement smooth list view animation. If you can render using the native API to an off-screen buffer, than it is doable. I would even risk to say that hard is not the proper adjective here, but instead laborious. To implement things like glowing, one can for instance implement an event handler inside the style that monitors mouse events and does the job of animating. Well at least it worked well for BlackBerry but I can't say anything about Mac since I don't know the API. If someone decides to give it a shot, though, I would be happy to help. Having said that, I agree QML components are the most sensible way to go. Just my $0.02 Rafael -- Rafael Roquetto | rafael.roque...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mon, Mar 11, 2013 at 01:38:28PM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 19.45.48, André Pönitz wrote: On Mon, Mar 11, 2013 at 08:37:19AM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 07.41.02, Jake Thomas Petroules wrote: Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. The whole point is that you shouldn't use QtWidgets at all on mobile platforms. Just don't. The point is that the current alternative is far from perfect as well. Indeed, but the current solution is not an option either. QtWidgets will not get the full look and feel of iOS. It was not meant to do animations and the effects required by their LF. So we have no solution at this point. And I'd argue that QtWidgets will not ever be good enough, whereas the Qt Quick solution can be. Combined with the insight that the old widgets don't cut it in the animated touch space and there's no resources to maintain two stacks one might have expected a single, fully compilable stack with optional script bindings on top as primary goal. If that's possible, sure. Why shouldn't it be possible to have a clearly layered stack with proper interfaces? But it's possibly even easier to write a single Qt Quick-based solution, with no C++ API. Given the lack of manpower, that's an alternative to consider. I am not sure I understand what this alternative would consist of. A solution that pushes common activities that can be done at compile time to every user's run time is not an approach that scales well outside the Mobile App comfort zone the current incarnation of Qt Quick is addressing. It does not scale down to real embedded, and it does not scale up to the usual bunch of engineering applications Qt was serving well in the past. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mar 11, 2013, at 5:36 PM, Raul Metsma r...@innovaatik.ee wrote: here is one other solution http://docs.appcelerator.com/titanium/latest/ javascript and native looking widgets under ios Perhaps we could look into this. On Mar 11, 2013, at 11:37 AM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 11 de março de 2013 07.41.02, Jake Thomas Petroules wrote: Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. The whole point is that you shouldn't use QtWidgets at all on mobile platforms. Just don't. I never said anything about widgets. I'm talking about QiOSStyle which would also be used by QtQuick.Controls just like Jens is doing now for the desktop. QiOSStyle would power both widgets and QML controls, just like how the others work. On Mar 11, 2013, at 3:54 PM, Rafael Roquetto rafael.roque...@kdab.com wrote: Why not? I agree that QtQuick is usually the way to go for implementing mobile UI, but that doesn't exclude QtWidgets for any reasons a developer may wish to use it. When we did the BlackBerry port, we did implement a BlackBerry style, which could achieve native look and feel decently. This comes really handy when you are porting apps from the desktop. I think implementing a native iOS style wouldn't be hard. I don't know much about iOS development, but if what Jake says about being able to render controls to off-screen buffers, then it should be completely feasible. Of course, even better would be a set of QML components, but these are not mutually exclusive approaches. My thoughts exactly. Another thing is, there seem to be some private classes named like _UISearchBarAppearanceStorage in UIKit. Obviously, we can't use these in the final product, but perhaps we could play around with them during development in order to try and break controls down into their individual components (colors, images) which we can cache manually in QiOSStyle. There are messages such as: imageForIcon:state:, searchFieldBackgroundImageForState:, separatorImage, etc., which potentially look relevant. https://github.com/nst/iOS-Runtime-Headers Also, this is about native control styling. So... let's focus on that and not turn this into a widgets vs QML debate. Like Rafael said, the two are not mutually exclusive. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] What do you know about Qt::Device/IoHandle?
Hi all, I have been trying to get a patch accepted to QSerialPort: https://codereview.qt-project.org/#change,48393 Basically, my problem is that I want to use QSerialPort, but I need to run the serial port in non-exclusive mode. My patch adds a handle() function to get the serial port's file descriptor, much like QFileDevice::handle(), QAbstractSocket::socketDescriptor(), QWidget::winId(), and QProcess::pid(). Once I have the file descriptor, disabling exclusive mode is a one-line call to ioctl. There are essentially two ways to implement QSerialPort::handle(): 1. Put #ifdef around the function prototype so that handle() returns an int on Unix and a HANDLE (a.k.a. void*) on Windows. In the documentation, do not specify handle()'s return type. 2. Define a new type analogous to WId and Q_PID for serial port handles. Use #ifdef to make this type equivalent to int on Unix and HANDLE or void* on Windows. Make handle() return this type. QSerialPort's primary maintainer, Laszlo Papp, is in favor of option #2, but says that it has to wait until a typedef Qt::Device/IoHandle is added to QtCore. He says that this Qt::Device/IoHandle is going to be for serial ports, parallel ports, bluetooth, and USB. It seems to me that Qt::Device/IoHandle could only work as long as Qt is not ported to any operating system that uses different data types for serial port, parallel port, bluetooth, and USB handles. However, Laszlo says that at least one QtCore developer supports this approach anyway. The patch was submitted 3 weeks ago and the problem still exists, so I'm bringing the question here. What do you know about Qt::Device/IoHandle, and how would you implement QSerialPort::handle()? Thanks, -Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On segunda-feira, 11 de março de 2013 23.02.02, André Pönitz wrote: Why shouldn't it be possible to have a clearly layered stack with proper interfaces? Maybe possible is not the right point. The point is whether it is feasible with the time and manpower available. Defining a proper interface takes time. Not defining it saves time, therefore allows us to finish the higher-level API sooner. But it's possibly even easier to write a single Qt Quick-based solution, with no C++ API. Given the lack of manpower, that's an alternative to consider. I am not sure I understand what this alternative would consist of. A QML-only API. A solution that pushes common activities that can be done at compile time to every user's run time is not an approach that scales well outside the Mobile App comfort zone the current incarnation of Qt Quick is addressing. It does not scale down to real embedded, and it does not scale up to the usual bunch of engineering applications Qt was serving well in the past. -- 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] What do you know about Qt::Device/IoHandle?
On segunda-feira, 11 de março de 2013 19.07.53, Alex Henrie wrote: It seems to me that Qt::Device/IoHandle could only work as long as Qt is not ported to any operating system that uses different data types for serial port, parallel port, bluetooth, and USB handles. However, Laszlo says that at least one QtCore developer supports this approach anyway. Did he also mention that the QtCore maintainer thinks that using one type for all of those is a bad idea? -- 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
[Development] cmake for Qt
Hello
This is my first to compile qt project use cmake.
I written CmakeLists.txt:
PROJECT(test)
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
FIND_PACKAGE(Qt4 REQUIRED)
INCLUDE(${QT_USE_FILE})
ADD_DEFINITIONS(${QT_DEFINITIONS})
SET(test_HEADERS widget.h comparefilethread.h)
SET(test_SOURCES main.cpp widget.cpp comparefilethread.cpp)
QT4_WRAP_CPP(test_HEADERS_MOC ${test_HEADERS})
ADD_EXECUTABLE(test ${test_HEADERS_MOC} ${test_SOURCES})
TARGET_LINK_LIBRARIES(test ${QT_LIBRARIES})
When I run Cmake
Maybe everything perfect. Makefile has been created.
output --
-- The C compiler identification is GNU 4.1.2
-- The CXX compiler identification is GNU 4.1.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found
-- Found Qt4: /usr/local/Trolltech/Qt-4.7.1/bin/qmake (found version 4.7.1)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/incam/test/wps/build
---
But when I run make, some errors occurred.
-- CmakeError.log ---
Determining if the Q_WS_WIN exist failed with the following output:
Change Dir: /home/incam/test/wps/build/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/gmake cmTryCompileExec1901404822/fast
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec1901404822.dir/build.make
CMakeFiles/cmTryCompileExec1901404822.dir/build
gmake[1]: Entering directory `/home/incam/test/wps/build/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report
/home/incam/test/wps/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec1901404822.dir/CheckSymbolExists.cxx.o
/usr/bin/c++-I/usr/local/Trolltech/Qt-4.7.1/include-o
CMakeFiles/cmTryCompileExec1901404822.dir/CheckSymbolExists.cxx.o -c
/home/incam/test/wps/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
/home/incam/test/wps/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx: In
function ‘int main(int, char**)’:
/home/incam/test/wps/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx:8:
错误：‘Q_WS_WIN’ 在此作用域中尚未声明
gmake[1]: ***
[CMakeFiles/cmTryCompileExec1901404822.dir/CheckSymbolExists.cxx.o] 错误 1
gmake[1]: Leaving directory `/home/incam/test/wps/build/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec1901404822/fast] 错误 2
File /home/incam/test/wps/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx:
/* */
#include QtCore/qglobal.h
int main(int argc, char** argv)
{
(void)argv;
#ifndef Q_WS_WIN
return ((int*)(Q_WS_WIN))[argc];
#else
(void)argc;
return 0;
#endif
}
…
---
Could anybody tell me why?
Thanks
Ken
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] What do you know about Qt::Device/IoHandle?
On Tue, Mar 12, 2013 at 1:07 AM, Alex Henrie alexhenri...@gmail.com wrote: 1. Put #ifdef around the function prototype so that handle() returns an int on Unix and a HANDLE (a.k.a. void*) on Windows. In the documentation, do not specify handle()'s return type. As written, this does not sound a good idea to me because of the following two concerns: 1) It is inconsistent with the rest. 2) The public documentation and interface should be in line. 2. Define a new type analogous to WId and Q_PID for serial port handles. Use #ifdef to make this type equivalent to int on Unix and HANDLE or void* on Windows. Make handle() return this type. QSerialPort's primary maintainer, Laszlo Papp, is in favor of option #2, but says that it has to wait until a typedef Qt::Device/IoHandle is added to QtCore. He says that this Qt::Device/IoHandle is going to be for serial ports, parallel ports, bluetooth, and USB. Hmm, that is a bit of misinterpretation. 1) I am not the primary maintainer. 2) I did not try to say, it has to be added to QtCore. All I said, it needs some more time to investigate about the proper API and considering that this feature has not been added to QExtSerialPort and so forth for more than eight years, I think it is not the most important thing to get done now for the release. The feature freeze was announced for the middle March, and I have concerns that I cannot finish the investigation I wished to do for this (i.e. even just for being able to review properly). Hence, I was trying to suggest to postpone the feature to 5.2. The idea is that, I personally do not wish to have an API added in a rush. We still have a room for the existing features to get up to the quality before adding further ones for this release. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] cmake for Qt
Hi,
This should go to qt-interest mail list instead of qt-development.
BTW, this error has nothing to do with CMAKE. and I couldn't understand
what you are trying to do with following code.
#ifndef Q_WS_WIN
return ((int*)(Q_WS_WIN))[argc];
...
Regards,
Debao
On Tue, Mar 12, 2013 at 11:08 AM, pengliang(彭亮) pengli...@founder.comwrote:
Hello
This is my first to compile qt project use cmake.
I written CmakeLists.txt:
PROJECT(test)
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
FIND_PACKAGE(Qt4 REQUIRED)
INCLUDE(${QT_USE_FILE})
ADD_DEFINITIONS(${QT_DEFINITIONS})
SET(test_HEADERS widget.h comparefilethread.h)
SET(test_SOURCES main.cpp widget.cpp comparefilethread.cpp)
QT4_WRAP_CPP(test_HEADERS_MOC ${test_HEADERS})
ADD_EXECUTABLE(test ${test_HEADERS_MOC} ${test_SOURCES})
TARGET_LINK_LIBRARIES(test ${QT_LIBRARIES})
** **
** **
** **
When I run Cmake
Maybe everything perfect. Makefile has been created.
output --
-- The C compiler identification is GNU 4.1.2
-- The CXX compiler identification is GNU 4.1.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found
-- Found Qt4: /usr/local/Trolltech/Qt-4.7.1/bin/qmake (found version
4.7.1)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/incam/test/wps/build
---
** **
But when I run make, some errors occurred.
** **
-- CmakeError.log ---
Determining if the Q_WS_WIN exist failed with the following output:
Change Dir: /home/incam/test/wps/build/CMakeFiles/CMakeTmp
** **
Run Build Command:/usr/bin/gmake cmTryCompileExec1901404822/fast
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec1901404822.dir/build.make
CMakeFiles/cmTryCompileExec1901404822.dir/build
gmake[1]: Entering directory
`/home/incam/test/wps/build/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report
/home/incam/test/wps/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec1901404822.dir/CheckSymbolExists.cxx.o
/usr/bin/c++-I/usr/local/Trolltech/Qt-4.7.1/include-o
CMakeFiles/cmTryCompileExec1901404822.dir/CheckSymbolExists.cxx.o -c
/home/incam/test/wps/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
/home/incam/test/wps/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx: In
function ‘int main(int, char**)’:
/home/incam/test/wps/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx:8:
错误：‘Q_WS_WIN’ 在此作用域中尚未声明
gmake[1]: ***
[CMakeFiles/cmTryCompileExec1901404822.dir/CheckSymbolExists.cxx.o] 错误 1**
**
gmake[1]: Leaving directory
`/home/incam/test/wps/build/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec1901404822/fast] 错误 2
** **
File /home/incam/test/wps/build/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx:
/* */
#include QtCore/qglobal.h
** **
int main(int argc, char** argv)
{
(void)argv;
#ifndef Q_WS_WIN
return ((int*)(Q_WS_WIN))[argc];
#else
(void)argc;
return 0;
#endif
}
…
---
** **
Could anybody tell me why?
** **
Thanks
Ken
** **
** **
** **
** **
** **
** **
** **
** **
** **
** **
** **
** **
** **
** **
** **
** **
___
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] Access lazy Models from within QML
On Mon, Mar 11, 2013 at 3:53 AM, Stephen Kelly stephen.ke...@kdab.com wrote: On Monday, March 04, 2013 16:51:32 Alan Alpert wrote: This is not a bug, ListView does not currently support canFetchMore (which only claims to be used by QAbstractItemView, so the docs are accurate already). What a strange justification to not support canFetchMore. It boggles the mind that that would be the justification for you. This is not a justification to not support canFetchMore. It's an explanation that we don't currently support canFetchMore in ListView. If you have the time to add that support to ListView, I look forward to your patch :) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
