Hello!
I don't know how this may work, but I think you should be careful with
commas inside Q_INFO. If Q_INFO may be a simple "empty" macro, then
preprocessor may require 2 arguments for Q_INFO macro in Q_INFO("foo",
"bar") and Q_INFO(myTag ("foo", "bar")).
01.09.2013 15:20, Stefan Merettig п
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 b
On 9 September 2013 05: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
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 su
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 a
Hi,
please, let's keep the discussion on the ML.
On 8 September 2013 23:10, Kurt Pattyn 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
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
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 m
On 08 Sep 2013, at 22:42, Konstantin Ritt wrote:
> 2013/9/8 Kurt Pattyn
>> 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 ch
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.
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 Q
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
> Hi Konstantin,
>
> that is exactl
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
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
On 8 September 2013 22:42, Kurt Pattyn 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-proj
Plz read the docs.
Regards,
Konstantin
2013/9/8 Kurt Pattyn
> On 08 Sep 2013, at 20:43, Thiago Macieira
> 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 cont
2013/9/8 Kurt Pattyn
> 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
On 08 Sep 2013, at 20:43, Thiago Macieira 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
__
On 08 Sep 2013, at 20:43, Thiago Macieira 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
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
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
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
>||
On 08 Sep 2013, at 20:01, development-requ...@qt-project.org wrote:
> From: Konstantin Ritt
> Subject: Re: [Development] [Question] Implementation of XML character
> validation
> Date: 8 Sep 2013 20:00:45 GMT+02:00
> To: "development@qt-project.org"
>
>
> [2] Char ::= #x9 | #xA |
[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,
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)
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 mak
26 matches
Mail list logo
