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
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
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
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
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
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.
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,
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,
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
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
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
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
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
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
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
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
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
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
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
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
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).
21 matches
Mail list logo
