Re: [Interest] (New?) Warning: Missing Push Notification Entitlement - iOS

[Tor Arne Vestbø]

This is likely Apple's string scanning that's being confused. I'll 
update the part of Qt that may incorrectly trigger this.

tor arne

On 04/09/15 06:23, maitai wrote:
> Same question here...
>
> Le 03-09-2015 23:46, Edward Sutton a écrit :
>
>> I am receiving this also on a recent TestFlight build with Qt 5.5.
>>
>> *Missing Push Notification Entitlement* - Your app appears to
>> include API used to register with the Apple Push Notification service
>>
>> However I had published to the app store in July using Qt 5.5 and had
>> not seen that message.
>> I wonder what the cause is?
>>
>> Dear developer,
>>
>> We have discovered one or more issues with your recent delivery
>> for "TSR Mobile". Your delivery was successful, but you may wish
>> to correct the following issues in your next delivery:
>>
>> *Missing Push Notification Entitlement* - Your app appears to
>> include API used to register with the Apple Push Notification
>> service, but the app signature's entitlements do not include the
>> "aps-environment" entitlement. If your app uses the Apple Push
>> Notification service, make sure your App ID is enabled for Push
>> Notification in the Provisioning Portal, and resubmit after
>> signing your app with a Distribution provisioning profile that
>> includes the "aps-environment" entitlement. See "Provisioning and
>> Development" in the Local and Push Notification Programming Guide
>> 
>> 
>>  for
>> more information. If your app does not use the Apple Push
>> Notification service, no action is required. You may remove the
>> API from future submissions to stop this warning. If you use a
>> third-party framework, you may need to contact the developer for
>> information on removing the API.
>>
>> After you've corrected the issues, you can use Xcode or
>> Application Loader to upload a new binary to iTunes Connect.
>>
>> Regards,
>>
>> The App Store team
>>
>>
>> -Ed
>>
>>
>>
>>
>>> On Sep 3, 2015, at 2:39 PM, Jason H >> > wrote:
>>>
>>> *External Message - use caution*
>>>
>>>
>>> I've been publishing our app to the iOS app store for a while, and I
>>> don't remember seeing this with our previously Qt 5.5.0-compiled
>>> version. We aren't using anything.
>>>
>>> While it is only a warning, I was wondering what changed that might
>>> have brought this on? We aren't using any push notifications at this
>>> time (though I continue to look into it)
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org 
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>> This email and any files transmitted with it from The Charles Machine
>> Works, Inc. are confidential and intended solely for the use of the
>> individual or entity to which they are addressed. If you have received
>> this email in error please notify the sender. Our company accepts no
>> liability for the contents of this email, or for the consequences of
>> any actions taken on the basis of the information provided, unless
>> that information is subsequently confirmed in writing. Please note
>> that any views or opinions presented in this email are solely those of
>> the author and do not necessarily represent those of the company.
>> Finally, the recipient should check this email and any attachments for
>> the presence of viruses. The company accepts no liability for any
>> damage caused by any virus transmitted by this email.
>> ___
>> Interest mailing list
>> Interest@qt-project.org  
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] iOS font rendering.

[Tor Arne Vestbø]

Please report a bug report with a testcase and screenshots of what 
you're seeing.

On 07/09/15 10:49, Igor Mironchik wrote:
> Hi,
>
> I saw that on my iPad font renders very ugly. Application is QWidget-based.
>
> What I have to know about fonts on iOS? How to fix this ugly font?
>
> Thank you.
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt on iOS - Native Swift-Written GUI with Qt Libraries

[Tor Arne Vestbø]

Hi,

This is (should be) possible, just do QT = core in your .pro file. Also, 
possibly create a library instead of an app, and then link the library 
into your native app.

let me know if it doesn't work.

On 03/09/15 07:38, Robert Iakobashvili wrote:
> Gentlemen,
> To overcome various issues and not-nativeness of Qt on iOS,
> I was thinking about the following combination:
>
> 1. Swift-written native GUI;
> 2. Internals supported by Qt-containers, QString, networking, IPC
>  from QtCore, QtNetwork;
>
> Has somebody tried the above combination and any experience
> could be shared like best practices or caveats?
> Thank you.
>
> Regards,
> Robert
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to combine glLineWidth call with Qt3D in QML?

[Björn Breitmeyer]

Hi,

you shouldn't rely on glLineWidth at all. It works only for a very limited 
amount of values, if at all. Its a deprecated feature, if you want thick lines 
you will need to create a triangle strip.

Best regards
Björn Breitmeyer

-- 
Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions 
Am Mittwoch, 9. September 2015, 03:39:10 schrieb Bin Chen:
> Hi, Guys,
> 
> I am evaluating Qt3D with a new project. I wrote a customised Qt3D object
> for loading and displaying triangle mesh lines in 3d scene and wondering
> where I can put in glLineWidth to change the line width.
 
> What I am doing is inheriting from Qt3D::QAbstractMesh, and providing a
> Qt3D::QAbstractMeshFunctorPtr to return Qt3D::QMeshData constructed with
> Qt3D::QMeshData::Lines. 
 
> I can’t find anywhere I can specify the line width in any Qt3D QML objects.
> 
> I know I can achieve that by shaders but I think using glLineWidth is a
> simpler way to do it.
 
> Does Qt3D allow me to specify any OpenGL function calls during rendering for
> a particular object?
 
> Thanks very much!
> 
> Bin Chen
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to combine glLineWidth call with Qt3D in QML?

[Bin Chen]

Thanks Guys,

I will try that. 

Cheers, 


陳斌
Bin Chen

> On 9 Sep 2015, at 6:44 pm, Sean Harmer  wrote:
> 
>> On Wednesday 09 Sep 2015 10:17:13 Björn Breitmeyer wrote:
>> Hi,
>> 
>> you shouldn't rely on glLineWidth at all. It works only for a very limited
>> amount of values, if at all. Its a deprecated feature, if you want thick
>> lines you will need to create a triangle strip.
> 
> Good point. I was thinking about compatibility profile but let's not go 
> there. 
> So yeah creating a triangle strip or even volumetric lines is the way to go 
> for stand alone lines. For lines super imposed upon other geometry you can 
> also use the technique shown in the wireframe example.
> 
> Cheers,
> 
> Sean
> -- 
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
> KDAB (UK) Ltd, a KDAB Group company
> Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
> Mobile: +44 (0)7545 140604
> KDAB - Qt Experts
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to combine glLineWidth call with Qt3D in QML?

[Sean Harmer]

On Wednesday 09 Sep 2015 10:17:13 Björn Breitmeyer wrote:
> Hi,
> 
> you shouldn't rely on glLineWidth at all. It works only for a very limited
> amount of values, if at all. Its a deprecated feature, if you want thick
> lines you will need to create a triangle strip.

Good point. I was thinking about compatibility profile but let's not go there. 
So yeah creating a triangle strip or even volumetric lines is the way to go 
for stand alone lines. For lines super imposed upon other geometry you can 
also use the technique shown in the wireframe example.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to combine glLineWidth call with Qt3D in QML?

[Sean Harmer]

On Wednesday 09 Sep 2015 03:39:10 Bin Chen wrote:
> Hi, Guys,
> 
> I am evaluating Qt3D with a new project. I wrote a customised Qt3D object
> for loading and displaying triangle mesh lines in 3d scene and wondering
> where I can put in glLineWidth to change the line width.
 
> What I am doing is inheriting from Qt3D::QAbstractMesh, and providing a
> Qt3D::QAbstractMeshFunctorPtr to return Qt3D::QMeshData constructed with
> Qt3D::QMeshData::Lines. 
 
> I can’t find anywhere I can specify the line width in any Qt3D QML objects.
> 
> I know I can achieve that by shaders but I think using glLineWidth is a
> simpler way to do it.
 
> Does Qt3D allow me to specify any OpenGL function calls during rendering for
> a particular object?

No, we don't allow arbitrary OpenGL calls to be injected so that we can track 
the state.

We will need to add API for this somewhere to handle this use case. Could you 
file a JIRA for this please?

Thanks,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QCanBusDevice inheritance

[Denis Shienkov]

Benjamin,

I forwarded your message to the mailing list back (you likely forgot to do
it?). Now it could available to comments and for other developers (if you
don't object).

BR,
Denis

2015-09-09 15:46 GMT+03:00 Denis Shienkov :

> Benjamin,
>
> I forwarded your message to the mailing list back (you likely forgot to do
> it?). Now it could available to comments and for other developers (if you
> don't object).
>
> 2015-09-09 11:10 GMT+03:00 Benjamin TERRIER :
>
>> 2015-09-08 19:37 GMT+02:00 Denis Shienkov :
>> > Hi.
>> >
>> > Because QIODevice is inconsistent with the CAN frames. The CAN uses a
>> > minimal entity - frame, which can not be divided to bytes. Besides,
>> > QIODevice's read/write/bytesAvailable methods has not sense, you can not
>> > read/write a half of frame and so on. You can not know a size of frame
>> > to serialize it, because its size is various. And others, others, others
>> > CAN specific reasons. Please, read comments in codereview commits on
>> > gerrit for acquaintance.
>> >
>> > BR,
>> > Denis
>> >
>> > 08.09.2015 18:50, Benjamin TERRIER пишет:
>> >> Hi,
>> >>
>> >> Following the announce of Qt 5.6 Alpha, I checked the brand new
>> >> QCanBusDevice and I've been wondering why the developers did not want
>> >> to use QIODevice (the git logs show that all dependencies have been
>> >> purposely removed).
>> >>
>> >> Cheers,
>> >>
>> >> Benjamin
>> >> ___
>> >> Interest mailing list
>> >> Interest@qt-project.org
>> >> http://lists.qt-project.org/mailman/listinfo/interest
>> >
>> > ___
>> > Interest mailing list
>> > Interest@qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/interest
>>
>> Hi,
>>
>> Thanks for your response but I still don't get why QIODevice has been
>> discarded for CAN while it is used for QUdpSocket.
>>
>> First, frames can always be divided into bytes, there length is an
>> integer multiple of byte. If you are talking about the fact that
>> fields within a frame are not 8 bits longs (identifier can be 11),
>> this should be handled by the underlying CAN library.
>>
>> I also don't get why not knowing the size of a frame can be a problem,
>> UDP datagrams size can vary yet QUdpSocket inherits QIODevice.
>>
>> Finally, QIODevice read/write/bytesAvailable can be given a sense, for
>> instance bytesAvailable could return the sum of the size of all
>> received CAN frames (I do agree it has a limited use but it does not
>> mean it doesn't make sense).
>>
>> My point is a QCanBusDevice is an I/O device and therefore should be a
>> QIODevice as, I quote, "The QIODevice class is the base interface
>> class of all I/O devices in Qt". And the fact that some QIODevice
>> functions are not a perfect fit for CAN should not be a reason not to
>> use it as such cases seems to have been taken into account in the
>> design of the QIODevice class (look at QIODevice::pos(), it is
>> explicitly stated that this function might not make sense).
>>
>> BR,
>>
>> Benjamin
>>
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QCanBusDevice inheritance

[Blasche Alexander]

Hi,


>Thanks for your response but I still don't get why QIODevice has been
>discarded for CAN while it is used for QUdpSocket.

>First, frames can always be divided into bytes, there length is an
>integer multiple of byte. If you are talking about the fact that
>fields within a frame are not 8 bits longs (identifier can be 11),
>this should be handled by the underlying CAN library.

The QIODevice architecture was not a good fit for CAN bus. The API must enable 
the user to interpret the various frames received on the bus. In addition to 
the payload, each frame may come from different sources, has different types 
and other attributes. This means that the API requires at least an abstraction 
on frame level. For each new frame that you send you may adjust the frame 
attributes as well.

This is considerably different from a QIODevice based architecture where you 
generally open a connection to a remote entity and once the connection is 
established you merely keep exchanging payload. After all you don't set a new 
IP for each UDP datagram. There is no requirement to dissect the incoming data 
stream on the backend either. We generally copy the raw data to a socket.

Another inefficiency of the QIODevice approach would be that each frame would 
have to be serialized to a QByteArray on the user API side just to be 
unserialized on the backend side again. I have yet to see a backend API that 
doesn't deal with a frame based API. There is simply nothing gained.

Another argument, the frame based API serves as an input gate. We can make 
assumptions about data format to be send by the API user as the user has to fit 
it into a QCanBusFrame. How should a backend react to an arbitrary data stream 
coming from the user? We have to find all the frame details in it before we 
send it further on. Hence a QIODevice API invites "frame input errors" which is 
not very user friendly.

I hope this helps to understand the reasons for the change.

--
Alex
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Trouble setting stylesheet for widget

[Shinnok]

Hi list,

I'm currently having a lot of trouble setting object specific stylesheet. I'm 
on Qt 5.4.2/OSX 10.10/Creator 3.5.0. The stylesheet is set from Creator -> 
Designer on the object property:

#mainTabWidget::tab {
...
}

 #mainTabWidget::tab:selected
{
}

However this:
#mainTabWidget::tab {

Seems to apply. I don't remember this being the case with stylesheets syntax 
for selectors nor the documentation yields that. This is also not the first 
time I'm touching QSS. Full stylesheet in question 
https://github.com/Tarsnap/tarsnap-gui/blob/master/forms/mainwindow.ui#L76 . 
None of those rules get applied for some reason.

Maybe it's my setup or a Qt toolchain bug. Any idea as to what's going on here?


Regards,
Shinnok
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Trouble setting stylesheet for widget

[Mike Chinander]

For styling named widgets, I thought you needed to use
QWidgetType#Objectname::element { }

In your case:
QTabWidget#mainTabWidget::tab {

}

On Wed, Sep 9, 2015 at 11:14 AM, Shinnok  wrote:

> Hi list,
>
> I'm currently having a lot of trouble setting object specific stylesheet.
> I'm on Qt 5.4.2/OSX 10.10/Creator 3.5.0. The stylesheet is set from Creator
> -> Designer on the object property:
>
> #mainTabWidget::tab {
> ...
> }
>
>  #mainTabWidget::tab:selected
> {
> }
>
> However this:
> #mainTabWidget::tab {
>
> Seems to apply. I don't remember this being the case with stylesheets
> syntax for selectors nor the documentation yields that. This is also not
> the first time I'm touching QSS. Full stylesheet in question
> https://github.com/Tarsnap/tarsnap-gui/blob/master/forms/mainwindow.ui#L76
> . None of those rules get applied for some reason.
>
> Maybe it's my setup or a Qt toolchain bug. Any idea as to what's going on
> here?
>
>
> Regards,
> Shinnok
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QCanBusDevice inheritance

[Benjamin TERRIER]

2015-09-09 15:18 GMT+02:00 Blasche Alexander
:
> Hi,
>
>
>>Thanks for your response but I still don't get why QIODevice has been
>>discarded for CAN while it is used for QUdpSocket.
>
>>First, frames can always be divided into bytes, there length is an
>>integer multiple of byte. If you are talking about the fact that
>>fields within a frame are not 8 bits longs (identifier can be 11),
>>this should be handled by the underlying CAN library.
>
> The QIODevice architecture was not a good fit for CAN bus. The API must
> enable the user to interpret the various frames received on the bus. In
> addition to the payload, each frame may come from different sources, has
> different types and other attributes. This means that the API requires at
> least an abstraction on frame level. For each new frame that you send you
> may adjust the frame attributes as well.

Yes, CAN requires an abstraction on frame level.

> This is considerably different from a QIODevice based architecture where you
> generally open a connection to a remote entity and once the connection is
> established you merely keep exchanging payload. After all you don't set a
> new IP for each UDP datagram. There is no requirement to dissect the
> incoming data stream on the backend either. We generally copy the raw data
> to a socket.

Check:
  qint64 QUdpSocket::writeDatagram(const QByteArray & datagram, const
QHostAddress & host, quint16 port)

You do set a new IP for each UDP datagram.
And as for QUdpSocket you could have enabled a virtual connection
behavior (see last line of QUdpSocket detailed description in Qt
documentation).


>
> Another inefficiency of the QIODevice approach would be that each frame
> would have to be serialized to a QByteArray on the user API side just to be
> unserialized on the backend side again. I have yet to see a backend API that
> doesn't deal with a frame based API. There is simply nothing gained.

I don't get why each frame would have to be serialized if
QCanBusDevice inherits QIODevice. The implementation of
QCanBusDevice::writeFrame() would not change. It would, on the other
hand, require to implement QIODevice::writeData() which would either
call QCanBusDevice::writeFrame() or directly the backend API
effectively doing some "unserialization".



> Another argument, the frame based API serves as an input gate. We can make
> assumptions about data format to be send by the API user as the user has to
> fit it into a QCanBusFrame. How should a backend react to an arbitrary data
> stream coming from the user? We have to find all the frame details in it
> before we send it further on. Hence a QIODevice API invites "frame input
> errors" which is not very user friendly.
>
> I hope this helps to understand the reasons for the change.
>
> --
> Alex
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>

I do agree that the QIODevice API is not a perfect fit for a CAN API
and that it is not user friendly. However, I do think it would have
been better to keep the inheritance using a frame level API as the
main entry point for QCanBusDevice, and the QIODevice API as a
fallback which would rely on the frame level API.
I think it would have been more coherent with the rest of the Qt
framework, particularly when looking at QUdpSocket.

BR,

Benjamin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QCanBusDevice inheritance

[Thiago Macieira]

On Wednesday 09 September 2015 13:18:33 Blasche Alexander wrote:
> The QIODevice architecture was not a good fit for CAN bus. The API must
> enable the user to interpret the various frames received on the bus. In
> addition to the payload, each frame may come from different sources, has
> different types and other attributes. This means that the API requires at
> least an abstraction on frame level. For each new frame that you send you
> may adjust the frame attributes as well.

You're describing QUdpDatagram (https://codereview.qt-project.org/108336), 
which is being added to QUdpSocket.

> After all you don't set a new IP for each UDP datagram. 

You can do it. You don't have to, but you can.

That said, the send/receive datagram functionality bypasses the regular 
QIODevice virtuals and goes straight to the socket engine.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] How to use QStyle.sizeFromContents with QStyleOptionFrame?

[Tony Rietwyk]

Hi Everybody, 

Using Qt 5.5.0 from installed binaries, in my QFrame based custom widget
sizeHint override I want to have: 

QSize contentSize = ;

QStyleOptionFrame optFrame;
initStyleOption();
QSize styleSize = style()->sizeFromContents( QStyle::CT_Frame,
optFrame, contentSize, this );

But of course, CT_Frame doesn't exist!  So how can I make this work?  A
global style sheet is used to produce different frame borders, padding,
background colors, etc.  

Thanks in advance, 

Tony.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] How to improve Qt3D rendering for big mesh?

[Bin Chen]

Hi, guys, 

I am testing Qt3D to render a big triangle mesh,  >1000,000 triangles.
I put all triangles in one QAbstractMesh subclass and added to a QEntity, but 
it is very slow.
Then I separate these triangles into a quadtree and map them into a QEntity 
hierarchy. It became even slower and doesn’t seem to cull nodes:(

I am wondering if I need to compute a QEntity's bounding box myself so the 
framework can cull nodes accordingly.

Any thoughts? 

Thanks very much.

Cheers.

Bin

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Trouble setting stylesheet for widget

[Shinnok]

Mike,

Although not specifically named in the documentation, my approach has worked 
for years and is used by many projects.

However, using that method doesn't yield results either...

Worth mentioning is that the same stylesheet you see in my link has been like 
that since the start of the project and only since upgrading my Qt toolchain 
and Creator the problem has risen and with a delayed effect, after I changed 
something..

Shinnok

> On Sep 9, 2015, at 7:29 PM, Mike Chinander  wrote:
> 
> For styling named widgets, I thought you needed to use 
> QWidgetType#Objectname::element { }
> 
> In your case:
> QTabWidget#mainTabWidget::tab {
> 
> }
> 
> On Wed, Sep 9, 2015 at 11:14 AM, Shinnok  > wrote:
> Hi list,
> 
> I'm currently having a lot of trouble setting object specific stylesheet. I'm 
> on Qt 5.4.2/OSX 10.10/Creator 3.5.0. The stylesheet is set from Creator -> 
> Designer on the object property:
> 
> #mainTabWidget::tab {
> ...
> }
> 
>  #mainTabWidget::tab:selected
> {
> }
> 
> However this:
> #mainTabWidget::tab {
> 
> Seems to apply. I don't remember this being the case with stylesheets syntax 
> for selectors nor the documentation yields that. This is also not the first 
> time I'm touching QSS. Full stylesheet in question 
> https://github.com/Tarsnap/tarsnap-gui/blob/master/forms/mainwindow.ui#L76 
>  
> . None of those rules get applied for some reason.
> 
> Maybe it's my setup or a Qt toolchain bug. Any idea as to what's going on 
> here?
> 
> 
> Regards,
> Shinnok
> ___
> Interest mailing list
> Interest@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/interest 
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest