Lars Knoll (29 September 2020 20:48)
> I hope that Eddy can create an updated header diff for the modules
> that are part of 6.0 to make reviewing easier.
Done.
Only qtbase, qtdeclarative, qttools, qtwayland and qt3d have changes
relative to the previous patch set, though.
The code to treat s/Q_R
Hi everybody,
We are now almost ready to release the Alpha for Qt 6. The plan is to follow up
with a first beta as quickly as we can manage, and then have frequent beta
releases until things have stabilised enough.
Apart from fixing bugs, the most important item now is to finalise and review
o
On Wednesday, 24 January 2018 10:49:32 PST Thiago Macieira wrote:
> I've added a CBOR dump tool example, which can help you with understanding
> what you have:
One more difference: since "convert" uses QCborValue, it will normalise a few
items:
$ ./convert/convert /tmp/test3.cbor
[
3
On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote:
> I'm also interested in what I could write as an example. Please send
> suggestions.
I've added a CBOR dump tool example, which can help you with understanding
what you have:
$ convert/convert -o line-wrap=no /tmp/test3.cbor
{ "
On segunda-feira, 22 de janeiro de 2018 16:56:56 PST Thiago Macieira wrote:
> After fixing the converter example to properly use mmap in all three cases,
> plus refactoring the CBOR parser to operate on a pre-loaded array and use
> larger buffer than single-digit byte counts, the numbers are:
A ma
On segunda-feira, 22 de janeiro de 2018 01:37:40 PST Thiago Macieira wrote:
> Binary JSON validating:
> 97,003559 task-clock:u (msec)
>237.092.857 cycles
>437.005.872 instructions
> [15.2% was spent in QIODevice::readAll, 59.1% in fromBinaryData]
>
> JSON pa
On segunda-feira, 22 de janeiro de 2018 01:37:40 PST Thiago Macieira wrote:
> CBOR parsing:
> 341,311535 task-clock
>885.053.081 cycles
> 2.548.803.851 instructions
>
> The string parser is still showing up at 70.5% of the full execution time,
> of which 33.4% a
On quarta-feira, 17 de janeiro de 2018 13:25:53 PST Thiago Macieira wrote:
> My current idea is a command-line tool that converts between serialisation
> formats:
> * CBOR
> * CBOR diagnostic notation (output only, since I won't write the parser)
> * JSON
> * XML
> * Qt binary JSON
> * Plain
On Thursday, 18 January 2018 00:51:18 PST Dominik Holland wrote:
> Am 01/18/2018 um 04:22 AM schrieb Thiago Macieira:
> > On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote:
> >> Another idea is to update the network-chat example to use CBOR instead of
> >> its plaintext protocol. In
Am 01/18/2018 um 04:22 AM schrieb Thiago Macieira:
> On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote:
>> Another idea is to update the network-chat example to use CBOR instead of
>> its plaintext protocol. In this one, I could use the stream reader and
>> writer. This example is a
On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote:
> Another idea is to update the network-chat example to use CBOR instead of
> its plaintext protocol. In this one, I could use the stream reader and
> writer. This example is a perfect candidate to have a CoAP version in the
> future
Hello
I finished writing the documentation for the two basic classes for CBOR. You
can find them in reviews
https://codereview.qt-project.org/107465
https://codereview.qt-project.org/107466
Please review. I will take a couple more days writing the docs for
QCbor{Value,Map,Array} and then I'll u
On Monday 18 January 2016 15:48:54 Andreas Hartmetz wrote:
> Everything I have written about API applies to documentation as well. It
> seems like whatever the implementor writes is accepted and that is that.
> AFAIU that was not exactly how it used to be done at Trolltech when it
> was still ca
On Mon, Jan 18, 2016 at 05:41:38PM +0100, Oswald Buddenhagen wrote:
> On Mon, Jan 18, 2016 at 03:48:54PM +0100, Andreas Hartmetz wrote:
> > Gerrit is somehow much more detail-oriented, and criticizing "too
> > subjective" stuff is frowned upon.
> >
> anyone who complains about such aspects of a re
On Montag, 18. Januar 2016 17:41:38 CET Oswald Buddenhagen wrote:
> On Mon, Jan 18, 2016 at 03:48:54PM +0100, Andreas Hartmetz wrote:
> > Gerrit is somehow much more detail-oriented, and criticizing "too
> > subjective" stuff is frowned upon.
>
> anyone who complains about such aspects of a review
On Mon, Jan 18, 2016 at 03:48:54PM +0100, Andreas Hartmetz wrote:
> Gerrit is somehow much more detail-oriented, and criticizing "too
> subjective" stuff is frowned upon.
>
anyone who complains about such aspects of a review clearly didn't quite
get https://wiki.qt.io/Qt_Contribution_Guidelines -
I don't really understand the question you're asking. :D
> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> Andreas Hartmetz
> Sent: Monday, 18 January 2016 3:49 PM
> To: qt-dev
> Subject: [Development] API rev
Hello,
Due to a recent problem I had with an API addition (solved while writing
the E-Mail about it, the rubber duck technique worked!) I noticed, not
for the first time, something missing...
the Trolltech API review process.
The thing that ensured that (almost) all new API made sense to humans
There's a fair amount of legacy code using other methods for implementing
the private class pointer. Q_Q and Q_D macros are preferred though.
You don't need to merge your .cpp files, we generally have one .cpp per
class (though trivial classes don't always have their own file).
The point is that t
Ok, tabs has been converted into 4 spaces.
Regarding the *_p.cpp files: I just did this to keep the file sizes at a
reasonable size; if it is a style requirement, I can merge those files.
The same holds for the other files (DataProcessor, …). If I merge them with
QWebSocket.cpp, then that file w
On Sun, Aug 25, 2013 at 3:49 PM, Kurt Pattyn wrote:
> Hi,
>
> I am about to move the QWebSockets project (see:
> http://github.com/KurtPattyn/QWebSockets) to the playground.
> Could you please review the API?
>
>
Just some quick stylistic observations:
* you don't usually make a class_p.cpp (imp
Hi,
I am about to move the QWebSockets project (see:
http://github.com/KurtPattyn/QWebSockets) to the playground.
Could you please review the API?
Notes:
The public API is QWebSocket and QWebSocketServer; all other classes are
internal.
The APIs of both classes were modelled after QAbstractSock
Whatever works, the task is just to avoid forgetting about it.
On 26 June 2013 19:41, Alan Alpert <4163654...@gmail.com> wrote:
> On Wed, Jun 26, 2013 at 6:27 AM, Rutledge Shawn
> wrote:
> > I just wrote up this task
> >
> > https://bugreports.qt-project.org/browse/QTBUG-32039
> >
> > because w
https://codereview.qt-project.org/24905
Although we created an enum for pause modes to make 5.x binary
compatible with 5.0, the enum value is not well named.
In 5.1, we propose to add PauseOnProxyAuthentication to the enum.
PauseOnNotify is not clear what it means, while PauseOnSslErrors is.
Any
Hi Morten,
On Tue, Jan 17, 2012 at 2:42 PM, wrote:
> QWheelEvent has fallen a bit behind and needs an update. It was once used for
> mouse wheel events only, but is today also used for scroll events generated
> from trackpad swipe gestures.
>
> There are two main issues:
>
> * QWheelEvents are
QWheelEvent has fallen a bit behind and needs an update. It was once used for
mouse wheel events only, but is today also used for scroll events generated
from trackpad swipe gestures.
There are two main issues:
* QWheelEvents are either horizontal or vertical, requiring two events and two
cal
On 01/06/2012 06:46 PM, ext Jeremy Lainé wrote:
>> - finalise the class name (I think QDns was suggested)
>>
>
> Could we get this point settled once and for all? My suggestions:
>
> - QDnsLookup (my preferred one, as the object represents a lookup and its
> result)
I like the name too...
> - QD
On 07/01/2012, at 4:46 AM, Jeremy Lainé wrote:
>> - finalise the class name (I think QDns was suggested)
>>
>
> Could we get this point settled once and for all? My suggestions:
>
> - QDnsLookup (my preferred one, as the object represents a lookup and its
> result)
+1 Says exactly what the
On Friday, 6 de January de 2012 18.46.16, Jeremy =?ISO-8859-1?Q?Lainé?wrote:
> > - finalise the class name (I think QDns was suggested)
>
> Could we get this point settled once and for all? My suggestions:
>
> - QDnsLookup (my preferred one, as the object represents a lookup and its
> result)
Go f
> - finalise the class name (I think QDns was suggested)
>
Could we get this point settled once and for all? My suggestions:
- QDnsLookup (my preferred one, as the object represents a lookup and its
result)
- QDnsInfo (similar to QHostInfo)
- QDns
Jeremy
___
Hi,
On 05/01/2012, at 1:11 AM, ext Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 12.07.37, craig.sc...@csiro.au wrote:
>> On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
>>> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
This could be perceived as cre
On 01/05/2012 01:03 AM, craig.sc...@csiro.au wrote:
>> Some notes about the implementation:
>>
>> - the actual lookup code is run in a thread, managed by a global threadpool
>> (QHostInfo-style)
> What happens if the client/user is also employing their own thread pool? Does
> your implementation
On 01/05/2012 01:47 AM, Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
>> This could be perceived as creating a race condition. You'd have to connect
>> a slot to the signal on the object returned, but what if the signal is
>> emitted before you get
On Thursday, 5 de January de 2012 12.51.50, craig.sc...@csiro.au wrote:
> Ah, the reply object emits the signal in the same thread as the caller? I
> was assuming the signal is emitted from within the thread that is
> processing the reply. Yes, in that case connecting before returning to the
> even
On 05/01/2012, at 12:11 PM, Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 12.07.37, craig.sc...@csiro.au wrote:
>> On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
>>> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
This could be perceived as creating a
On Thursday, 5 de January de 2012 12.07.37, craig.sc...@csiro.au wrote:
> On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
> > On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
> >> This could be perceived as creating a race condition. You'd have to
> >> connect
> >> a slot
On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
>> This could be perceived as creating a race condition. You'd have to connect
>> a slot to the signal on the object returned, but what if the signal is
>> emitted before y
On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
> This could be perceived as creating a race condition. You'd have to connect
> a slot to the signal on the object returned, but what if the signal is
> emitted before you get a chance to do that?
It cannot happen if you make
On 05/01/2012, at 3:51 AM, Jeremy Lainé wrote:
> Replying to myself to try and get the discussion going again.
>
> A summary of API decisions so far:
>
> - we only provide an asynchronous API
>
> - we do not want a "manager" object (QNAM-style) to avoid users creating a
> manager per lookup
>
Replying to myself to try and get the discussion going again.
A summary of API decisions so far:
- we only provide an asynchronous API
- we do not want a "manager" object (QNAM-style) to avoid users creating a
manager per lookup
- we want a single class to support different types of DNS reques
Hi,
We are about to introduce a new function and an enum in QMetaType class:
class QMetatype {
...
enum TypeFlag {
NeedsConstruction = 0x1,
NeedsDestruction = 0x2,
MovableType = 0x4
};
Q_DECLARE_FLAGS(TypeFlags, TypeFlag)
...
static TypeFlags type
On Thursday, 10 de November de 2011 07.54.55, Jeremy Lainé wrote:
> What I mean is that the Q3Dns has setters as well as a constructor with
> arguments, so for instance:
>
> Q3Dns *dns = new Q3Dns;
> dns->setLabel("foodomain.org");// will a request be triggered if I stop here
> and don't specify th
On Wednesday, 9 de November de 2011 19.21.14, Peter Hartmann wrote:
> We probably can mitigate the complexity introduced by QSharedPointer by
> having a simple example in the documentation.
Note: add QSharedPointer and QWeakPointer overloads to QObject::connect.
--
Thiago Macieira - thiago (AT)
On 11/09/2011 07:41 PM, Giuseppe D'Angelo wrote:
> On 9 November 2011 18:35, Jeremy Lainé wrote:
>> C/ you make QDnsReply's constructor public, and let the user manage the
>> lifetime of the
>> object. This is what the Q3Dns API looks like. What I don't like about
>> Q3Dns's API is that
>> it's
Op 9-11-2011 19:35, Jeremy Lainé schreef:
> On 11/09/2011 07:21 PM, Peter Hartmann wrote:
>> On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
>>> (...)
>>> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>>>
>>> pro: easy to connect to the QDnsReply's signal
>>> con: it's entirely
On 9 November 2011 18:35, Jeremy Lainé wrote:
> C/ you make QDnsReply's constructor public, and let the user manage the
> lifetime of the
> object. This is what the Q3Dns API looks like. What I don't like about
> Q3Dns's API is that
> it's unclear when the request is actually made.
It starts af
On 11/09/2011 07:21 PM, Peter Hartmann wrote:
> On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
>> (...)
>> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>>
>> pro: easy to connect to the QDnsReply's signal
>> con: it's entirely up to the user to handle deletion. Judging by your
On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
> (...)
> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>
> pro: easy to connect to the QDnsReply's signal
> con: it's entirely up to the user to handle deletion. Judging by your
> comments above, I
> doubt you favor it?
>
> or
>
On Wednesday 09 November 2011 18:05:52 Jeremy Lainé wrote:
> This talk about QtConcurrent has me wondering: do we need an asynchronous
> API at all?
>
> The underlying system calls are blocking anyway, and we could maybe have a
> very simple API like:
>
> QDnsInfo QDnsInfo::lookup(QDnsInfo::Recor
On 11/09/2011 06:21 PM, Robin Burchell wrote:
> On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé wrote:
>> This talk about QtConcurrent has me wondering: do we need an asynchronous
>> API at all?
> I really dislike synchronous APIs, even more so when they're the only
> option. Reason being that most
On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé wrote:
> This talk about QtConcurrent has me wondering: do we need an asynchronous API
> at all?
I really dislike synchronous APIs, even more so when they're the only
option. Reason being that most 'normal' people won't make the effort
to get it right
This talk about QtConcurrent has me wondering: do we need an asynchronous API
at all?
The underlying system calls are blocking anyway, and we could maybe have a very
simple API like:
QDnsInfo QDnsInfo::lookup(QDnsInfo::RecordType type, const QString &domain)
And if you want asynchronous calls
On Nov 4, 2011, at 9:37 PM, ext Thiago Macieira wrote:
> On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
>> Me too. My point was, that we have slightly different patters for
>> basically the same sort of thing in different places in Qt. QFuture is
>> currently coupled with QtConcu
On Wed, Nov 9, 2011 at 11:26 AM, Jeremy Lainé wrote:
>
> Le Nov 9, 2011 à 10:14 AM, André Somers a écrit :
>
>
>
> On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
>
>> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
>> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
>> >> - t
Le Nov 9, 2011 à 10:14 AM, André Somers a écrit :
>
>
> On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> > Correct, but all function
On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> > Correct, but all functions in QDnsResolver are static.
> >
> > That means they could
On Wednesday, 9 de November de 2011 09:17:59 Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> >
> > Correct, but all functions in QDnsResolver are static.
> >
> > That m
On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
>> - the QNAM-style API seems to be OK
> Correct, but all functions in QDnsResolver are static.
>
> That means they could go into QDnsReply and we could rename the class simply
> QDns. It
On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> - the QNAM-style API seems to be OK
Correct, but all functions in QDnsResolver are static.
That means they could go into QDnsReply and we could rename the class simply
QDns. It worked for Qt 3...
> - I have implemented QDnsReply::a
On 11/04/2011 09:37 PM, Thiago Macieira wrote:
> On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
>> Me too. My point was, that we have slightly different patters for
>> basically the same sort of thing in different places in Qt. QFuture is
>> currently coupled with QtConcurrent, but i
On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
> Me too. My point was, that we have slightly different patters for
> basically the same sort of thing in different places in Qt. QFuture is
> currently coupled with QtConcurrent, but is there a strong reason why
> is must be? I was not
On 11/04/2011 09:01 PM, Andre Somers wrote:
> Op 4-11-2011 20:31, Jeremy Lainé schreef:
>> On 11/04/2011 10:15 AM, André Somers wrote:
>>> The more I think about it, the more I think it is important to fix this:
>>> who is
>>> responsible for the lifetime of the QDnsReply object?
>>>
>> Why not ha
Op 4-11-2011 20:31, Jeremy Lainé schreef:
> On 11/04/2011 10:15 AM, André Somers wrote:
>> The more I think about it, the more I think it is important to fix this: who
>> is
>> responsible for the lifetime of the QDnsReply object?
>>
> Why not have the same pattern as QNAM for consistency?
How abo
On 11/04/2011 11:47 AM, Peter Hartmann wrote:
> Btw. I think we need the generic accessor anyway because you never know
> what the format of a TXT response looks like. Q3Dns allowed that only
> for TXT records, but IMO it would be better to always have an accessor
> to the raw response data, or at
On 11/04/2011 10:15 AM, André Somers wrote:
>
> The more I think about it, the more I think it is important to fix this: who
> is
> responsible for the lifetime of the QDnsReply object?
>
Why not have the same pattern as QNAM for consistency?
> This API does not make that clear. I like the patt
On Friday, 4 de November de 2011 17:14:35 Stephen Kelly wrote:
> On Tuesday, October 25, 2011 11:59:54 Thiago Macieira wrote:
> > QStringList allQueryItemValues(const QString &key,
> >
> > QUrl::ComponentFormattingOptions encoding = QUrl::PrettyDecoded) const;
>
> Does this return all values fo
On Tuesday, October 25, 2011 11:59:54 Thiago Macieira wrote:
> QStringList allQueryItemValues(const QString &key,
> QUrl::ComponentFormattingOptions encoding = QUrl::PrettyDecoded) const;
Does this return all values for the key? If the query string is a=4&a=5&a=6,
then
queryObject.allQuery
Le Nov 4, 2011 à 11:05 AM, Thiago Macieira a écrit :
> On Friday, 4 de November de 2011 10:36:29 Peter Hartmann wrote:
>> I am happy with having one QDnsReply class; I think we can get pretty
>> far with some special accessors for SRV and other records, and one
>> generic accessor for simple (Q
On 11/04/2011 10:15 AM, ext André Somers wrote:
> (...)
> The more I think about it, the more I think it is important to fix this:
> who is responsible for the lifetime of the QDnsReply object?
>
> This API does not make that clear. I like the pattern in itself (also in
> QNAM), but I do think it w
On Friday, 4 de November de 2011 11:47:23 Peter Hartmann wrote:
> True, QByteArray then, but why would it be useless? You would just need
> to parse the response itself if the format is not supported, which would
> be easy for TXT, SOA, A6 etc. For CERT and other DNSSEC types you would
> have to do
On 11/04/2011 11:05 AM, ext Thiago Macieira wrote:
> On Friday, 4 de November de 2011 10:36:29 Peter Hartmann wrote:
>> I am happy with having one QDnsReply class; I think we can get pretty
>> far with some special accessors for SRV and other records, and one
>> generic accessor for simple (QString
On Friday, 4 de November de 2011 10:15:54 André Somers wrote:
> The more I think about it, the more I think it is important to fix this:
> who is responsible for the lifetime of the QDnsReply object?
>
> This API does not make that clear. I like the pattern in itself (also in
> QNAM), but I do thin
On Friday, 4 de November de 2011 10:36:29 Peter Hartmann wrote:
> I am happy with having one QDnsReply class; I think we can get pretty
> far with some special accessors for SRV and other records, and one
> generic accessor for simple (QString) and unsupported cases. Then
> whoever wants to read a
On 11/03/2011 08:32 PM, ext Jeremy Lainé wrote:
>
> Le Nov 3, 2011 à 7:10 PM, Peter Hartmann a écrit :
>
>> On 11/03/2011 04:12 PM, ext Thiago Macieira wrote:
>>> (...)
>>> The DNS query is not the problem. A query is always composed of a domain
>>> name
>>> being queried, along with the DNS class
2011/11/4 André Somers :
> Currently, the user
> will have to instantiate the QDnsResolver object, and call the lookupService
> method. It is not so clear what needs to happen to that instance after that.
which brings up a pet QNAM-peeve of mine - a frequent new-to-Qt user
trap is that they instan
On Thu, Nov 3, 2011 at 12:40 PM, Jeremy Lainé wrote:
> Based on some initial feedback I received regarding DNS SRV support in Qt,
> I have refactored my proposed code and introduced a "QDnsResolver" class
> which I would like to submit for API review. The point of this class is to
> provide a QNA
Le Nov 3, 2011 à 7:10 PM, Peter Hartmann a écrit :
> On 11/03/2011 04:12 PM, ext Thiago Macieira wrote:
>> (...)
>> The DNS query is not the problem. A query is always composed of a domain name
>> being queried, along with the DNS class (Internet, no one uses anything else
>> for real purposes) a
On 11/03/2011 04:12 PM, ext Thiago Macieira wrote:
> (...)
> The DNS query is not the problem. A query is always composed of a domain name
> being queried, along with the DNS class (Internet, no one uses anything else
> for real purposes) and the record type. For the record type, it's very easy to
On Thursday, 3 de November de 2011 15:45:31 Peter Hartmann wrote:
> > An open question: should we have multiple lookupXXX() methods, or a single
> > lookup() which takes a QDnsRequest?
> It might make sense to have a generic method for querying any type of
> DNS; but then would we need a QDnsReques
On 11/03/2011 12:40 PM, ext Jeremy Lainé wrote:
> Based on some initial feedback I received regarding DNS SRV support in Qt, I
> have refactored my proposed code and introduced a "QDnsResolver" class which
> I would like to submit for API review. The point of this class is to provide
> a QNAM-st
nt-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of Jeremy Lainé
> Sent: Thursday, November 03, 2011 11:40
> To: development@qt-project.org
> Subject: [Development] API review for a new QDnsResolver class
>
> Based on some initial feedback I received regarding DNS
Based on some initial feedback I received regarding DNS SRV support in Qt, I
have refactored my proposed code and introduced a "QDnsResolver" class which I
would like to submit for API review. The point of this class is to provide a
QNAM-style asynchronous API to perform DNS lookups.
The resolv
On 10/31/2011 05:42 PM, ext Thiago Macieira wrote:
> (...)
>>>- QUrlQuery does not keep the order of the items (it's kept in a hash).
>>>Is
>>>
>>> the order important?
>>
>> I would prefer if the order was kept; e.g. for using OAuth, the
>> parameters need to be sorted in alphabetical orde
On Monday, 31 de October de 2011 16:40:32 Peter Hartmann wrote:
> On 10/25/2011 11:59 AM, ext Thiago Macieira wrote:
> > I can't post the code just yet, but I can post the new API.
> >
> > Questions:
> > - I un-deprecated fromEncoded and toEncoded, as they're used everywhere.
> >
> > Should I d
On 10/25/2011 11:59 AM, ext Thiago Macieira wrote:
> I can't post the code just yet, but I can post the new API.
>
> Questions:
> - I un-deprecated fromEncoded and toEncoded, as they're used everywhere.
> Should I do the same for fromPercentEncoding and toPercentEncoding? They
> convert from QStr
I can't post the code just yet, but I can post the new API.
Questions:
- I un-deprecated fromEncoded and toEncoded, as they're used everywhere.
Should I do the same for fromPercentEncoding and toPercentEncoding? They
convert from QString to QByteArray and vice-versa, while
QByteArray::fromPerc
86 matches
Mail list logo
