Re: [Development] A QtCore class for event-driven jobs
On Sun, Sep 8, 2013 at 3:06 AM, Aleix Pol aleix...@kde.org wrote: Either that or not rushing into porting everything to QJob. Having it in a separate library would mean having QtCoreJobs, QtNetworkJobs, etc. Doesn't seem to be very flexible. I also think it makes sense to have a separate playground module for experiment as Thiago and Konstantin suggested. It would be similar to qtlogger, scene graph, etc which can then later be merged back into main modules if needed. Although, having a playground module even after stabilized for a somewhat similar scenario as QIODevice: network devices, core devices, etc, seems a bit inconsistent, especially if it was also a common functionality as it seems, and not corner case. If it is not a that common functionality, then perhaps, yes... -- Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A QtCore class for event-driven jobs
My two cents (with top quote apology :)
I really like it when classes get added to Qt that can be used out of the box
without sub-classing. That's been a guideline in the past, functionality that
the end users of Qt can use right away. I really really like that philosophy
(and the change to make QThread's run method non-virtual is an example of that).
I also think that it is even better when functionality gets added to Qt that is
used within, by other classes in the same module or by other modules (at least
for classes that are lower down in the dependency chain). Alternatively it is
great if API is in place that makes combining it with a specific other class
particularly easy.
With that in mind, I think that the job class represents an example that is
perhaps more interesting for a framework developer on top of Qt, not an
application developer. Consequently I suggest to let it have the term
Abstract in its name.
I also wonder if it makes sense to perhaps provide convenience API to connect
this with the state machine framework?
Lastly IMHO this should be accompanied with a documented example that shows how
to build a job based framework.
Simon
Fra: David Faure
Sendt: 19:47 fredag 6. september 2013
Til: development@qt-project.org
Emne: [Development] A QtCore class for event-driven jobs
I would like to propose the inclusion of a QJob class in QtCore, based on
years of experience with KIO::Job and KJob.
The idea is to encapsulate an event driven asynchronous operation into a job
class. Example use cases:
- a network download with QNetworkAccessManager.
- operations (command+reply) over a QLocalSocket or QTcpSocket (like akonadi).
- long async dbus calls (special case of the previous line)
- long tasks executed by external processes (e.g. make from an IDE, unrar
from an archive program)
...
At the core, QJob is really just a class with start() and kill(), calling pure
virtual methods doStart() and doKill(), and signals, most importantly the
result(QJob *) signal.
The expected use case is:
void SomeClass::methodWithAsynchronousJobCall()
{
QJob* job = someoperation(some parameters);
connect(job, SIGNAL(result(QJob*)),
this, SLOT(handleResult(QJob*)));
job-start(); // or it could just autostart, which I actually prefer...
}
(other connects, specific to the job)
And handleResult is usually at least:
void SomeClass::handleResult( QJob *job )
{
if (job-error()) {
// handle error
} else {
// handle succesful job completion, if needed
}
}
But it can and should also have the following features:
* error code, error text
* suspend/resume with doSuspend/doResume virtual methods
* capabilities Killable and Suspendable, to avoid trying these on jobs that
don't support them
* kill(Quietly) vs kill(EmitResult), for the app's convenience
* a finished signal that is emitted with both types of killing, for things
like progress dialogs
* auto-deletion (on by default, can be turned off)
* synchronous exec() using a QEventLoop, with a big fat huge warning about not
using that in GUI apps (ideally only to be used in unittests or separate
threads).
* more standard signals for progress info, messages, warnings..
The whole point of standardizing such signals is that it allows generic GUIs
to be built on top, so that your app or your desktop can show the progress of
multiple concurrent jobs, of different types (file download, CD burning, mail
checking, etc. etc.)
Finally, for the benefit of job implementors, QJob would support sub-jobs.
The job implementation would choose when to create these subjobs (all at once
initially, to have them run in parallel, or one after the other, for sequence
of operations). KDE currently does that in a subclass (KCompositeJob) but
Thiago and I (and kio, and akonadi) agree that it's better to have it all in
one class instead.
We also have a standard interface for error handling so that all jobs from a
given framework can have their error handled the same way, but thinking about
it, that part could stay separate, at least for now.
Well, that's it. So why this email? Because Thiago asked me to, and to gather
some support. I plan to make a merge request for Qt 5.2.
Thiago asked more specifically:
* API-wise, can't this be merged with QFuture?
- no, because QFuture encapsulates a value, with blocking methods for getting
the value, even available as casting-to-the-value. If we imagine a QFuture
that wraps a QJob, and the blocking method calling exec(), we'd have a lot
more nested event loops than is good for the health of our programs.
On the other hand, QJob would not be related to any value. It's really a
QObject that informs of progress via signals.
* relation to QRunnable?
A runnable is also some sort of job, but the implementation is completely
different: a runnable is one sync method, while a qjob is all signals/slots
based, with start() returning immediately. So one can't be used like the
other, a given task
[Development] [Question] Implementation of XML character validation
All XML validation in Qt is based on XML 1.0 (and not the newer 1.1 standard).
I found at least 3 places where validity is checked:
1. in qxmlstream.cpp:
Method resolveCharRef:
//checks for validity
ok = (s == 0x9 || s == 0xa || s == 0xd || (s = 0x20 s = 0xd7ff)
|| (s = 0xe000 s = 0xfffd) || (s = 0x1 s =
QChar::LastValidCodePoint));
Method scanUntil:
//checks for invalidity
if (c 0x20 || (c 0xFFFD c 0x1) || c
QChar::LastValidCodePoint )
2. In qxmlutils.cpp:
bool QXmlUtils::isChar(const QChar c)
{
return (c.unicode() = 0x0020 c.unicode() = 0xD7FF)
|| c.unicode() == 0x0009
|| c.unicode() == 0x000A
|| c.unicode() == 0x000D
|| (c.unicode() = 0xE000 c.unicode() = 0xFFFD);
}
It is pretty much the same as the above checks, except that it doesn't check
for characters in the range 0x1 - 0x10.
It think this is a bug, especially because the source is referring to the
standard at http://www.w3.org/TR/REC-xml/#NT-Char, which says:
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] |
[#xE000-#xFFFD] | [#x1-#x10] /* any Unicode character, excluding the
surrogate blocks, FFFE, and . */
Now, I have three questions:
1. Can someone confirm if the check in QXmlUtils is actually a bug?
2. Wouldn't it be better to move these checks to QChar, so that at least there
is only one implementation?
3. Is there a reason to stick to XML1.0, or should Qt also implement the XML1.1
standard?
According to the XML 1.1 standard (http://www.w3.org/TR/xml11/#charsets),
allowed characters are:
[2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] |
[#x1-#x10] /* any Unicode character, excluding the surrogate
blocks, FFFE, and . */
[2a] RestrictedChar ::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] |
[#x86-#x9F]
So the allowed character range is a little bit extended (now includes all
characters between 0x0001 and 0x0020). In addition, XML1.1 has defined some
characters to be highly discouraged, but still valid.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Question] Implementation of XML character validation
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD]
| [#x1-#x10]/* any Unicode character, excluding the surrogate
blocks, FFFE, and . */
in XML 1.0 is quite the same as
[2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] /* any
Unicode character, excluding the surrogate blocks, FFFE, and . */
[2a] RestrictedChar ::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] |
[#x86-#x9F]
in XML 1.1, except of [U+007F..U+0084] and [U+0086..U+009F], which are
prohibited now.
The code looks correct for XML 1.0, however I didn't find the surrogates
validation code neither in qxml*, neither in QUtfCodec-s. I'll probably
write some additional tests once have a time for that.
You may want to raise a suggestion/feature request via
http://bugreports.qt-project.org/ about upgrading XML support in Qt up to
1.1
Regards,
Konstantin
2013/9/8 Kurt Pattyn pattyn.k...@gmail.com
All XML validation in Qt is based on XML 1.0 (and not the newer 1.1
standard).
I found at least 3 places where validity is checked:
*1. in qxmlstream.cpp:*
Method resolveCharRef:
//checks for validity
ok = (s == 0x9 || s == 0xa || s == 0xd || (s = 0x20 s = 0xd7ff)
|| (s = 0xe000 s = 0xfffd) || (s = 0x1 s =
QChar::LastValidCodePoint));
Method scanUntil:
//checks for invalidity
if (c 0x20 || (c 0xFFFD c 0x1) || c
QChar::LastValidCodePoint )
2. *In qxmlutils.cpp*:
bool QXmlUtils::isChar(const QChar c)
{
return (c.unicode() = 0x0020 c.unicode() = 0xD7FF)
|| c.unicode() == 0x0009
|| c.unicode() == 0x000A
|| c.unicode() == 0x000D
|| (c.unicode() = 0xE000 c.unicode() = 0xFFFD);
}
It is pretty much the same as the above checks, except that it doesn't
check for characters in the range 0x1 - 0x10.
It think this is a bug, especially because the source is referring to the
standard at http://www.w3.org/TR/REC-xml/#NT-Char, which says:
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] |
[#xE000-#xFFFD] | *[#x1-#x10]*/* any Unicode character,
excluding the surrogate blocks, FFFE, and . */
Now, I have three questions:
1. Can someone confirm if the check in QXmlUtils is actually a bug?
2. Wouldn't it be better to move these checks to QChar, so that at least
there is only one implementation?
3. Is there a reason to stick to XML1.0, or should Qt also implement the
XML1.1 standard?
According to the XML 1.1 standard (http://www.w3.org/TR/xml11/#charsets),
allowed characters are:
[2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] |
[#x1-#x10] /* any Unicode character, excluding the surrogate
blocks, FFFE, and . */
[2a] RestrictedChar ::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84]
| [#x86-#x9F]
So the allowed character range is a little bit extended (now includes all
characters between 0x0001 and 0x0020). In addition, XML1.1 has defined some
characters to be highly discouraged, but still valid.
___
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] [Question] Implementation of XML character validation
On 08 Sep 2013, at 20:01, development-requ...@qt-project.org wrote:
From: Konstantin Ritt ritt...@gmail.com
Subject: Re: [Development] [Question] Implementation of XML character
validation
Date: 8 Sep 2013 20:00:45 GMT+02:00
To: development@qt-project.org development@qt-project.org
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x1-#x10]/* any Unicode character, excluding the surrogate
blocks, FFFE, and . */
in XML 1.0 is quite the same as
[2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10]
/* any Unicode character, excluding the surrogate blocks, FFFE, and . */
[2a] RestrictedChar::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] |
[#x86-#x9F]
in XML 1.1, except of [U+007F..U+0084] and [U+0086..U+009F], which are
prohibited now.
Is it prohibited or just highly discouraged? Where in XML1.0, characters
below 0x0020 were simply not allowed (except for 0x0009, 0x000A and 0x000D), in
XML1.1 they are called highly discouraged (it seems the constraints have been
loosened a bit). How should highly discouraged be interpreted: should Qt
allow them, or mark them as prohibited?
The code looks correct for XML 1.0, however I didn't find the surrogates
validation code neither in qxml*, neither in QUtfCodec-s. I'll probably write
some additional tests once have a time for that.
Correct, I didn't even notice this.
And what about?
bool QXmlUtils::isChar(const QChar c)
{
return (c.unicode() = 0x0020 c.unicode() = 0xD7FF)
|| c.unicode() == 0x0009
|| c.unicode() == 0x000A
|| c.unicode() == 0x000D
|| (c.unicode() = 0xE000 c.unicode() = 0xFFFD);
}
Isn't this code missing the check
c = 0x1 c = QChar::LastValidCodePoint ?
You may want to raise a suggestion/feature request via
http://bugreports.qt-project.org/ about upgrading XML support in Qt up to 1.1
Regards,
Konstantin
Regards,
Kurt___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Question] Implementation of XML character validation
On domingo, 8 de setembro de 2013 20:36:39, Kurt Pattyn wrote:
bool QXmlUtils::isChar(const QChar c)
{
return (c.unicode() = 0x0020 c.unicode() = 0xD7FF)
|| c.unicode() == 0x0009
|| c.unicode() == 0x000A
|| c.unicode() == 0x000D
|| (c.unicode() = 0xE000 c.unicode() = 0xFFFD);
}
Isn't this code missing the check
c = 0x1 c = QChar::LastValidCodePoint ?
No.
It's limited by the size of QChar. It cannot contain 0x1.
No, the entire API is flawed. It should work on terms of UCS-4, not of QChar.
The code calling this API needs to do the surrogate decoding. This class may
be interesting for them:
https://codereview.qt-project.org/669
--
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] Fwd: Change in qt/qtbase[dev]: Enable -Werror for all of qtbase
Whilst I'm with Oliver and André in that part that affects the Qt user (and I can imagine users in panic filing latest dev build fails bugs right now), I agree with Thiago in that part that we could try fixing existing warnings on some configurations at very least. Throwing warnings is not a way for compiler to simply bother you, most often warnings are almost errors. I.e. if compiler says there is a possible issue, go and check it. Despite that fact we all don't like wasting our time, several potential issues were fixed already (i.e. 5dd2713c8ba98e06ae5c4f3da44b2ed73121d247 ); so let's give it a try for a short time, at least. However, I'd like to ask someone to blog about this experiment and show the user how to switch -Werror of at configure time. Kind regards, Konstantin 2013/9/5 Thiago Macieira thiago.macie...@intel.com On quinta-feira, 5 de setembro de 2013 09:41:11, Giuseppe D'Angelo wrote: On 5 September 2013 08:44, Thiago Macieira thiago.macie...@intel.com wrote: Can we please give the feature a try, for a week or two, with -warnings-are- errors enabled in all CI builds? I don't think this is the point. We already do have several -developer-build configurations active in CI, and, as you say, that's enough for enabling -Werror there. Eventually, the configurations without -developer-build could get -warnings-are-errors, but that's another story... That's part of what I am asking. The problem (*) is that the CI is not testing common configurations that developers use daily, for instance GCC 4.7/4.8 under Linux. If a patch of mine triggers warnings (= errors) under one of those compilers, but not for the other compilers used by CI (see [1]) it will get merged. And as soon as the other hundred developers pull the branches with that patch, they'll have a broken build, and they'll have to act to solve / work around the warning (instead of doing their job [2]). That's why I was proposing to limit the -Werror to those compilers which are actually in the CI, so those patches don't get merged in the first place and the *submitter* is forced to act to solve the warning: I disagree. That's why I am asking for two weeks of testing. I don't think -Werror are any worse than any other changes going on. Let me give you several examples: 1) developer A writes code on Ubuntu, for example the same version that we have on CI. It compiles, so it gets integrated. Developer B gets the code and is running brand-new Gentoo or Fedora Rawhide, with glibc 2.19-pre. Code fails to compile because glibc removed an indirect include. This has happened in the past, just with different version numbers. 2) developer A submits code that uses non-standard header names and bad include guards, and it passes CI integration. Developer B downloads the code and does some extra checks, causing the problems to show. Developer A = Lars Simon, the code was V4. 3) code exists in the Qt repositories and compiles on all compilers we've so far tested. A new compiler version is released, so we test and find that it fails to compile due to a stricter checking of some C++ feature. This has also happened in the past, like with aliasing violations. My points are: * The CI can *never* check everything. We rely on crowdsourcing by our own devs to catch those mistakes. * New compilers need to be validated anyway. * Upgrades of third-party libraries can cause build failures anyway. So I am asserting here that -Werror is no different from the cases above. The issues we're seeing now is that we've only had a limited time to fix the *existing* warnings. That's why I am asking for one or two weeks, so we find out how often this continues to happen, after the initial warnings get fixed. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 8b7a8efe6 broke the dev branch
On Sat, Sep 07, 2013 at 08:53:05AM -0700, Thiago Macieira wrote: On sábado, 7 de setembro de 2013 17:25:56, Mark wrote: While trying to update my Qt build i got this nasty unexpected error: http://paste.kde.org/p7c51188c/ Or rather, two other folks from #kde-devel had that. While i recompiled i was welcomed by the same error. Not a bug in Qt. Look at the error message you're getting: qjsonvalue.h:70:9: error: expected identifier before ‘int’ Bool = 0x1, ^ Why is it talking about int and pointing to Bool? Answer: you #included X11/xlib.h and forgot to clean it up. It has a #define Bool. While indeed not being a exactly a bug in Qt this breakage was, as others, predictable and could have been avoided by simply sticking to the rules laid out in Designing Qt-Style C++ APIs, section The Art of Naming, subsection Naming Enum Types and Values which states: When declaring enums, we must keep in mind that in C++ (unlike in Java or C#), the enum values are used without the type. and continues later One guideline for naming enum types is to repeat at least one element of the enum type name in each of the enum values Calling an enum value Bool should have been a no-go, even if in this case the reason was not 'clash-due-to-similar-enums' but 'clash- due-to-common-names-for-macros'. Andre' PS: The full version is at http://doc.qt.digia.com/qq/qq13-apis.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Question] Implementation of XML character validation
On 08 Sep 2013, at 20:43, Thiago Macieira thiago.macie...@intel.com wrote:
On domingo, 8 de setembro de 2013 20:36:39, Kurt Pattyn wrote:
bool QXmlUtils::isChar(const QChar c)
{
return (c.unicode() = 0x0020 c.unicode() = 0xD7FF)
|| c.unicode() == 0x0009
|| c.unicode() == 0x000A
|| c.unicode() == 0x000D
|| (c.unicode() = 0xE000 c.unicode() = 0xFFFD);
}
Isn't this code missing the check
c = 0x1 c = QChar::LastValidCodePoint ?
No.
It's limited by the size of QChar. It cannot contain 0x1.
No, the entire API is flawed. It should work on terms of UCS-4, not of QChar.
Couldn't it be a solution to expand QChar to contain 32-bit code points iso
16-bit, and have the unicode() function return an UCS4 value?
At least, I think it would be nice that the checks for valid XML characters
would be concentrated in one place.
The code calling this API needs to do the surrogate decoding. This class may
be interesting for them:
https://codereview.qt-project.org/669
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Question] Implementation of XML character validation
On 08 Sep 2013, at 20:43, Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 8 de setembro de 2013 20:36:39, Kurt Pattyn wrote: It's limited by the size of QChar. It cannot contain 0x1. Isn't it supposed that a QChar contains a Unicode character (which is 32-bit in size)? Regards, Kurt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Question] Implementation of XML character validation
2013/9/8 Kurt Pattyn pattyn.k...@gmail.com Couldn't it be a solution to expand QChar to contain 32-bit code points iso 16-bit, and have the unicode() function return an UCS4 value? At least, I think it would be nice that the checks for valid XML characters would be concentrated in one place. No. QString operates on UCS-2, not UCS-4. The code calling this API needs to do the surrogate decoding. This class may be interesting for them: https://codereview.qt-project.org/669 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Kurt ___ 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] [Question] Implementation of XML character validation
Plz read the docs. Regards, Konstantin 2013/9/8 Kurt Pattyn pattyn.k...@gmail.com On 08 Sep 2013, at 20:43, Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 8 de setembro de 2013 20:36:39, Kurt Pattyn wrote: It's limited by the size of QChar. It cannot contain 0x1. Isn't it supposed that a QChar contains a Unicode character (which is 32-bit in size)? Regards, Kurt ___ 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] [Question] Implementation of XML character validation
On 8 September 2013 22:42, Kurt Pattyn pattyn.k...@gmail.com wrote: Isn't it supposed that a QChar contains a Unicode character (which is 32-bit in size)? No, a QChar is exactly an UTF-16 code unit. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Question] Implementation of XML character validation
Hi Konstantin, that is exactly what I did. From the Qt5 documentation: The QChar class provides a 16-bit Unicode character. In Qt, Unicode characters are 16-bit entities without any markup or structure. This class represents such an entity. It is lightweight, so it can be used everywhere. Most compilers treat it like a unsigned short. There is no mention of UTF-16. Furthermore, I would expect to method unicode(), to return the UCS-4 representation: ushort QChar::unicode() const Returns the numeric Unicode value of the QChar. But, it doesn't return the unicode v6.2 value, as that can be 32-bit; I know. It gives me the impression that QChar is based on an old Unicode standard. Furthermore (again from the documentation): Qt 5.0 uses and fully supports version 6.2 of the Unicode standard. At least, I think this is confusing. So, either the documentation of QChar should at least indicate that it is encoded in UTF-16, which I doubt (because then QChar should have place for 2 16-bit values), or QChar should be adapted to conform to the statement that Qt5.0 is Unicode 6.2 compliant, or it should be indicated that QChar conforms to an older standard. So, I was just wondering how QChar fits within the Unicode 6.2 standard? Reading the docs doesn't clarify much. Kurt On 08 Sep 2013, at 22:43, Konstantin Ritt ritt...@gmail.com wrote: Plz read the docs. Regards, Konstantin 2013/9/8 Kurt Pattyn pattyn.k...@gmail.com On 08 Sep 2013, at 20:43, Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 8 de setembro de 2013 20:36:39, Kurt Pattyn wrote: It's limited by the size of QChar. It cannot contain 0x1. Isn't it supposed that a QChar contains a Unicode character (which is 32-bit in size)? Regards, Kurt ___ 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] [Question] Implementation of XML character validation
On domingo, 8 de setembro de 2013 22:39:07, Kurt Pattyn wrote: Couldn't it be a solution to expand QChar to contain 32-bit code points iso 16-bit, and have the unicode() function return an UCS4 value? Maybe in Qt 7. (No, this is not a typo) -- 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] [Question] Implementation of XML character validation
Neither of these relates to some specific Unicode version. QChar is a 16-bit Unicode character part. QString is UCS-2-encoded. Read about UTF-16 for more info. Also !qdoc: QChar::highSurrogate(), QChar::lowSurrogate() Regards, Konstantin 2013/9/9 Kurt Pattyn pattyn.k...@gmail.com Hi Konstantin, that is exactly what I did. From the Qt5 documentation: The QChar class provides a 16-bit Unicode character. In Qt, Unicode characters are 16-bit entities without any markup or structure. This class represents such an entity. It is lightweight, so it can be used everywhere. Most compilers treat it like a unsigned short. There is no mention of UTF-16. Furthermore, I would expect to method unicode(), to return the UCS-4 representation: ushorthttp://qt-project.org/doc/qt-5.0/qtcore/qtglobal.html#ushort-typedef QChar::unicode() const Returns the numeric Unicode value of the QCharhttp://qt-project.org/doc/qt-5.0/qtcore/qchar.html . But, it doesn't return the unicode v6.2 value, as that can be 32-bit; I know. It gives me the impression that QChar is based on an old Unicode standard. Furthermore (again from the documentation): Qt 5.0 uses and fully supports version 6.2 of the Unicode standard. At least, I think this is confusing. So, either the documentation of QChar should at least indicate that it is encoded in UTF-16, which I doubt (because then QChar should have place for 2 16-bit values), or QChar should be adapted to conform to the statement that Qt5.0 is Unicode 6.2 compliant, or it should be indicated that QChar conforms to an older standard. So, I was just wondering how QChar fits within the Unicode 6.2 standard? Reading the docs doesn't clarify much. Kurt On 08 Sep 2013, at 22:43, Konstantin Ritt ritt...@gmail.com wrote: Plz read the docs. Regards, Konstantin 2013/9/8 Kurt Pattyn pattyn.k...@gmail.com On 08 Sep 2013, at 20:43, Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 8 de setembro de 2013 20:36:39, Kurt Pattyn wrote: It's limited by the size of QChar. It cannot contain 0x1. Isn't it supposed that a QChar contains a Unicode character (which is 32-bit in size)? Regards, Kurt ___ 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] [Question] Implementation of XML character validation
On domingo, 8 de setembro de 2013 23:05:49, Kurt Pattyn wrote: So, either the documentation of QChar should at least indicate that it is encoded in UTF-16, which I doubt (because then QChar should have place for 2 16-bit values), or QChar should be adapted to conform to the statement that Qt5.0 is Unicode 6.2 compliant, or it should be indicated that QChar conforms to an older standard. So, I was just wondering how QChar fits within the Unicode 6.2 standard? Reading the docs doesn't clarify much. It does very well, QChar contains one 16-bit unit, it does not actually enforce UTF-16. QString is UTF-16. That's where it matters. -- 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] Cherry picking to replace a change set
On 31 août 2013, at 23:37, Thiago Macieira wrote: On sábado, 31 de agosto de 2013 21:24:21, Samuel Gaist wrote: Just to be sure (for a future work),for example https://codereview.qt-project.org/#change,63526 and https://codereview.qt-project.org/#change,63699 that try to fix Bug-1180. The bug applies to both 4 and 5. But in Qt5 the same fix also uncovered another problem that I tried to address within the same patch set. So the correct work flow would have been to first fix all the problems in Qt 5, cherry pick and only apply and submit the needed changes to Qt 4 ? The correct work flow would have been to have one commit that does one thing only. Then you could have cherry-picked it in its entirety. Just thought about something: Is it possible to have some sort dependency between two commits in jira ? My example shows exactly the problem of one fix common to Qt 4 and 5 that reveals another bug (in Qt 5 but not 4) that must be solved first in order to have a clean solution. So currently (from my limited knowledge), I see three possibilities: - Both fix in the same patch (not atomic but everything is fixed in one go) - Send the second fix, wait for it to be integrated and then submit the first one (atomic but not necessarily efficient) - Send both separated and self -1 the commit that needs to wait for integration and add a comment stating the needs for the other to test/validate the solution (again atomic but not necessarily efficient, on the plus side people wanting to do tests have all the changes needed) Option 2 and 3 allow for a clean cherry pick to Qt 4 but might slow down the integration of the complete fix in Qt 5 so... What would be the best workflow in this case ? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Question] Implementation of XML character validation
Hi, please, let's keep the discussion on the ML. On 8 September 2013 23:10, Kurt Pattyn pattyn.k...@gmail.com wrote: Hi Giuseppe, this is not mentioned in the documentation, and, if QChar is following the Unicode v6.2 standard, cannot be correct, as the method unicode() returns a 16-bit value, which even in UTF-16 is too short (UTF-16 encoding can have 2 16-bit values to represent a unicode character). Yes, unicode() returns the UTF-16 code unit held inside the QChar (which is just a 16 bit number...). If you want to UTF-16 encode code points above 0x, you need surrogate pairs, i.e. pairs of QChars. QChar itself offers methods such as isHighSurrogate/isLowSurrogate, and various statics (surrogateToUcs4(QChar, QChar), isSurrogate(uint), lowSurrogate(uint), etc.) HTH, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Question] Implementation of XML character validation
On domingo, 8 de setembro de 2013 23:42:57, Konstantin Ritt wrote: No. QString operates on UCS-2, not UCS-4. QString operates on UTF-16, not UCS-2. -- 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] Cherry picking to replace a change set
On 8 sept. 2013, at 23:21, Thiago Macieira wrote: On domingo, 8 de setembro de 2013 23:15:41, Samuel Gaist wrote: Just thought about something: Is it possible to have some sort dependency between two commits in jira ? My example shows exactly the problem of one fix common to Qt 4 and 5 that reveals another bug (in Qt 5 but not 4) that must be solved first in order to have a clean solution. Use the Link feature and set depends on So I should add a sub task to the current bug report and make the current bug depends on the new sub task ? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry picking to replace a change set
On domingo, 8 de setembro de 2013 23:36:21, Samuel Gaist wrote: Use the Link feature and set depends on So I should add a sub task to the current bug report and make the current bug depends on the new sub task ? If you create a sub-task, it's implied that it depends on the subtask being completed first. -- 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] Cherry picking to replace a change set
On 9 September 2013 05:21, Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 8 de setembro de 2013 23:15:41, Samuel Gaist wrote: Just thought about something: Is it possible to have some sort dependency between two commits in jira ? My example shows exactly the problem of one fix common to Qt 4 and 5 that reveals another bug (in Qt 5 but not 4) that must be solved first in order to have a clean solution. Use the Link feature and set depends on I couldn't find the Link feature. Is it disabled for regular users? If so, it would be useful to enable it for a user's own reports, like the Close button. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] WebView for Android on track for Qt 5.2?
Hi, So far there hasn't been much research on this, but the idea was to render it into a texture and use this in the QML scene graph, yes. Any experience you collect on this will probably be very helpful. I think the path forward may be to make an Android-specific API for this that can easily be adapted to a cross-platform API later. That gives us a bit more flexibility as we do not have to commit to a cross-platform API right away. I can't give any promises as for the Qt version this will be targeted at yet, but I do understand that it's a very important feature, so I definitely want to have it as soon as at all possible. Here's a blog which might be helpful if you're going to be looking at this: http://anuraagsridhar.wordpress.com/2013/03/13/rendering-an-android-webview-or-for-that-matter-any-android-view-directly-to-opengl/ -- Eskil -Opprinnelig melding- Fra: Cornelius Hald [mailto:h...@icandy.de] Sendt: 6. september 2013 16:15 Til: Abrahamsen-Blomfeldt Eskil Kopi: development@qt-project.org Emne: Re: [Development] WebView for Android on track for Qt 5.2? On Fri, 2013-09-06 at 10:41 +0200, Eskil Abrahamsen Blomfeldt wrote: On 09/05/2013 06:18 PM, Cornelius Hald wrote: Hi guys, what is the state of WebView (QQ2) for Android? Is it still planed for Qt 5.2? Is there a branch to track somewhere? The bug report suggests that instead of using QtWebKit a wrapper around the Android-WebView is now planned. https://bugreports.qt-project.org/browse/QTBUG-32093 Anything I could help you with? Hi, I've talked to the team working on the web engine in Qt in Digia, and right now there are no resources to do work on this in Digia unfortunately. It might be possible to do something specifically for Android, but it would be a lot nicer to have a cross-platform solution like the web engine guys initially planned, and I think this is needed for iOS as well. I'll talk to the iOS team here, but I don't think it sounds feasible that this will be done in the one and a half weeks we have left before the Qt 5.2 feature freeze. Sorry :( -- Eskil Hi Eskil, thank you for your fast reply. Of course that wasn't the answer I was hoping for but at least I can be sure now. I have two projects running on Windows and Linux. Both I should port to Android as soon as possible. Are there any known workarounds? Like using the Android WebView and rendering it into a GL texture that could be used with QQ2? I only need output. No input or interaction. I will research my options but would be very grateful for any hints and tips. Also it would be great to know for what Qt version it is planned to have a working WebView on Android. Thanks! Conny ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
