Re: [Development] Nominating Janne Anttila as Approver

[Knoll Lars]

The 15 days are over, so congratulations Janne!

Cheers,
Lars

On Oct 17, 2012, at 4:18 AM, Rohan McGovern  wrote:

> I hereby nominate Janne Anttila as an approver.
> 
> Janne has a long history with Qt, going back (at least?) to the initial
> Qt for S60 port in 2008.  In the past several years, Janne has contributed
> many fixes to all platforms (especially, it seems, those platforms which
> nobody else likes to work on :)
> 
> I count over 500 commits in Qt authored or reviewed by Janne.
> 
> Recently, Janne has also been leading the creation of Digia's new test farm
> to be used in the Qt Project CI system.
> 
> See Janne's dashboard and recently merged patches for further evidence
> of his many contributions:
> 
>  https://codereview.qt-project.org/#dashboard,1000971
>  
> https://codereview.qt-project.org/#q,owner:janne.anttila%2540digia.com+status:merged,n,z
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Load qml state from separate files

[hailong geng]

I want to load state from separate files but I don't know how to do that, 
especially on how to deal with target property of PropertyChanges Item, this is 
the link http://qt-project.org/forums/viewthread/21699/ ,please help me, thank 
you.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

[Qi Liang]

Any plan for osx-10.8-64, Mac OS X Mountain Lion, 10.8? Thanks.

Regards,
Liang

From: development-bounces+liang.qi=digia@qt-project.org 
[development-bounces+liang.qi=digia@qt-project.org] on behalf of Koehne Kai 
[kai.koe...@digia.com]
Sent: Tuesday, November 06, 2012 5:08 PM
To: development@qt-project.org
Subject: [Development] Proposal: New list of Qt 5 reference / Tier 1
platforms

Hi,

The list of reference & Tier 1 platforms at 
http://qt-project.org/wiki/Qt-5#Platforms is somewhat out of date ... Here is a 
new proposal

Reference Platforms:

We have the following platform configurations as reference platforms for Qt 5.0:

PLATFORM  CONFIGURATION COMPILER
linux-x86-32-gcc-x11  Ubuntu Linux 11.10 ×86 32 bit, X11as 
provided
linux-x86-64-gcc-x11  Ubuntu Linux 11.10 ×86 64 bit, X11as 
provided
windows-7-32-msvc2010-angle   Microsoft Windows 7 32 bit, ANGLE 
MSVC2010-SP1 32-bit
osx-10.7-64   Apple Mac OS X 10.7 "Lion" Cocoa 64 bit   as 
provided


Tier 1 platforms:

In addition to the reference platform configurations, we support the following 
configurations on Tier 1 level.

PLATFORM  CONFIGURATION COMPILER
windows-7-64-msvc2010-angle   Microsoft Windows 7 64 bit, ANGLE 
MSVC2010-SP1 64-bit
windows-7-32-msvc2010-opengl  Microsoft Windows 7 32 bit, OpenGL
MSVC2010-SP1 32-bit
windows-7-64-msvc2010-opengl  Microsoft Windows 7 64 bit, OpenGL
MSVC2010-SP1 64-bit
windows-7-32-mingw-builds Microsoft Windows XP Windows 7 32 bit gcc 4.7 
(MinGW-builds)
windows-xp-32-msvc2008Microsoft Windows XP SP3 32 bit   MSVC 
2008 32-bit
osx-10.6-64   Apple Mac OS X 10.6 Cocoa 64 bit  as 
provided




Remarks:

Before you shoot, check 
http://qt-project.org/groups/qt-contributors-summit-2011/wiki/Qt5ProductDefinition#4582cf86974b397c8f3a2ed2fd502f8c
 to see what we agreed upon back then what the requirements of a 'reference 
platform' and 'Tier 1 platform' are, specifically  that they are in tested by 
the CI system, and are available as alpha, beta, final packages.

windows-7-64-msvc2010, windows-7-64-msvc2010-angle, windows-7-32-mingw-builds 
aren't checked in the CI system right now. Still I think they are important 
enough to deserve an exception, and remain in Tier 1.

I understood that whether we can keep osx-10.6-64 bit as Tier 1 platform for 
qtwebkit is yet unclear.

Finally, I don't know what to do  with the *wayland, *mips, *icc platforms in 
the current version of the page.


Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[Corentin Jabot]

2012/11/7 Thiago Macieira :
> On quarta-feira, 7 de novembro de 2012 00.07.41, Corentin Jabot wrote:
>> The following seems like a good subset of the QAbstractSocket
>> interfaces that also makes sense for QLocalSocket
>
> I don't want you to list functions that are common. I can do that by myself.
>
> I want you to explain *why* you need those. And while you're at it, let us
> know whether they should be shared with QProcess and QNetworkReply too.
>
>>
>> void abort ()
>> void disconnectFromHost ()
>
> No for disconnectFromHost so long as connectToHost() isn't common. You'll have
> to make do with close().

Makes sense

>> SocketError error () const
>
> I'd have liked to replace this with a QtNetwork-wide error enum, the one in
> QNetworkReply.

Would be neat !

>> bool flush ()
>> bool isValid () const
>
> Explain why you need isValid and why isOpen or others don't suffice.

Well if that method is useful in both QLocalSocket & QAbstractSocket,
i guess it should be common.
But if isOpen() do the trick, then... maybe that method is not useful
in the first place,
should it be deprecated. or the doc should state "see also isOpen()" ?

>
>> qint64 readBufferSize () const
>> void setReadBufferSize ( qint64 size )
>
> I completely agree with those two. They should be in QIODevice itself.

Should flush() be in QIODevice too ? I think there could be other
use-case for it

>
>> bool setSocketDescriptor ( int socketDescriptor, SocketState
>> socketState = ConnectedState, OpenMode openMode = ReadWrite )
>
> No on this one. I don't think that replacing an existing socket makes sense in
> the common base. You usually need to know that the socket type is compatible
> with the class that you're using. Therefore, this does not need to be common.

Agree, It depends indeed to much of the implementation

>
>> int socketDescriptor () const
>
> Yes on this one.

You said disconnect should not be common if connect is not, and, I
tend to agree.
Isn't that the same for socketDescriptor/setSocketDescriptor ?

>
>> SocketType socketType () const
>
> Yes and QLocalSocket needs to differentiate a local socket and an abstract
> local socket.
>
>> SocketState state () const
>
> Makes sense.
>
>> bool waitForConnected ( int msecs = 3 )
>> bool waitForDisconnected ( int msecs = 3 )
>
> No on both of those: connecting is specific on the type, therefore
> waitForConnected is specific too. If disconnectFromHost isn't common either,
> then waitForDisconnected shouldn't be either.
>
>> The SocketError & SocketState enums have already similar values in both
>> class
>>
>> SocketType should be in TcpSocket, UdpSocket, LocalSocket - ( could
>> also be NamedPipeSocket ? )
>
> It should differentiate based on the implementation in the backend. There's
> also the NonceTcpSocket possibility for QLocalSocket. I agree we need it.
>
>> The following signals could also be common (again, it's about using
>> the same enums):
>> void connected ()
>> void disconnected ()
>> void error ( QAbstractSocket::SocketError socketError )
>> void stateChanged ( QAbstractSocket::SocketState socketState )
>>
>> I dont see how the connectTo* methods could be shared, and I don't
>> think it would be a good idea to try to do so.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[d3fault]

On 11/6/12, Corentin Jabot  wrote:
>
> I dont see how the connectTo* methods could be shared, and I don't
> think it would be a good idea to try to do so.
>

I disagree. Having a QList and then being able to
iterate over them and connectTo* and disconnectFrom* without knowing
their type is helpful. You (_developer_) can't know the duration of
each connection (_user_) either so we could move the traditional
connectTo parameters into a new constructor and expose them as
properties as well. Then QAbstractSocket::connectToHost() would have
no arguments, and we can provide a helper/source-compatible overload
QTcpSocket::connectToHost(host, port) while we're at it. The base type
constructor has no arguments and calling the empty connectToHost
before setting up the properties will just return false.

(I'm conveniently ignoring QObject *parent and Read/ReadWrite args as
they aren't relevant)


Iterating over a list of connections like this is already possible,
but as stated requires glue code and ugly hacky design. This thread is
just about a cleanup. Since no new code is introduced, there's a very
low chance of introducing bugs and it's worth breaking the randomly
declared (in May!) feature freeze.



Additionally, hostName() is shared in the obvious way and we
can/should introduce a url() or some such that would, for example,
append the port after a colon (in relevant subclasses). I guess this
would also imply being able to pass in that url (to yet another
constructor in each subclass) as an alternative to specifying the
host/port as separate args.


d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[Thiago Macieira]

On quarta-feira, 7 de novembro de 2012 00.07.41, Corentin Jabot wrote:
> The following seems like a good subset of the QAbstractSocket
> interfaces that also makes sense for QLocalSocket

I don't want you to list functions that are common. I can do that by myself.

I want you to explain *why* you need those. And while you're at it, let us 
know whether they should be shared with QProcess and QNetworkReply too.

> 
> void abort ()
> void disconnectFromHost ()

No for disconnectFromHost so long as connectToHost() isn't common. You'll have 
to make do with close().

> SocketError error () const

I'd have liked to replace this with a QtNetwork-wide error enum, the one in 
QNetworkReply.

> bool flush ()
> bool isValid () const

Explain why you need isValid and why isOpen or others don't suffice.

> qint64 readBufferSize () const
> void setReadBufferSize ( qint64 size )

I completely agree with those two. They should be in QIODevice itself.

> bool setSocketDescriptor ( int socketDescriptor, SocketState
> socketState = ConnectedState, OpenMode openMode = ReadWrite )

No on this one. I don't think that replacing an existing socket makes sense in 
the common base. You usually need to know that the socket type is compatible 
with the class that you're using. Therefore, this does not need to be common.

> int socketDescriptor () const

Yes on this one.

> SocketType socketType () const

Yes and QLocalSocket needs to differentiate a local socket and an abstract 
local socket.

> SocketState state () const

Makes sense.

> bool waitForConnected ( int msecs = 3 )
> bool waitForDisconnected ( int msecs = 3 )

No on both of those: connecting is specific on the type, therefore 
waitForConnected is specific too. If disconnectFromHost isn't common either, 
then waitForDisconnected shouldn't be either.

> The SocketError & SocketState enums have already similar values in both
> class
> 
> SocketType should be in TcpSocket, UdpSocket, LocalSocket - ( could
> also be NamedPipeSocket ? )

It should differentiate based on the implementation in the backend. There's 
also the NonceTcpSocket possibility for QLocalSocket. I agree we need it.

> The following signals could also be common (again, it's about using
> the same enums):
> void connected ()
> void disconnected ()
> void error ( QAbstractSocket::SocketError socketError )
> void stateChanged ( QAbstractSocket::SocketState socketState )
> 
> I dont see how the connectTo* methods could be shared, and I don't
> think it would be a good idea to try to do so.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[Corentin Jabot]

The following seems like a good subset of the QAbstractSocket
interfaces that also makes sense for QLocalSocket

void abort ()
void disconnectFromHost ()
SocketError error () const
bool flush ()
bool isValid () const
qint64 readBufferSize () const
void setReadBufferSize ( qint64 size )
bool setSocketDescriptor ( int socketDescriptor, SocketState
socketState = ConnectedState, OpenMode openMode = ReadWrite )
int socketDescriptor () const
SocketType socketType () const
SocketState state () const
bool waitForConnected ( int msecs = 3 )
bool waitForDisconnected ( int msecs = 3 )

The SocketError & SocketState enums have already similar values in both class

SocketType should be in TcpSocket, UdpSocket, LocalSocket - ( could
also be NamedPipeSocket ? )

The following signals could also be common (again, it's about using
the same enums):
void connected ()
void disconnected ()
void error ( QAbstractSocket::SocketError socketError )
void stateChanged ( QAbstractSocket::SocketState socketState )

I dont see how the connectTo* methods could be shared, and I don't
think it would be a good idea to try to do so.

Regards,
Corentin.


2012/11/6 Thiago Macieira :
> On terça-feira, 6 de novembro de 2012 11.49.40, Alfonso Chartier wrote:
>> Someone below asked what the motivation is behind having a common abstract
>> socket base class for all concrete socket types. The reason for this is it
>> can significantly clean up client code. Currently if I want to handle
>> different sockets generically (e.g., TCP vs. local), I have to jump through
>> several hurdles: create my own wrapper class abstraction, maintain separate
>> lists of objects, etc. A single, common base class would allow client code
>> to use polymorphism to manage and use socket objects very easily. For
>> instance, I could then have client code that defines a
>> QList and is able to connect, disconnect, write, read,
>> etc. from the socket without having to know the concrete class type.
>>
>> I hope this helps explain why it would be very useful to have a common base
>> socket class.
>
> It's very clear why you'd want to have a common base class, but you were not
> concrete on the details. I want to know what methods from QAbstractSocket
> and/or QLocalSocket would you like to see in this common base class, methods
> that aren't in QIODevice.
>
> Or, asked from another angle: why you can't use QList in your
> case above? You said disconnect, read, write, all of which you can do with
> QIODevice (close() is virtual, the signals are in QIODevice).
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Issues with compiling Qt-Creator on windows

[Majid Khan]

I am now using Qt creator to build qt creator and my build step currently
look like:

qmake.exe qtcreator.pro -r -spec win32-msvc2010 "CONFIG+=declarative_debug"

and my private files are in: C:\QtSDK\QtSources\4.8.1\include\QtCore\private

Do I change my build step to


qmake.exe qtcreator.pro -r -spec win32-msvc2010
"CONFIG+=declarative_debug" -r
QT_PRIVATE_HEADERS="/home/me/where/qt/buildtree/is/include"
?

also is there anything else I would need to change?


Thanks

On Mon, Oct 8, 2012 at 6:50 PM, Ziller Eike  wrote:

>
> On 7 Oct 2012, at 16:21, Majid Khan  wrote:
>
> > I have tried compiling Qt creator using VS2010 (qt4.8.1) but I am
> missing .
> >
> > It works alright in linux (but thats because inclusion is under
> pre-processor directive for Q_OS_WIN.  I have seen this has been issue for
> some other people too but haven't seen any fix around it.
> >
> > Anyone has any idea for a workaround it?
>
> That's a private Qt header. If you have an installed Qt / a Qt with a
> install prefix that is not the source directory, you need to point Qt
> Creator's build to where the private headers are by setting the qmake
> variable QT_PRIVATE_HEADERS, e.g.
>
> qmake -r QT_PRIVATE_HEADERS="/home/me/where/qt/buildtree/is/include" &&
> make
>
> Br, Eike
>
> --
> Eike Ziller, Senior Software Engineer - Digia, Qt
>
> Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
>
>


-- 
Majid Khan
http://www.icplusplus.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

[Thiago Macieira]

On terça-feira, 6 de novembro de 2012 16.08.06, Koehne Kai wrote:
> Hi,
>
> The list of reference & Tier 1 platforms at
> http://qt-project.org/wiki/Qt-5#Platforms is somewhat out of date ... Here
> is a new proposal
>
> Reference Platforms:
>
> We have the following platform configurations as reference platforms for Qt
> 5.0:
>
> PLATFORM  CONFIGURATION
> COMPILER linux-x86-32-gcc-x11  Ubuntu Linux 11.10 ×86 32 bit, X11
>  as provided linux-x86-64-gcc-x11  Ubuntu Linux 11.10 ×86 64
> bit, X11as provided windows-7-32-msvc2010-angle   Microsoft Windows
> 7 32 bit, ANGLE MSVC2010-SP1 32-bit osx-10.7-64
> Apple Mac OS X 10.7 "Lion" Cocoa 64 bit   as provided

The above looks fine. I'd just like to be clear that the reference platforms
are, generically:
 - Windows
 - Mac OS X
 - Linux (Wayland and X11)

and that you're just being specific of what that means at this particular point
in time.

> Tier 1 platforms:

> Remarks:
>
> Before you shoot, check
> http://qt-project.org/groups/qt-contributors-summit-2011/wiki/Qt5ProductDef
> inition#4582cf86974b397c8f3a2ed2fd502f8c to see what we agreed upon back
> then what the requirements of a 'reference platform' and 'Tier 1 platform'
> are, specifically  that they are in tested by the CI system, and are
> available as alpha, beta, final packages.

Like above, generically speaking, tier 1 platforms are those that participate
in the release process, providing a good, usable release and, in addition,
have a team that commits to supporting it for a certain period of time.

Your list of criteria above is a good declination and a goal that we should
strive for. However, since right now no external platform can integrate with
the CI, I don't think it's fair to require it. So we should be able to list
certain platforms as Tier 1, provided they meet the other quality criteria,
even if they aren't in the CI.

Specifically, I'm thinking of QNX and, in turn, wondering if the team behind it
is committed to the quality effort to Tier 1 in 5.0.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[Thiago Macieira]

On terça-feira, 6 de novembro de 2012 11.49.40, Alfonso Chartier wrote:
> Someone below asked what the motivation is behind having a common abstract
> socket base class for all concrete socket types. The reason for this is it
> can significantly clean up client code. Currently if I want to handle
> different sockets generically (e.g., TCP vs. local), I have to jump through
> several hurdles: create my own wrapper class abstraction, maintain separate
> lists of objects, etc. A single, common base class would allow client code
> to use polymorphism to manage and use socket objects very easily. For
> instance, I could then have client code that defines a
> QList and is able to connect, disconnect, write, read,
> etc. from the socket without having to know the concrete class type.
>
> I hope this helps explain why it would be very useful to have a common base
> socket class.

It's very clear why you'd want to have a common base class, but you were not
concrete on the details. I want to know what methods from QAbstractSocket
and/or QLocalSocket would you like to see in this common base class, methods
that aren't in QIODevice.

Or, asked from another angle: why you can't use QList in your
case above? You said disconnect, read, write, all of which you can do with
QIODevice (close() is virtual, the signals are in QIODevice).
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[Alfonso Chartier]

rmat
>
>
> If it's still not working, you need to check what's going in the platform-
> plugin
>  - Is their a native egl/opengl-surface which has multisampling aviable?
>  - Is the platform-plugin using it? why not?
>
>
> Greets
> Thomas
>
> >
> >
> >
> > With best regards,
> > Torsten Labs
> >
> > Siemens AG
> > Industry Sector
> > Industry Automation Division
> > Industrial Automation Systems
> > Factory Automation
> > I IA AS FA WF FTH 2
> > Siemensstr. 2-4
> > 90766 Fuerth, Germany
> > Tel.: +49 911 978-3682
> > mailto:torsten.l...@siemens.com
> >
> > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
> > Cromme; Managing Board: Peter Loescher, Chairman, President and Chief
> > Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe
> > Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y.
> > Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany;
> > Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB
> 6684;
> > WEEE-Reg.-No. DE 23691322
>
>
> --
>
> Message: 7
> Date: Tue, 6 Nov 2012 10:59:03 -0700
> From: Charley Bay 
> Subject: Re: [Development] Proposal: New list of Qt 5 reference / Tier
> 1   platforms
> To: Koehne Kai 
> Cc: "development@qt-project.org" 
> Message-ID:
> <
> caoqne30xuwcgc5dpxn61nh8msg0gxkdinwx0ifpb3gcifym...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Kai spaketh:
> > The list of reference & Tier 1 platforms at
> http://qt-project.org/wiki/Qt-5#Platforms
> > is somewhat out of date ... Here is a new proposal ,
>
> Seems fine to me.
>
> An aside -- serious suggestion:
>
> We are successfully using the, "MSVS2010, SP1" compiler within the
> "MSVS2008 IDE" using the steps found here:
>
> <
> http://www.codeproject.com/Tips/105011/Using-Visual-Studio-2008-IDE-with-Visual-C-2010-co
> >
>
> IMHO, the MSVS2010 IDE is, "badly-broken" and quite unusable for our needs.
>
> REQUEST:  For the Tier-1 "MSVS2010, SP1, Win7-32bit" release, IT WOULD
> BE NICE if "QMake" would still have the OPTION to generate "MSVS2008
> *.vcproj" instances.  Please.  Pretty Please.  And then, I will send
> you home-made cookies.  Every month.
>
> --charley
>
>
> --
>
> Message: 8
> Date: Tue, 6 Nov 2012 10:23:05 -0800
> From: Romain Pokrzywka 
> Subject: Re: [Development] QT.module.rpath is not used properly
> To: Thomas Senyk 
> Cc: "development@qt-project.org" 
> Message-ID:
> <
> caknafds0hewtdd44lzhwra6r7my4pp+dc0fz6mwmoyk8-zq...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I have a fix for this issue in Gerrit which has been waiting for weeks:
>
> https://codereview.qt-project.org/35394
>
> But it hasn't been approved yet because apparently ossi thinks the commit
> log isn't clear enough. Maybe you can explain it to him in better words
> than I do.
>
> Romain
> On Nov 6, 2012 9:27 AM, "Thomas Senyk" 
> wrote:
>
> > Hi Folks,
> >
> > I got a self-written mkspec for the rasp-pi and everything is working as
> > expected.
> >
> > With one exception, for external applications he is not adding the proper
> >  -Wl,-rpath,
> >
> >
> > The problem is that:
> > cat /usr/local/Trolltech/Qt5-rasp-pi-2/mkspecs/modules/qt_lib_* |grep
> rpath
> >
> > returns nothing.
> >
> >  --> the installed module pri files do not contain the rpath and
> rpath-link
> > variables anymore.
> >
> > The ones in the qt-build-directory do.
> > e.g.: qt_lib_core.pri contains:
> > QT.core.rpath = /usr/local/Trolltech/Qt5-rasp-pi-2/lib
> >
> >
> >
> > Any though how/why they vanished?
> >
> >
> >
> > FYI:
> > If you add a module to "QT" in your project file, qt_functions.prf:93
> will
> > add:
> >  -Wl,-rpath,/
> >
> > ...which is totally wrong... but maybe expected if QT.module.rpath is
> > empty?
> >
> > Greets
> > Thomas
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> http://lists.qt-project.org/pipermail/development/attachments/20121106/ffd37e58/attachment.html
>
> --
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> End of Development Digest, Vol 14, Issue 18
> ***
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT.module.rpath is not used properly

[Oswald Buddenhagen]

On Tue, Nov 06, 2012 at 06:17:04PM +0100, Thomas Senyk wrote:
> I got a self-written mkspec for the rasp-pi and everything is working as 
> expected.
> 
> With one exception, for external applications he is not adding the proper
>  -Wl,-rpath,

> The problem is that:
>   cat /usr/local/Trolltech/Qt5-rasp-pi-2/mkspecs/modules/qt_lib_* |grep rpath
> returns nothing.
> 
that's not the problem.

> If you add a module to "QT" in your project file, qt_functions.prf:93 will 
> add:
>  -Wl,-rpath,/
> 
*that* is the problem.
the fallback path doesn't account for sysroots. and it cannot do that
cleanly. so it should be scrapped.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

[Oswald Buddenhagen]

On Tue, Nov 06, 2012 at 10:59:03AM -0700, Charley Bay wrote:
> REQUEST:  For the Tier-1 "MSVS2010, SP1, Win7-32bit" release, IT WOULD
> BE NICE if "QMake" would still have the OPTION to generate "MSVS2008
> *.vcproj" instances.  Please.  Pretty Please.  And then, I will send
> you home-made cookies.  Every month.
> 
just run
  qmake -spec win32-msvc2008
if that doesn't just work, then the request will cost you a lot more
cookies than you think ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT.module.rpath is not used properly

[Romain Pokrzywka]

I have a fix for this issue in Gerrit which has been waiting for weeks:

https://codereview.qt-project.org/35394

But it hasn't been approved yet because apparently ossi thinks the commit
log isn't clear enough. Maybe you can explain it to him in better words
than I do.

Romain
On Nov 6, 2012 9:27 AM, "Thomas Senyk"  wrote:

> Hi Folks,
>
> I got a self-written mkspec for the rasp-pi and everything is working as
> expected.
>
> With one exception, for external applications he is not adding the proper
>  -Wl,-rpath,
>
>
> The problem is that:
> cat /usr/local/Trolltech/Qt5-rasp-pi-2/mkspecs/modules/qt_lib_* |grep rpath
>
> returns nothing.
>
>  --> the installed module pri files do not contain the rpath and rpath-link
> variables anymore.
>
> The ones in the qt-build-directory do.
> e.g.: qt_lib_core.pri contains:
> QT.core.rpath = /usr/local/Trolltech/Qt5-rasp-pi-2/lib
>
>
>
> Any though how/why they vanished?
>
>
>
> FYI:
> If you add a module to "QT" in your project file, qt_functions.prf:93 will
> add:
>  -Wl,-rpath,/
>
> ...which is totally wrong... but maybe expected if QT.module.rpath is
> empty?
>
> Greets
> Thomas
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

[Charley Bay]

Kai spaketh:
> The list of reference & Tier 1 platforms at 
> http://qt-project.org/wiki/Qt-5#Platforms
> is somewhat out of date ... Here is a new proposal ,

Seems fine to me.

An aside -- serious suggestion:

We are successfully using the, "MSVS2010, SP1" compiler within the
"MSVS2008 IDE" using the steps found here:



IMHO, the MSVS2010 IDE is, "badly-broken" and quite unusable for our needs.

REQUEST:  For the Tier-1 "MSVS2010, SP1, Win7-32bit" release, IT WOULD
BE NICE if "QMake" would still have the OPTION to generate "MSVS2008
*.vcproj" instances.  Please.  Pretty Please.  And then, I will send
you home-made cookies.  Every month.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Beta/Qt Quick 2.0 and Antialiasing

[Thomas Senyk]

On Tue, October 30, 2012 11:14:46 AM Labs, Torsten wrote:
> Hello,
> 
> we created some prototype with Qt Quick 2 on a ARM board. Its running verry
> well except antialiasing. As i can see in the Qt5 Documentation there is a
> new flag for antialiasing *  
> antialiasing iasing-prop> : bool
> 
> but this makes no difference. Is there still a bug?
> 
> Thx
> 
> Torsten

In general it's the duty of the platform plugin (I assume eglfs or 
minimalegl?) to provide a native-surface which has multisampling.


The application-level API to request a multisample surface is:
http://doc-snapshot.qt-project.org/5.0/qsurfaceformat.html#setSamples

Then set the changed surfaceformat with:
http://doc-snapshot.qt-project.org/5.0/qwindow.html#setFormat


If it's still not working, you need to check what's going in the platform-
plugin
 - Is their a native egl/opengl-surface which has multisampling aviable?
 - Is the platform-plugin using it? why not?


Greets
Thomas

> 
> 
> 
> With best regards,
> Torsten Labs
> 
> Siemens AG
> Industry Sector
> Industry Automation Division
> Industrial Automation Systems
> Factory Automation
> I IA AS FA WF FTH 2
> Siemensstr. 2-4
> 90766 Fuerth, Germany
> Tel.: +49 911 978-3682
> mailto:torsten.l...@siemens.com
> 
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
> Cromme; Managing Board: Peter Loescher, Chairman, President and Chief
> Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe
> Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y.
> Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany;
> Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
> WEEE-Reg.-No. DE 23691322
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QT.module.rpath is not used properly

[Thomas Senyk]

Hi Folks,

I got a self-written mkspec for the rasp-pi and everything is working as 
expected.

With one exception, for external applications he is not adding the proper
 -Wl,-rpath,


The problem is that:
cat /usr/local/Trolltech/Qt5-rasp-pi-2/mkspecs/modules/qt_lib_* |grep rpath

returns nothing.

 --> the installed module pri files do not contain the rpath and rpath-link 
variables anymore.

The ones in the qt-build-directory do.
e.g.: qt_lib_core.pri contains:
QT.core.rpath = /usr/local/Trolltech/Qt5-rasp-pi-2/lib



Any though how/why they vanished?



FYI:
If you add a module to "QT" in your project file, qt_functions.prf:93 will add:
 -Wl,-rpath,/

...which is totally wrong... but maybe expected if QT.module.rpath is empty?

Greets
Thomas
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

[Koehne Kai]

Hi,
 
The list of reference & Tier 1 platforms at 
http://qt-project.org/wiki/Qt-5#Platforms is somewhat out of date ... Here is a 
new proposal

Reference Platforms:

We have the following platform configurations as reference platforms for Qt 5.0:

PLATFORM  CONFIGURATION COMPILER
linux-x86-32-gcc-x11  Ubuntu Linux 11.10 ×86 32 bit, X11as 
provided
linux-x86-64-gcc-x11  Ubuntu Linux 11.10 ×86 64 bit, X11as 
provided
windows-7-32-msvc2010-angle   Microsoft Windows 7 32 bit, ANGLE 
MSVC2010-SP1 32-bit
osx-10.7-64   Apple Mac OS X 10.7 "Lion" Cocoa 64 bit   as 
provided


Tier 1 platforms:

In addition to the reference platform configurations, we support the following 
configurations on Tier 1 level.

PLATFORM  CONFIGURATION COMPILER
windows-7-64-msvc2010-angle   Microsoft Windows 7 64 bit, ANGLE 
MSVC2010-SP1 64-bit
windows-7-32-msvc2010-opengl  Microsoft Windows 7 32 bit, OpenGL
MSVC2010-SP1 32-bit
windows-7-64-msvc2010-opengl  Microsoft Windows 7 64 bit, OpenGL
MSVC2010-SP1 64-bit
windows-7-32-mingw-builds Microsoft Windows XP Windows 7 32 bit gcc 4.7 
(MinGW-builds)
windows-xp-32-msvc2008Microsoft Windows XP SP3 32 bit   MSVC 
2008 32-bit
osx-10.6-64   Apple Mac OS X 10.6 Cocoa 64 bit  as 
provided




Remarks:

Before you shoot, check 
http://qt-project.org/groups/qt-contributors-summit-2011/wiki/Qt5ProductDefinition#4582cf86974b397c8f3a2ed2fd502f8c
 to see what we agreed upon back then what the requirements of a 'reference 
platform' and 'Tier 1 platform' are, specifically  that they are in tested by 
the CI system, and are available as alpha, beta, final packages.

windows-7-64-msvc2010, windows-7-64-msvc2010-angle, windows-7-32-mingw-builds 
aren't checked in the CI system right now. Still I think they are important 
enough to deserve an exception, and remain in Tier 1.

I understood that whether we can keep osx-10.6-64 bit as Tier 1 platform for 
qtwebkit is yet unclear.

Finally, I don't know what to do  with the *wayland, *mips, *icc platforms in 
the current version of the page.


Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[Joseph Crowell]

On 11/6/2012 7:52 PM, d3fault wrote:
> You want to obey a randomly declared 'feature-freeze'
It wasn't randomly declared. :D It has been set in stone since around 
May and is standard practice for open source projects near time for a 
stable release usually starting at the first beta release. Otherwise, a 
stable release would never get done. Don't tell me you don't understand why.

> and decline a
> SUPERIOR re-design that can only take place during BC breakages? It's
> not like it'd be that hard to implement. Sure, we're in a feature
> freeze but that's nothing compared to a 'BC promise' that 5 will
> set in stone.
>
> <*insert holy war argument here*>
>
> d3fault
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] CI status update

[Anttila Janne]

I thought it might be good idea to summarize what has been happening on CI 
lately.
So here is summary about CI system changes and some status info from weeks 
44-45:

1. OpenSSL installed to Windows CI testers
-> Auto-detection for configure time check is now true
-> SSL related auto test are build & executed during CI round

2. ICU4C is installed to Windows CI testers
-> WebKit is built on those CI jobs which have webkit dependency
(QtTools, QtQuick1 and QtWebkit demos&examples)
-> Increases webkit testing and reduces problems in release process

3. WebKit mirror taken into use for CI init-repository step
-> Should increase reliability of WebKit fetching

4. Angle based Windows CI stage added for all CI projects
-> Angle based configuration is now being tested, but all projects
 have forcesuccess & qt.tests.insignicant enabled for now

5. Temporarily with qt.tests.insiginifant marked 4.8 CI jobs made enforcing
-> Temporary workaround due to Nokia -> Digia migration removed
-> Still work needed to fix individual insignificant test cases:
 https://bugreports.qt-project.org/browse/QTQAINFRA-574 

6. Test Scheduler taken into use for Qt 4.8 CI
-> 4.8 CI failures reported to Gerrit should be formatted better
-> It is possible to start adding parallel_test attribute for 4.x autotests
-> Possibility to speed-up 4.8 CI round

7. Marked some more CI jobs enforcing
-> QtGraphicalEffects, QtScript and QtWebKit Examples&Demos
-> Autotests were passing, ensure they stay that way

8. SysAdmin repo clean-ups
-> Clean-up for some Nokia specific stuff in puppet configurations

9. Improved rebooting hook taken into use in Jenkins 
-> Some CI failures were suspected to be caused by failing reboot between 
CI jobs 
-> To be followed if this reduces CI failures

10. Possibly jom related errors being studied
-> Made jom installation on Windows machines controlled by Puppet to ease
 changing used jom version
-> Jom was only used in QtBase_master_Integration/win32-msvc2010_Windows_7,
 Jom disabled also on that job until stability problems are solved
-> Tested different jom version on CI development machines, definitely 
working 
 jom version still not found

11. Jenkins server memory configuration updated
-> There were some CI jobs failing due to Jenkins JVM was running OOM
-> Fixed by changing JVM memory configs to "-Xmx1024m -XX:MaxPermSize=256m"
-> In addition more memory added for Virtual Machine running Jenkins

12. CI GIT mirror configuration updated
-> There have been some GIT fetching related CI failures, updated GIT 
   daemon configs on CI mirror should reduce possibility of those failures

13. Simo Fält (CC) joined CI team
-> Simo is currently working to enable Webkit CI in Qt-Project CI system
-> Target: WebKit dependency can be removed from QtTools and QtQuick1 CI
-> RevDep testing for QtTools and QtQuick1 to be performed only when webkit
   is updated

14. xUnit Jenkins plugin installation and usage being studied on development CI
-> Possibly provides better and more visual overview to autotest results

15. More OSX capacity being installed to Digia hosted CI system
-> Macs have been the biggest bottleneck on HW side, with extended capacity
   we prepare for taking the repository branching in use after Qt5 Beta 2

16. QtLocation and QtConnectivity CI is broken due to the fact that their
dependencies were removed from Qt5.git
-> CI uses init-repository script to fetch dependencies listed in 
sync.profile
-> Because Qt5.git does not contain necessary dependencies anymore CI
   fails. Solution under investigation  

Let's see if the CI status update will be something that we will sent out 
regularly,
if not them we will try to keep you updated at least about all big changes in 
CI.

Br,
--
Janne Anttila
Senior Architect - Digia, Qt
Visit us on: http://qt.digia.com 


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5-Beta build from Git on Windows --> Failed to load platform plugin "windows"

[Friedemann Kleint]

Hi,

on Windows XP, the load error is most likely caused by 
https://bugreports.qt-project.org/browse/QTBUG-27741  ,  for which the 
fix https://codereview.qt-project.org/#change,38566 is pending.

Regards,
Friedemann

-- 
Friedemann Kleint
Digia, Qt

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5-Beta build from Git on Windows --> Failed to load platform plugin "windows"

[Koehne Kai]

> -Original Message-
> From: Labs, Torsten [mailto:torsten.l...@siemens.com]
> Sent: Tuesday, November 06, 2012 10:57 AM
> To: Koehne Kai; development@qt-project.org
> Subject: RE: [Development] Qt5-Beta build from Git on Windows --> Failed
> to load platform plugin "windows"
> 
> Hi Kai,
> 
> I got the message that IESHIMS.DLL and WER.DLL is missing. Is that normal?

At least nothing you should worry about:

http://stackoverflow.com/questions/2465111/dependency-walker-reports-ieshims-dll-and-wer-dll-missing

 
Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5-Beta build from Git on Windows --> Failed to load platform plugin "windows"

[Labs, Torsten]

Hi Kai,

I got the message that IESHIMS.DLL and WER.DLL is missing. Is that normal?

Greetings

Torsten 


With best regards,
Torsten Labs

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
Factory Automation
I IA AS FA WF FTH 2
Siemensstr. 2-4
90766 Fuerth, Germany
Tel.: +49 911 978-3682 
mailto:torsten.l...@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; 
Managing Board: Peter Loescher, Chairman, President and Chief Executive 
Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara 
Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; 
Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

-Original Message-
From: Koehne Kai [mailto:kai.koe...@digia.com] 
Sent: Tuesday, November 06, 2012 8:53 AM
To: Labs, Torsten; development@qt-project.org
Subject: RE: [Development] Qt5-Beta build from Git on Windows --> Failed to 
load platform plugin "windows"


> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> Behalf Of Labs, Torsten
> Sent: Tuesday, November 06, 2012 8:47 AM
> To: development@qt-project.org
> Subject: [Development] Qt5-Beta build from Git on Windows --> Failed to
> load platform plugin "windows"
> 
> Hello,
> 
> i compiled Qt on my Windows XP with VS2010 using the qt5_tool -c -u -b
> script. It was working i completed completly.
> 
> But when i start qmlscene.exe he is saying:
> "Failed to load platform plugin "windows" Available platform are:
> minimal
> windows
> 
> If i choose minimal he is saying "This plugin does not support
> propagateSizeHints".

You really want to use the windows plugin. Find out why it doesn't load. 
Depends.exe (Dependency Walker) [1] will help you:
 - load plugins\platforms\windows.dll. Add the path to QTDIR\libs to "Module 
Search Order". Check for missing dependencies (ignoring IESHMS.dll, GPSVC.dll)
 - if this doesn't show anything obvious, depends also allows you to profile an 
actual run. Load your .exe file and click "Profile", "Start Profiling..." 

Regards

Kai

1: http://www.dependencywalker.com/
 
> I want to try Qt5 using Angle from Google to get a proper support for
> OpenGL on Windows. We faced there some problems with Shaders on our
> Notebooks without using Angle.
> 
> Does anybody has an idea?
> 
> Thx
> 
> Torsten
> 
> 
> 
> 
> 
> 
> 
> With best regards,
> Torsten Labs
> 
> Siemens AG
> Industry Sector
> Industry Automation Division
> Industrial Automation Systems
> Factory Automation
> I IA AS FA WF FTH 2
> Siemensstr. 2-4
> 90766 Fuerth, Germany
> Tel.: +49 911 978-3682
> mailto:torsten.l...@siemens.com
> 
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
> Cromme; Managing Board: Peter Loescher, Chairman, President and Chief
> Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser,
> Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen,
> Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial
> registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-
> Reg.-No. DE 23691322
> 
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[d3fault]

You want to obey a randomly declared 'feature-freeze' and decline a
SUPERIOR re-design that can only take place during BC breakages? It's
not like it'd be that hard to implement. Sure, we're in a feature
freeze but that's nothing compared to a 'BC promise' that 5 will
set in stone.

<*insert holy war argument here*>

d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[André Somers]

Op 6-11-2012 10:26, d3fault schreef:
> "a common base class is an interesting idea. But it’s a moot point
> since we have to maintain binary compatibility until Qt 5. So
> QAbstractSocket cannot change. We’ll revisit the issue when Qt 5
> development starts, but that’s a long way in the future". (
> http://blog.qt.digia.com/blog/2008/02/22/qlocalserver-qlocalsocket/#comment-1820
> )
>
> "It won't happen for Qt 5. It's way too late for that". (
> http://lists.qt-project.org/pipermail/development/2012-November/007746.html
> )
>
So, something that was on the list of interesting ideas for 5.0 did not 
get done. So what? There is a long list of ideas that did not make it to 
5.0, simply because nobody bothered to do the work on time, it slipped 
between the cracks, or whatever other reason there might be. There have 
been plenty of warnings of when the development window for 5.0 would 
close, and it even has been re-opened a for a few features that were 
already in progress. But now really is the time to stabilize 5.0, not to 
introduce new stuff. The window is closed.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[d3fault]

"a common base class is an interesting idea. But it’s a moot point
since we have to maintain binary compatibility until Qt 5. So
QAbstractSocket cannot change. We’ll revisit the issue when Qt 5
development starts, but that’s a long way in the future". (
http://blog.qt.digia.com/blog/2008/02/22/qlocalserver-qlocalsocket/#comment-1820
)

"It won't happen for Qt 5. It's way too late for that". (
http://lists.qt-project.org/pipermail/development/2012-November/007746.html
)

d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Qt 4.8.4 release candidates are available

[Jonathan Liu]

On 6/11/2012 2:55 AM, Salovaara Akseli wrote:
> Thank you for notification. SHA-1 c16471dd7aa6ce9b9768e70de66763f73584d880 
> will be in Qt 4.8.4.
changes-4.8.4_RC2 has incorrect reference to QTBUG.
   - QGLTextureGlyphCache: Fix text rendering artifacts on NVIDIA 
[QTBUG-27658]
should be:
   - QGLTextureGlyphCache: Fix text rendering artifacts on NVIDIA 
[QTBUG-26444]

Regards,
Jonathan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5-Beta build from Git on Windows --> Failed to load platform plugin "windows"

[Thiago Macieira]

On terça-feira, 6 de novembro de 2012 07.52.44, Koehne Kai wrote:
> You really want to use the windows plugin. Find out why it doesn't load.
> Depends.exe (Dependency Walker) [1] will help you:
> - load plugins\platforms\windows.dll. Add the path to QTDIR\libs to "Module
> Search Order". Check for missing dependencies (ignoring IESHMS.dll,
> GPSVC.dll)
> - if this doesn't show anything obvious, depends also allows you to profile
> an actual run. Load your .exe file and click "Profile", "Start
> Profiling..."

Another hint: set QT_DEBUG_PLUGINS to 1 in the environment. If loading the
plugin fails, it will tell you why.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development