The problem is serious enough, indeed, that Python 3 has resorted to a hack
where they use a private Unicode range to encode the bytes between 128
and 255 in strings that fail normal decoding. I think that putting this hack
into
QString is unthinkable, and the concept of a platform string
On 25.04.2014 12:18, Joerg Bornemann wrote:
Yep, I hear people keep repeating the mantra QML is declarative. It's
just QML/JS that isn't.
I think the declarative-mantra is a good idea, especially when used for
_specifying_ (not programming) the GUI.
At Adobe they tried it with pure
So we started to design our UI
with QML. I liked the design to split business logic into
C++ and UI design into QML and I still like it, but I came across
several blocking issues (some of them are only valid for our application, some
of them are general):
- Our application has a huge
So, here is what we will do:
- create one branch named 'qt' out of current stable
- block any other branches in gerrit
- move on with this branch, and announce the current status of it (open for
features, feature freeze, hardening...) on the mailing list
In addition there seems to be a
-Original Message-
From: development-bounces+tvaneerd=rim@qt-project.org
[mailto:development-bounces+tvaneerd=rim@qt-project.org] On
Behalf Of Thiago Macieira
Sent: Friday, February 28, 2014 11:26 AM
To: development@qt-project.org
Subject: Re: [Development] Binary
Sorry, there is probably a KDE email list or something that I should post this
to, but I know it is very closely related to Qt:
On http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
there is:
You cannot...
- For existing functions of any type:
- add an overload
+tvaneerd=blackberry@qt-project.org]
On Behalf Of Tony Van Eerd
Sent: Thursday, February 27, 2014 3:06 PM
To: development@qt-project.org
Subject: [Development] Binary Compatibility question (KDE)
Sorry, there is probably a KDE email list or something that I should post this
to, but I know
Hi,
- Have an API review board, and for
A review board would indeed be a good thing to have, not necessarily
restricted to API reviews only.
The problem also currently is that reviewers are distracted by a lot
of mundane things (check for compilation, compiler warnings, check
I agree on detach(): you can easily trigger a detach() by calling data().
Well, as long as you ensure that your object is not const.
I wouldn't get rid of detach() just because data() can do the same thing. If
it is useful, I'd rather use the proper name for it.
The question is whether it
The Qt coding conventions
(http://qt-project.org/wiki/Coding-Conventions)
recommend using an enum over 'const int'.
The rationale given there is that an enum will be replaced at
compile-time resulting in 'faster code'. Won't that be the case with
'const int' as well? I think a
http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful
-Original Message-
From: development-bounces+tvaneerd=rim@qt-project.org
[mailto:development-bounces+tvaneerd=rim@qt-project.org] On
Behalf Of Thiago Macieira
Sent: Tuesday, February 11, 2014 11:15 AM
I've followed std::optional closely through the standardization process, so I
can give some background info:
- from the beginning Boost::optional was written with a pointer-like syntax:
optionalint op = maybe_get_the_value();
if (op) {
int x = *op;
Yes, for QOptional you wouldn't want to name it 'isOkay()'. But you
*will* have the problem of ambiguous implicit conversion with
QOptionalbool, which I assume will be allowed even if there is no
QString::toBool(). Alternatively you could omit implicit value conversion
entirely and require
On 13 Jan 2014, at 5:06 PM, Alvin Yulo wrote:
Here are the QDrive APIs that Tony mentioned below:
https://codereview.qt-project.org/#change,75336,patchset=1
Cool.
But I think maybe we should get the C++ APIs into qtbase, so that
QtQuick.Controls.FileDialog doesn't depend on
1) well, it can go to qt base, but what module? We can't add mount and
monitor to qtcore, because Linux implementation will require dbus.
I'm not familiar with the details there, can you briefly explain why dbus is
necessary and why it is a bad thing for qtcore?
2) separate, see above.
There was some work going on inside BlackBerry to revamp QSystemStorageInfo.
Last version I saw had:
QDrive:
- similar to QDir (not a QObject!).
- construct from URI/path (ie dev/sda1 or D:\)
- mount/unmount/is-it-mounted/list-of-mount-points/etc
- total/available space
QDriveWatcher:
-
: Tony Van Eerd; Alvin Yulo; David Faure; Rutledge Shawn; Alan Alpert;
development@qt-project.org
Subject: Re: [Development] moving some SystemInfo stuff into qtbase (was Re:
QtDriveInfo module in Playground)
2014/1/10 Matt Broadstone mbroa...@gmail.commailto:mbroa...@gmail.com
On Fri, Jan 10, 2014
- I think there is cleanup that could be done.
- I think it is still too early to do so. I'm still running XP! (true, not for
much longer...)
-Original Message-
From: development-bounces+tvaneerd=blackberry@qt-project.org
Bay,
Tony van
Eerd and me. I'd like a few more Qt devs showing up and presenting our
more...
ahem, pragmatic / conservative... solutions to other C++ library devs.
-- Forwarded message --
Subject: [Interest] [ANN] C++Now 2014: 5 Days to Submissions Deadline
Date: terça
of the Qt Project, we had Charley Bay,
Tony van
Eerd and me. I'd like a few more Qt devs showing up and presenting
our more...
ahem, pragmatic / conservative... solutions to other C++ library
devs.
This was my first time at the C++Now! conference in 2013 -- previously
named BoostCon.
Here's
Is it common/uncommon/unheard-of to have a 'valid' property:
Q_PROPERTY( bool valid READ isValid NOTIFY validChanged )
I'm thinking about classes like 'DeviceLocation' which would update with GPS
changes, but at some point might just become invalid (or start invalid, until
GPS turns on, etc).
specific.
From: Hausmann Simon [mailto:simon.hausm...@digia.com]
Sent: Friday, November 29, 2013 2:20 PM
To: Tony Van Eerd; development@qt-project.org
Subject: SV: [Development] isValid() as a property
Imho isValid is fine, but generally I would suggest a more context specific
name, i.e
On Fri, 29 Nov 2013, Tony Van Eerd wrote:
in the cases I am looking at, if isValid() == false, then all the
other
properties are invalid, and return , -1, etc. It really does mean
the
whole object is invalid.
(except maybe an 'id', in the case of, say, a Battery object - the id
Let's realize that there are probably 2 separate categories of code worth
talking about, and then also some overlap:
A - common code for internal implementation
ie a PpsObject class would be used to implement many standard Qt APIs
on the BB/QNX platform
B - useful code _for enduser
But that's a long term plan, v4vm isn't even released yet (new in 5.2
remember) and there's still tons of work to do. Until v4vm is ready to
take over from QtScript, which will still be a while, I believe the
recommendation is to keep using QtScript. It's deprecated and done
because we've
Most of BlackBerry's APIs are async.
We are looking at moving some of these APIs into Qt.
Just as one example, WiFi Direct.
I have been attempting to come up with some solid guidelines of how to deal
with errors on async operations.
Some things to consider:
- the initial request may fail. ie
It could also fail later, as it is mostly asynchronous. Or it could
succeed with a result. ie
Q_SIGNAL void deviceConntected(SomeDevice device);
Q_SIGNAL void deviceConnectionFailed(SomeOtherConnectError
error);
or one signal:
Q_SIGNAL void
might want to change the toLower() docs:
QString str = Qt by NOKIA;
str = str.toLower();// str == qt by nokia
http://qt-project.org/doc/qt-5.0/qtcore/qstring.html#toLower
-
This transmission (including any
-Original Message-
ject.org; development@qt-project.org
Subject: Re: [Development] [Interest] [ANN] Registration for C++Now
2013 is now open
On terça-feira, 11 de dezembro de 2012 13.14.00, Boris Kolpackov wrote:
Speakers
If you are interested in presenting, we are currently
-Original Message-
[mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf
Of Ziller Eike
On 23 Nov 2012, at 11:20, Peter Hartmann phartm...@rim.com wrote:
Do you intend to upgrade this version of Qt that's installed on the
device
without upgrading the
-feira, 16 de novembro de 2012 23.46.32, Tony Van Eerd wrote:
C++1y (ie whatever the next standard might be called) will likely
have even
more threading options. Including an executor model where you queue
up
std::functions to be run on background thread(s). But the background
threading
Nope.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3378.pdf
-Original Message-
From: Olivier Goffart [mailto:oliv...@woboq.com]
Sent: Friday, November 16, 2012 6:58 PM
To: Tony Van Eerd
Cc: development@qt-project.org
Subject: Re: [Development] The future of QFuture
C++1y (ie whatever the next standard might be called) will likely have even
more threading options.
Including an executor model where you queue up std::functions to be run on
background thread(s). But the background threading is configurable by the
fact that the executor object isn't
QThread:
- needs new docs (coming in 5.0)
- often misused (you're doing it wrong)
- results in too many dedicated threads (typically)
- or threads created/destroyed too often
QtConcurrent::run()
- I thought this was a better alternative for one shot tasks
- now it sounds like QtConcurrent is not
I think Windows also uses 0-width to mean the same thing.
On the other hand, I worked on a drawing library that used sub-pixel lines.
Via good anti-aliasing, A 0.5 width line, even if vertical/horizontal, would be
drawn semi-transparent. A 0-width line would thus be invisible.
[mailto:szehowe@gmail.com]
Sent: Tuesday, October 09, 2012 11:12 PM
To: Tony Van Eerd
Cc: development@qt-project.org
Subject: Re: [Development] QThread usage/guidance
On Wed, Oct 10, 2012 at 1:20 AM, Tony Van Eerd
tvane...@rim.commailto:tvane...@rim.com wrote:
Speaking of docs, should the docs
-Original Message-
From: Olivier Goffart [mailto:oliv...@woboq.com]
So I'd like to understand how it works. Maybe that means looking
more at
the code than the docs. But the code can change - the real
contract is
in the docs.
Depends of the point of view... To me the real
-Original Message-
From: Giuseppe D'Angelo [mailto:dange...@gmail.com]
Sent: Wednesday, October 10, 2012 12:46 PM
To: Tony Van Eerd
Cc: Sze Howe Koh; development@qt-project.org
Subject: Re: [Development] QThread usage/guidance
On 10 October 2012 16:00, Tony Van Eerd tvane
-Original Message-
From: development-bounces+tvaneerd=rim@qt-project.org
[mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf
Of Kevin Krammer
This mailing list is not really for question on how to use Qt. You
should
use the interest mailing-list or the
What was the final resolution (if any) of the email thread
QThread::finished() race → fixing QThread
http://lists.qt-project.org/pipermail/development/2011-November/000284.html
In particular as seen in
So that is the 'recommended' style then?
-Original Message-
From: Olivier Goffart [mailto:oliv...@woboq.com]
Sent: Friday, October 05, 2012 10:54 AM
To: development@qt-project.org
Cc: Tony Van Eerd
Subject: Re: [Development] QThread usage/guidance
On Friday 05 October 2012 14:31
I think proper resolution dependence and independence requires, at times at
least, 2 separate measurements for each widget:
visual measure:
- physical measurement is in arcminutes (ie angle between top-of-dot,
your-eye, bottom-of-dot for the smallest dot you can see - ie discerning the
-Original Message-
From: Shawn Rutledge [mailto:shawn.t.rutle...@gmail.com]
Sent: Thursday, October 04, 2012 11:09 AM
To: Tony Van Eerd
Cc: development@qt-project.org
Subject: Re: [Development] resolution independence (was Re: Retina
display support)
On 4 October 2012 16:27, Tony
-Original Message-
Not really, the id can't change.
The id is only set once when the QMutexPrivate is used for the first
time.
(And that change has already been aquired for a long time)
Acquire is uneccessary.
It was added in commit 5bfeab87 when the uses of the operator
2012 13.42.13, Tony Van Eerd wrote:
By the way, I assume the intent is to limit the implementation to
only using
int/pointer-sized atomics, not double width atomics?
We can use double-width atomics if necessary. But the only architecture
for
which I implemented that is x86 32-bit (via
I've been looking at the implementation of QMutex (et al), via woboq, ie
http://code.woboq.org/qt5/qtbase/src/corelib/thread/qmutex.cpp.html. (nice
work on the code viewer, by the way!)
I'm wondering if there isn't a subtle race condition in lockInternal() at line
358:
358 if
-Original Message-
We check for that case shortly after:
361 if (d != d_ptr.loadAcquire()) {
362//Either the mutex is already unlocked, or relocked with
another mutex
363d-deref();
364continue;
365 }
Or course. Very next lines! shortly after
15.50.12, Tony Van Eerd wrote:
We check for that case shortly after:
361 if (d != d_ptr.loadAcquire()) {
362//Either the mutex is already unlocked, or relocked with
another mutex
363d-deref();
364continue;
365 }
Or course. Very next
-Original Message-
I have a change to document more the internal, but it is not merged
yet.
https://codereview.qt-project.org/33739
Staged now, thanks :-)
It would be nice if the new comments on the if (d-ref()) line pointed out that
'd' is never invalid because we recycle, but
-Original Message-
internals? (P.S. I noticed one of those had a static QBasicMutex
inside a function, which gcc will then put a 'mutex' around...)
correction: no constructor, no compiler-installed mutex. I would hope/assume.
::lockInternal() race condition?
On quinta-feira, 20 de setembro de 2012 16.53.23, Tony Van Eerd wrote:
Tony: I'd really appreciate giving the implementation a thorough
once-
over.
I will try to find the time, although I'm already further down the
rabbit
hole than I should be. I
51 matches
Mail list logo
