On 11/02/2011 07:36 AM, Quim Gil wrote:
> If you are planning to have Qt Project specific discussions, including
> those directly related with development and anything worth taking
> minutes and publish them, then we will gladly schedule them during that
> day.
Watch http://wiki.qt-project.org/Qt_
I'm configuring qtbase (Mac OS 10.6.8, Xcode 4.2, and qtbase/master)
using the following command:
export QTDIR=/some/path/for/installation
./configure -prefix $QTDIR -opensource -no-sql-mysql -qt-libpng
-qt-libjpeg -no-dbus -nomake examples -nomake demos
After a while, I get an error that configu
2011/11/4 Thiago Macieira :
> On Friday, 4 de November de 2011 12:36:40 Chris Meyer wrote:
>> I'm preparing some patches that help applications built on Qt get
>> accepted into the App Store.
>>
>> My project is currently being built on qt/4.7 and I'll be switching to
>> qt/4.8 when it is officiall
On Friday, 4 de November de 2011 12:36:40 Chris Meyer wrote:
> I'm preparing some patches that help applications built on Qt get
> accepted into the App Store.
>
> My project is currently being built on qt/4.7 and I'll be switching to
> qt/4.8 when it is officially released.
>
> What is the best pl
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
I'm preparing some patches that help applications built on Qt get
accepted into the App Store.
My project is currently being built on qt/4.7 and I'll be switching to
qt/4.8 when it is officially released.
What is the best place to submit those merge requests? In
qtbase/master, qt/4.7, qt/4.8, or
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
On 11/04/11 14:29, ext Holger Hans Peter Freyther wrote:
> I want to use file:*directfb*, but according to this[1] I will need to watch
> the project,
correct. the search function generally sucks.
> so I started to watch qt/qtbase with a file:\*directfb\* glob but
this won't work. this must be a r
On Thursday, November 03, 2011 08:33:37 Quim Gil wrote:
> Hi, I want to propose the creation of a mailing list focusing on
> marketing, events and misc community activities not directly related
> with software development:
>
> - qt-project.org content.
> - Marketing activities.
> - Organization an
> Hi,
>
> I have checked the wiki and I am failing to find the information. I want
> to
> search for all changes to directfb and I fail to do so.
>
> I could do this by searching for directfb in messages or based on a file
> glob.
> I somehow fail...
>
>
> Searching by name:
> "message:directfb" do
Hi,
I have checked the wiki and I am failing to find the information. I want to
search for all changes to directfb and I fail to do so.
I could do this by searching for directfb in messages or based on a file glob.
I somehow fail...
Searching by name:
"message:directfb" does work.
Searching by
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
Hi Andrew,
On 11/4/11 9:39 AM, "ext andrew.den-ex...@nokia.com"
wrote:
>Sometime during the refactor QTextEdit and QLineEdit acquired their own
>copies of these classes leaving QtDeclarative as the only user of this
>private API that I'm aware of.
Yes, that was required to get the library split
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
Another +1 from me.
Cheers,
Lars
On 11/3/11 6:45 PM, "ext Thiago Macieira"
wrote:
>On Thursday, 3 de November de 2011 08:33:37 Quim Gil wrote:
>> The existence of "marketing" or "community" specific mailing lists in
>> big free software projects is quite usual. Probably for a good reason.
>>
>
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 3 Nov 2011, at 11:15, ext Thiago Macieira wrote:
> On Thursday, 3 de November de 2011 09:50:45 eike.zil...@nokia.com wrote:
>> Btw, I don't think the governance model handles how changes to the
>> governance model itself are done
>
> And how do we handle the changes to the way the model is ch
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
Sometime during the refactor QTextEdit and QLineEdit acquired their own copies
of these classes leaving QtDeclarative as the only user of this private API
that I'm aware of. Coordinating bug fixes that required patches to one of
these classes in qtbase and and TextInput or TextEdit in qtdeclara
29 matches
Mail list logo
