On 10/25/11 10:51 PM, "ext marius.storm-ol...@nokia.com"
wrote:
>Hi Maintainers and Approver,
>
>Please keep in mind dependent modules when you approve and merge in
>changes which can lead to dependent projects failing. If you know that a
>commit has a risk of destabilizing other modules, please
On Wednesday, 26 de October de 2011 23.28.53, Olivier Goffart wrote:
> After a small talk with David Faure, we came to the conclusion that maybe
> it would be a good temporary solution to define
> QT_DISABLE_DEPRECATED_BEFORE to 4.9 to re-enable (temporarely) all the
> deprecated function, untill
I also agree. Javascript just never occurred to me...
On Wed, Oct 26, 2011 at 1:13 AM, Mark Constable wrote:
> On 2011-10-25 11:32 PM, Gábor Lehel wrote:
> > > Lastly, ties to a scripting language would be excellent, and it
> > > would be great if we could start with Lua since it is dead simple
Hi,
First, let me re-introduce (for those that did not know) QT_DEPRECATED_SINCE:
It was added in the commit 6618dd877f83be56d140882a2f6c3fa5a985c2d2
The goal of this macro is to "versionize" when a a function is deprecated.
Then, one can define in his project QT_DISABLE_DEPRECATED_BEFORE to con
On Tuesday 25 October 2011 22:53:02 Frans Klaver wrote:
> Hi,
>
> On Tue, 25 Oct 2011 22:19:29 +0200, Antonis Tsiapaliokas
>
> wrote:
> > Also, please read the comment from the John Brooks, which i think
> > that he isright. So what do you think?
>
> I would say he is right. He strongly hints a
2011/10/25 Antonis Tsiapaliokas :
> So what do you think? Is there any way to add this feature or it will to
> hackish? (if we assume that we want to support for all the ways that a
> string can represent a bool...)
I think we should then really discuss about what should be considered
to be "true"
On Wednesday 26 October 2011 20:03:56 Robin Burchell wrote:
> Hi,
>
> On Wed, Oct 26, 2011 at 7:44 PM, Olivier Goffart wrote:
> > So that class really fits into Qt. But only as a low level class
> > (that could even stay internal maybe, I still fail to see a use case for
> > it that is not covere
Hi,
On Wed, Oct 26, 2011 at 7:44 PM, Olivier Goffart wrote:
> So that class really fits into Qt. But only as a low level class
> (that could even stay internal maybe, I still fail to see a use case for it
> that is not covered by the convinience i suggest)
(without ever having actually read the
On Wednesday 26 October 2011 15:15:11 Jeremy Lainé wrote:
> Some time ago a bug [1] was filed against Qt pointing out the fact there
> that Qt4 has no API for doing DNS SRV lookups. Such lookups are important
> for implementing both XMPP and SIP applications, and as such I wrote an
> implementation
Hi,
On Wed, Oct 26, 2011 at 5:56 PM, wrote:
> To avoid ambiguity with other types of service, QDnsService makes sense to me.
It's also a lot easier to pronounce, which is always a good thing. :)
BR,
Robin
___
Development mailing list
Development@qt-
> -Original Message-
> On Behalf Of Jeremy Lainé
> Sent: Wednesday, October 26, 2011 14:15
> To: development@qt-project.org
> Subject: [Development] QTBUG-10481: Adding support for DNS SRV lookups
>
...
> I would like to get some further feedback on the API / implementation
> in order to ho
On 10/26/2011 11:12 AM, Giovanni Bajo wrote:
> Hi,
>
> I'm not sure what's the correct "meta-list" now (list for discussion on the
> qt-project itself), so I'm posting there. I apologize in advance if it is not
> the correct list.
>
> Gerrit is available on both http:// and https://, but since it
Some time ago a bug [1] was filed against Qt pointing out the fact there that
Qt4 has no API for doing DNS SRV lookups. Such lookups are important for
implementing both XMPP and SIP applications, and as such I wrote an
implementation for the QXmpp [2] project which has been in use for over a yea
On Wed, Oct 26, 2011 at 12:50 PM, Andre Somers wrote:
> Note that the verification flag would be optional anyway. If you return
> false if ok is false, then you can easily choose if you need
> verification or not. It just needs to be clearly documented.
As always.
> However, if
> you think that
Op 26-10-2011 10:02, Frans Klaver schreef:
> On Wed, Oct 26, 2011 at 9:21 AM, Andre Somers wrote:
>
>> IMHO, there is a big difference between a string that correctly converts
>> to false, and one that can not be converted to a boolean. Do you really
>> wish to make that difference invisible?
> Ce
On Wednesday, 26 de October de 2011 07.15.59, jan-arve.saet...@nokia.com
wrote:
> bool parseOk;
> if (!str.toBool(&parseOk)) {
>if (parseOk)
>disableSuperFastRenderer();
> }
bool parseOk
if (!str.toBool(&parseOk) && parseOk)
disableSuperFastRenderer();
Or you can accept that, if
Hi,
I'm not sure what's the correct "meta-list" now (list for discussion on the
qt-project itself), so I'm posting there. I apologize in advance if it is not
the correct list.
Gerrit is available on both http:// and https://, but since it's using HTTP
basic-auth, passwords are transmitted in c
On Wed, Oct 26, 2011 at 9:21 AM, Andre Somers wrote:
> IMHO, there is a big difference between a string that correctly converts
> to false, and one that can not be converted to a boolean. Do you really
> wish to make that difference invisible?
Certainly not.
> I agree with Jan Arve on this topi
Op 26-10-2011 8:39, Frans Klaver schreef:
> On Wed, Oct 26, 2011 at 8:31 AM, wrote:
>
>> Consider this code:
>>
>> bool parseOk;
>> if (str.toBool(&parseOk)) {
>> if (parseOk)
>> enableSuperFastRenderer();
>> }
> I think that in most, if not all cases, the parseOk argument would or
> e
ext Frans Klaver wrote on 2011-10-26:
> On Wed, Oct 26, 2011 at 8:31 AM, wrote:
>
>> Consider this code:
>>
>> bool parseOk;
>> if (str.toBool(&parseOk)) {
>> if (parseOk)
>> enableSuperFastRenderer();
>> }
>
> I think that in most, if not all cases, the parseOk argument would or
>
20 matches
Mail list logo
