Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD?
A property im table is more thsn a just Qt property, that macro create
property and static field for query writing and class info about property
to add to database.
And what's the reason to have a constructor as Q_INVOKABLE?
Andre right abou
moin,
we finally managed to add a cherry-pick validator to the sanity bot, so
i dared to open the 5.6 branch for staging again.
caveat: patchsets created before the final forward merge got a positive
review while they aren't cherry-picks. i don't suppose anyone would
stage such an old patchset as
On sexta-feira, 3 de fevereiro de 2017 13:48:46 PST Kevin Kofler wrote:
> The overhead compared to using QString will be reduced, but only part of it
> (the avoided memory allocation) is really an optimization. The rest of the
> "reduced" overhead is because QString will get the same overhead bloat
On sexta-feira, 3 de fevereiro de 2017 12:59:19 PST Marc Mutz wrote:
> QStringLiteral is not what most people use. It's too verbose. They use
> "&OK", cf. our tests and, to a lesser extend, because we encourage tr()
> there, examples and docs.
>
> u"&OK", however, has almost no readbility overhead
Op 03/02/2017 om 14:27 schreef Giuseppe D'Angelo:
Il 03/02/2017 13:48, Kevin Kofler ha scritto:
We really need a plan to deprecate implicit casts between QString and ASCII.
They are not only the source of such inefficiencies from inexperienced or
lazy programmers, but also of encoding-related
Il 03/02/2017 13:48, Kevin Kofler ha scritto:
> We really need a plan to deprecate implicit casts between QString and ASCII.
> They are not only the source of such inefficiencies from inexperienced or
> lazy programmers, but also of encoding-related bugs. If you need to convert
> between 8-bit e
Marc Mutz wrote:
> QStringLiteral is not what most people use. It's too verbose.
#define U(x) QStringLiteral(x)
or some other 1-letter macro or even $ (which most compilers will let you
get away with).
> They use "&OK",
We really need a plan to deprecate implicit casts between QString and ASCII
On Friday 03 February 2017 09:29:22 Thiago Macieira wrote:
> On sexta-feira, 3 de fevereiro de 2017 08:49:24 PST Marc Mutz wrote:
> > When the QString overload is replaced by a QStringView one, these calls
> > become errors. I don't mean to say that's a good thing going forward into
> > Qt 6, but I
Marc Mutz wrote:
> setLabelQStringCRef("&OK");
That is an unfair comparison. The QString code should use QStringLiteral. Of
course converting from 8-bit to 16-bit is horribly inefficient compared to
just using a 16-bit literal.
Kevin Kofler
_
On Freitag, 3. Februar 2017 10:59:21 CET Kevin Kofler wrote:
> Marc Mutz wrote:
> > The question of whether to replace QString sink arguments with QStringView
> > ones is an open one. It does not affect the usefulness of QStringView as a
> > way to pass UTF-16 data from a wide variety of sources th
03.02.2017, 01:07, "Milian Wolff" :
> On Donnerstag, 2. Februar 2017 20:38:00 CET Hamed Masafi wrote:
>> Project Name: Nut (currently renamed to ORM)
>>
>> Description: ORM is a project aimed to help users working with databases.
>> Developer will write his/her own classes and ORM will generat
Marc Mutz wrote:
> The question of whether to replace QString sink arguments with QStringView
> ones is an open one. It does not affect the usefulness of QStringView as a
> way to pass UTF-16 data from a wide variety of sources through a single
> function.
>
> I'd invite you to look at the QColor
Op 03/02/2017 om 10:18 schreef Jesus Fernandez:
On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote:
Declaring persistant objects in ORM is straightforward:
class Comment : public Table
{
Q_OBJECT
NUT_PRIMARY_AUTO_INCREMENT(id)
NUT_DECLARE_FIELD
On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote:
> Declaring persistant objects in ORM is straightforward:
>
> class Comment : public Table
> {
> Q_OBJECT
>
> NUT_PRIMARY_AUTO_INCREMENT(id)
> NUT_DECLARE_FIELD(int, id, id, setId)
> NUT_DECLARE
[below: Till's reply and request to forward our discussion to this
mailing list]
Forwarded Message
Subject: Re: Google Summer of Code 2017 - Common Print Dialog project
Date: Thu, 2 Feb 2017 21:56:47 -0200
From: Till Kamppeter
To: Michael Weghorn
CC: Aveek Basu , John Layt ,
B
[below: my answer to Till's initial email regarding the Common Print Dialog]
Forwarded Message
Subject: Re: Google Summer of Code 2017 - Common Print Dialog project
Date: Thu, 2 Feb 2017 00:04:03 +0100
From: Michael Weghorn
To: Till Kamppeter
CC: [...]
Hi Till,
thank you ver
Hi,
when reading about our thoughts on implementing printer-specific options
for the Qt print dialog, Till Kamppeter contacted me, mentioning the
project of a Common Print Dialog at OpenPrinting.
I am forwarding our discussion to this mailing list. I will send the
other two emails separately to m
On sexta-feira, 3 de fevereiro de 2017 08:49:24 PST Marc Mutz wrote:
> When the QString overload is replaced by a QStringView one, these calls
> become errors. I don't mean to say that's a good thing going forward into
> Qt 6, but I do say that having this option (and nothing more is being
> discus
18 matches
Mail list logo
