[Development] How long until clang memory model is ready?
Chris L
hackthegovernment at hotmail.com
Wed Jan 22 19:46:55 CET 2014
I mean to say Code Model, not memory model.
> From: development-request at qt-project.org
> Subject: Development Digest, Vol 28, Issue 84
> To: development at qt-project.org
> Date: Wed, 22 Jan 2014 19:14:49 +0100
>
> Send Development mailing list submissions to
> development at qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.qt-project.org/mailman/listinfo/development
> or, via email, send a message with subject or body 'help' to
> development-request at qt-project.org
>
> You can reach the person managing the list at
> development-owner at qt-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Development digest..."
>
>
> Today's Topics:
>
> 1. Re: QtMultimedia and GStreamer 1.0 (Lopes Yoann)
> 2. Re: QtWebSockets as add-on: current voting status (Kurt Pattyn)
> 3. Re: QtMultimedia and GStreamer 1.0 (Tomasz Olszak)
> 4. Re: QtMultimedia and GStreamer 1.0 (Lopes Yoann)
> 5. Re: How to write a ChangeLog entry (Frederik Gladhorn)
> 6. Re: How to write a ChangeLog entry (Thiago Macieira)
> 7. Re: [QtSerialPort] Add some set of base auto tests
> (Denis Shienkov)
> 8. Re: How long until clang memory model is ready? (Chris L)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 22 Jan 2014 14:05:56 +0000
> From: Lopes Yoann <Yoann.Lopes at digia.com>
> Subject: Re: [Development] QtMultimedia and GStreamer 1.0
> To: Tomasz Olszak <olszak.tomasz at gmail.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID: <0CEE48E2-3D6D-4EC6-8655-BECAD37813C2 at digia.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> On Jan 22, 2014, at 10:07 AM, Tomasz Olszak wrote:
> > Hi.
> >
> > Is gstreamer 1.0 integration planned for 5.3?
> >
>
> Ongoing porting effort is happening in the 'wip/gstreamer-1.0' branch.
>
> It most likely won't make it into Qt before 5.4.
>
> Yoann Lopes
> Senior Software Engineer - Digia, Qt
> Visit us on: http://qt.digia.com
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 22 Jan 2014 15:07:22 +0100
> From: Kurt Pattyn <pattyn.kurt at gmail.com>
> Subject: Re: [Development] QtWebSockets as add-on: current voting
> status
> To: Oswald Buddenhagen <oswald.buddenhagen at digia.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID: <578900D4-15B3-4542-A7C3-38E48F5F7A86 at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> Great, thanks for the effort.
>
> /Kurt
> On 22 Jan 2014, at 11:13, Oswald Buddenhagen <oswald.buddenhagen at digia.com> wrote:
>
> > On Mon, Jan 20, 2014 at 01:15:46PM +0100, Kurt Pattyn wrote:
> >> The majority seems to agree that this should NOT go into the QtNetwork module, but should be an add-on.
> >>
> > the repository was now moved to qt/qtwebsockets.
> > - you need to adjust your git remotes (just edit .git/config)
> > - when you deem it to be in a reasonable state, you need to integrate
> > the repo into qt5.git
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 22 Jan 2014 15:32:15 +0100
> From: Tomasz Olszak <olszak.tomasz at gmail.com>
> Subject: Re: [Development] QtMultimedia and GStreamer 1.0
> To: Lopes Yoann <Yoann.Lopes at digia.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> <CAGuVYzBoWEN4vXi=oXH1cmgGTN=_APPPN3zvJ+xVAAkrrxA+Sw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > Ongoing porting effort is happening in the 'wip/gstreamer-1.0' branch.
> >
> > It most likely won't make it into Qt before 5.4.
>
> I noticed that there was no activity in this branch since end of
> October. Is there any TODO list... what need to be done to merge it
> with dev?
>
> --
> regards,
> Tomasz Olszak
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 22 Jan 2014 14:47:24 +0000
> From: Lopes Yoann <Yoann.Lopes at digia.com>
> Subject: Re: [Development] QtMultimedia and GStreamer 1.0
> To: Tomasz Olszak <olszak.tomasz at gmail.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID: <CB18CC7D-2A45-4BE0-9ABE-86A199B354EC at digia.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Jan 22, 2014, at 3:32 PM, Tomasz Olszak wrote:
>
> I noticed that there was no activity in this branch since end of
> October. Is there any TODO list... what need to be done to merge it
> with dev?
>
>
> Indeed there hasn't been any activity. It currently contains what was started by Ilay and Jim. I haven't had the time to look at what exactly is done and what is not. At least a TODO file should be added to that branch in order to see what's missing (and in case anyone wants to contribute).
>
> It also has to be extensively tested before being merged to dev.
>
> --
> Yoann
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.qt-project.org/pipermail/development/attachments/20140122/a1da069f/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Wed, 22 Jan 2014 15:47:29 +0100
> From: Frederik Gladhorn <frederik.gladhorn at digia.com>
> Subject: Re: [Development] How to write a ChangeLog entry
> To: <development at qt-project.org>
> Message-ID: <7601196.05YD2R37J0 at varney>
> Content-Type: text/plain; charset="us-ascii"
>
> Mandag 20. januar 2014 12.59.49 skrev Thiago Macieira:
> > On segunda-feira, 20 de janeiro de 2014 12:39:04, Thiago Macieira wrote:
> > > Accessibility
> > > -------------
> > >
> > > - On Linux action names were returned as empty strings in AT-SPI
> > >
> > > getActions, now returns the proper names.
> >
> > Should I move this to QtGui? Or to QtWidgets? Or leave?
>
> In this case it is part of QtGui. I don't mind gui or leaving it separate.
> Since it's only one entry maybe gui is the better place.
>
> --
> Best regards,
> Frederik Gladhorn
> Senior Software Engineer - Digia, Qt
> Visit us on: http://qt.digia.com
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 22 Jan 2014 07:38 -0800
> From: Thiago Macieira <thiago.macieira at intel.com>
> Subject: Re: [Development] How to write a ChangeLog entry
> To: development at qt-project.org
> Message-ID: <5576048.lfcoVRSRUR at tjmaciei-mobl2>
> Content-Type: text/plain; charset="us-ascii"
>
> On quarta-feira, 22 de janeiro de 2014 09:26:57, Blasche Alexander wrote:
> > It's the first time that I had to provide a changes file for my modules.
> > Obviously I was a bit too ambitious ;) but yes:
> >
> > qt.gitorious.org/qt/qtconnectivity/blobs/release/dist/changes-5.2.1
>
> Thanks Alex
>
> I'll split the changelog today. Looks like I've captured the changes that
> people talked about so far.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: This is a digitally signed message part.
> Url : http://lists.qt-project.org/pipermail/development/attachments/20140122/5b6d4391/attachment-0001.bin
>
> ------------------------------
>
> Message: 7
> Date: Wed, 22 Jan 2014 22:06:03 +0400
> From: Denis Shienkov <denis.shienkov at gmail.com>
> Subject: Re: [Development] [QtSerialPort] Add some set of base auto
> tests
> To: "development at qt-project.org" <development at qt-project.org>
> Cc: Thiago Macieira <thiago.macieira at intel.com>, Oswald Buddenhagen
> <oswald.buddenhagen at digia.com>
> Message-ID: <52E0088B.4010104 at gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
> > As mentioned on Gerrit before, I was discussing it with Simo, but the
> > problem is really that we neither had anything integrated, nor
> > instructions how to set it up... Those are necessary to get done
> > before requesting any further steps on the CI side.
>
> The short instruction how to setup and configure the "com0com" software
> is here:
>
> https://codereview.qt-project.org/#change,65431
>
> For this purpose it is enough to have a host with any Windows x32.
> Windows x64 doesn't suit for this purpose because "com0com" is delivered
> with unsigned drivers which won't work there.
>
> As a result, the principal thing is the configuring of the CI hosts
> (setup an ENV variables of QTEST_SERIALPORT_SENDER,
> QTEST_SERIALPORT_RECEIVER, and etc.). I don't know how to do it on CI,
> so an help (and some work) from the Digia is necessary, IMHO.
>
>
> Thiago, Oswald, Digia, Others,
>
> what do you think about it? IMHO, it is impossible to delays with this
> issue more (1~2 years it is too long)...
>
> If you agree with passes of names of serial ports to tests through ENV,
> then we can start of implementation a set of the minimal tests (even if
> CI is yet ready). Can you comment it?
>
> Best regards,
> Denis
>
> 16.01.2014 13:26, Laszlo Papp ?????:
> > It had been discussed on this list about 1-2 years ago (if memory
> > serves well), and the common consensus was to use com0com on Windows
> > and some VT alike option on Linux. I do not think the technology
> > changed much, so it is probably still the best option... In my opinion
> > though, the best and easiest option would be socat on Linux. That can
> > elegantly create pseudo terminals for this purpose.
> >
> > I was writing some unit tests last year targeting the replacement of
> > socat internally, but it turned out a bit complex, so I lost
> > motivation. In theory, it would be possible to use an internal "socat"
> > functionality without requiring external dependencies, so the init and
> > tear down would take over the responsibility for this, but it is not
> > that urgent. It is probably not an issue on Linux to setup socat, but
> > I will leave that the decision with the CI contributors.
> >
> > As mentioned on Gerrit before, I was discussing it with Simo, but the
> > problem is really that we neither had anything integrated, nor
> > instructions how to set it up... Those are necessary to get done
> > before requesting any further steps on the CI side.
> >
> > In the long future, my opinion is to get QtMock up to the speed,
> > preferably using the llvm C++ parser (which was not option back then
> > when I thought abut it), and then we could remove all this workaround
> > with a cross-platform solution which is not only useful for
> > QtSerialPort.
> >
> > On Tue, Jan 14, 2014 at 8:14 AM, Denis Shienkov
> > <denis.shienkov at gmail.com> wrote:
> >> Hi developers.
> >>
> >> I want to bring up a question of possibility of addition of some base tests
> >> for QtSerialPort. I understand that it is a complex challenge because for
> >> this purpose is desirable existence of at least two serial ports of devices
> >> which are connected by a Null-modem cable.
> >>
> >> But this problem can be bypassed by use of virtual devices which are
> >> provided with the software of some vendors,
> >> e.g.:
> >>
> >> * on Windows:
> >>
> >> - eltima virtual serial port driver: http://www.eltima.com/products/vspdxp/
> >> - hdd free virtual serial ports:
> >> http://www.hhdsoftware.com/free-virtual-serial-ports
> >> - com0com null modem emulator: http://sourceforge.net/projects/com0com/
> >> and others
> >>
> >> * on Linux:
> >>
> >> - tibbo virtual serial port driver:
> >> http://tibbo.com/downloads/soi/vspdl.html
> >>
> >> So, for a covering of the minimum basic tests I would choose com0com the
> >> project (because free) for windows and tibbo the project (but I yet didn't
> >> use it never) for linux. In this case on CI it is enough to install this
> >> software and to configure it.
> >>
> >> The main feature of tests for QtSerialPort is need of explicit specifying of
> >> names of serial ports for their use. So, our team had an idea to pass these
> >> names (two names at least) to tests through ENV.
> >>
> >> Please see an main ideas example with the tests here:
> >> https://codereview.qt-project.org/#change,65431
> >>
> >> At present behavior of tests such that in case of absence in ENV of the
> >> QTEST_SERIALPORT_SENDER and the QTEST_SERIALPORT_RECEIVER variables any
> >> tests will be skipped/ignored. Otherwise each test will take necessary
> >> device name from the necessary variable and to be executed.
> >>
> >> It allows to use these tests and to developers (for example for me) to make
> >> additional tests that cover the CI tests. Because I can setup as the real
> >> physical serial devices and as other software of the virtual serial devices
> >> (for example from Eltima and so forth), i.e. I have an more flexibility.
> >>
> >> Also it will be useful for other users who have other types of serial ports.
> >> They can execute these tests with the specific types of devices that have.
> >> Also it will be useful to have these tests available even if on CI them
> >> still isn't present because it will give the chance for the end users (or
> >> for developers) to test changes by means of the same test sets.
> >>
> >> Guys, I wait for your comments and sentences about it... Because it is
> >> necessary to solve something, otherwise it is impossible further to continue
> >> to work for the project since complexity increases... :(
> >>
> >> Best regards,
> >> Denis
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Development mailing list
> >> Development at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> >>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 22 Jan 2014 12:14:46 -0600
> From: Chris L <hackthegovernment at hotmail.com>
> Subject: Re: [Development] How long until clang memory model is ready?
> To: "development at qt-project.org" <development at qt-project.org>
> Message-ID: <BLU168-W99436A9248B78D0DFD5D3FA2A70 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
> There are many people out there that want to use Qt Creator not just for Qt applications but also for general c++ cross platform development as well.When you look at the options available in this area there are only a few with the features set that Qt Creator has. Eclipse comes to mind.
> Qt Creator could be, with a few fixed bugs the obvious #1 choice ( if it isn't already ) for general cross platform c++ but it seems like the devs ignore non Qt c++ development.
> Which is a shame since people who use Qt Creator for general c++, but haven't coded Qt before would be more likely to pick Qt once they start shopping for a library. The more people using Qt Creator, the better for Qt.
> I brought up the clang memory model because discussions on the irc channels and old blog entries indicate that there was a plan to use clangs memory model to support the stl's classes in Qt Creator ( unique_ptr, vector, ect... ), once clang's memory model was working correctly, and my question is about when to expect this to happen if ever?
>
> > From: development-request at qt-project.org
> > Subject: Development Digest, Vol 28, Issue 82
> > To: development at qt-project.org
> > Date: Wed, 22 Jan 2014 09:03:01 +0100
> >
> > Send Development mailing list submissions to
> > development at qt-project.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.qt-project.org/mailman/listinfo/development
> > or, via email, send a message with subject or body 'help' to
> > development-request at qt-project.org
> >
> > You can reach the person managing the list at
> > development-owner at qt-project.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Development digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: How long until clang memory model is ready? (Thiago Macieira)
> > 2. QML Image aliasing when animating (Joshua Kolden)
> > 3. Re: QML Image aliasing when animating (Rutledge Shawn)
> > 4. Re: QML Image aliasing when animating (Joshua Kolden)
> > 5. Re: QML Image aliasing when animating (Gunnar Sletta)
> > 6. Re: Remove OSX 10.6 Build? (Ziller Eike)
> > 7. Re: Remove OSX 10.6 Build? (Ziller Eike)
> > 8. Re: Remove OSX 10.6 Build? (Ziller Eike)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 21 Jan 2014 16:03:21 -0800
> > From: Thiago Macieira <thiago.macieira at intel.com>
> > Subject: Re: [Development] How long until clang memory model is ready?
> > To: development at qt-project.org
> > Message-ID: <18596554.AqrLlMcojV at tjmaciei-mobl2>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > On ter?a-feira, 21 de janeiro de 2014 17:39:07, Chris L wrote:
> > > With clang getting complete draft c++14 support, is the memory model
> > > sufficient to move to using it by default? Things like unique_ptr and
> > > vector really need this.
> >
> > What do you mean? We've been officially depending on the C++11 memory model
> > since sometime in Qt 3. The C++98 memory model is incompatible with threads,
> > we were out of it. There was quite a bit of work to fix some of the issues
> > during the Qt 5.0 timeframe.
> >
> > Also, we can't use std::unique_ptr until much later. The Standard Library
> > support is much sketchier than the language support from the compiler. I also
> > don't see a need to use std::unique_ptr at all in Qt code and we don't use
> > std::vector either.
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> > Software Architect - Intel Open Source Technology Center
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: not available
> > Type: application/pgp-signature
> > Size: 190 bytes
> > Desc: This is a digitally signed message part.
> > Url : http://lists.qt-project.org/pipermail/development/attachments/20140121/0ee54eb6/attachment-0001.bin
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 21 Jan 2014 19:03:18 -0800
> > From: Joshua Kolden <joshua at crackcreative.com>
> > Subject: [Development] QML Image aliasing when animating
> > To: development at qt-project.org
> > Message-ID: <57AE9A3A-D962-455F-A41F-CACD8056F293 at crackcreative.com>
> > Content-Type: text/plain; charset=windows-1252
> >
> > I?m getting boxed in with rendering bugs on two fronts. Originally I tried to work with fonts for the following animation, but have both render quality and font ?subfamily? selection bugs to deal with there. So I took the effort to switch a lot of stuff around and use images instead, however I?m getting aliasing artifacts now. I?m rather stuck at the moment for rendering a good quality large font design.
> >
> > This video shows the aliasing I?m talking about. There are 3 images here one is 2048x512 and two are 512x512 for the Camera4 and C4 text logos. The movie is captured pixel for pixel, and the images at their largest (in this example) are smaller then the source resolution.
> >
> > http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality.mov
> >
> > Here is an example of one of the Image invocations:
> >
> > Image {
> > id: c4CameraImage
> > fillMode: Image.PreserveAspectFit
> > source: ?path/to/c4camera.png"
> > anchors.left: parent.left
> > anchors.top: parent.top
> > anchors.bottom: parent.bottom
> > smooth : true
> > opacity: 0.0
> > }
> >
> > The animation is created with a number animation on the width and height of the parent rectangles.
> >
> > I?ve asked on IRC, and in the [interest] list, but one said it should just work and the other didn?t reply.
> >
> > Is this a known issue, a bug, or and I?m I doing it wrong?
> >
> > Thanks,
> > j
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 22 Jan 2014 07:21:28 +0000
> > From: Rutledge Shawn <Shawn.Rutledge at digia.com>
> > Subject: Re: [Development] QML Image aliasing when animating
> > To: Joshua Kolden <joshua at crackcreative.com>
> > Cc: "<development at qt-project.org>" <development at qt-project.org>
> > Message-ID: <DF10430D-7FBE-4D8A-BFA0-9B1236F4EAA7 at digia.com>
> > Content-Type: text/plain; charset="Windows-1252"
> >
> >
> > On 22 Jan 2014, at 4:03 AM, Joshua Kolden wrote:
> >
> > > Image {
> > > id: c4CameraImage
> > > fillMode: Image.PreserveAspectFit
> > > source: ?path/to/c4camera.png"
> > > anchors.left: parent.left
> > > anchors.top: parent.top
> > > anchors.bottom: parent.bottom
> > > smooth : true
> >
> > Did you try antialiasing: true?
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 21 Jan 2014 23:25:50 -0800
> > From: Joshua Kolden <joshua at crackcreative.com>
> > Subject: Re: [Development] QML Image aliasing when animating
> > To: Rutledge Shawn <Shawn.Rutledge at digia.com>
> > Cc: "<development at qt-project.org>" <development at qt-project.org>
> > Message-ID: <5E47AE2F-4778-4B0F-97D3-3341A794F7F6 at crackcreative.com>
> > Content-Type: text/plain; charset=windows-1252
> >
> > Yes, it also has no effect.
> >
> >
> > On Jan 21, 2014, at 11:21 PM, Rutledge Shawn <Shawn.Rutledge at digia.com> wrote:
> >
> > >
> > > On 22 Jan 2014, at 4:03 AM, Joshua Kolden wrote:
> > >
> > >> Image {
> > >> id: c4CameraImage
> > >> fillMode: Image.PreserveAspectFit
> > >> source: ?path/to/c4camera.png"
> > >> anchors.left: parent.left
> > >> anchors.top: parent.top
> > >> anchors.bottom: parent.bottom
> > >> smooth : true
> > >
> > > Did you try antialiasing: true?
> >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Wed, 22 Jan 2014 07:50:38 +0000
> > From: Gunnar Sletta <gunnar.sletta at jolla.com>
> > Subject: Re: [Development] QML Image aliasing when animating
> > To: Joshua Kolden <joshua at crackcreative.com>
> > Cc: "development at qt-project.org" <development at qt-project.org>
> > Message-ID: <5EF03F70-2C0D-4668-9B34-86961177488F at jollamobile.com>
> > Content-Type: text/plain; charset="Windows-1252"
> >
> > This is the expceted result. smooth: true uses bilinear filtering which is what is supported in hardware. When scaling down, this starts to degrade. The effect is drastic for high-contrast content like the edges of a font. Once go get below 0.5x scale factor the sampling starts to ignore pixels and aliasing become very visible.
> >
> > The preferred solution is to prepare raster content (images in your case) close to the size you intend to show them. If you must scale them down, then use mipmapping. With the image element, you can get this by doing:
> >
> > Image {
> > layer.enabled: true
> > layer.smooth: true
> > layer.mipmap: true
> > ...
> > }
> >
> > However, by enabling the layer you get an extra texture copy of your rather large image, so it might be preferable to implement a custom QQuickItem which returns a QSGSimpleTextureNode with a QSGTexture with mipmapping.
> >
> > cheers,
> > Gunnar
> >
> > On 22 Jan 2014, at 04:03, Joshua Kolden <joshua at crackcreative.com> wrote:
> >
> > > I?m getting boxed in with rendering bugs on two fronts. Originally I tried to work with fonts for the following animation, but have both render quality and font ?subfamily? selection bugs to deal with there. So I took the effort to switch a lot of stuff around and use images instead, however I?m getting aliasing artifacts now. I?m rather stuck at the moment for rendering a good quality large font design.
> > >
> > > This video shows the aliasing I?m talking about. There are 3 images here one is 2048x512 and two are 512x512 for the Camera4 and C4 text logos. The movie is captured pixel for pixel, and the images at their largest (in this example) are smaller then the source resolution.
> > >
> > > http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality.mov
> > >
> > > Here is an example of one of the Image invocations:
> > >
> > > Image {
> > > id: c4CameraImage
> > > fillMode: Image.PreserveAspectFit
> > > source: ?path/to/c4camera.png"
> > > anchors.left: parent.left
> > > anchors.top: parent.top
> > > anchors.bottom: parent.bottom
> > > smooth : true
> > > opacity: 0.0
> > > }
> > >
> > > The animation is created with a number animation on the width and height of the parent rectangles.
> > >
> > > I?ve asked on IRC, and in the [interest] list, but one said it should just work and the other didn?t reply.
> > >
> > > Is this a known issue, a bug, or and I?m I doing it wrong?
> > >
> > > Thanks,
> > > j
> > > _______________________________________________
> > > Development mailing list
> > > Development at qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/development
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Wed, 22 Jan 2014 07:51:53 +0000
> > From: Ziller Eike <Eike.Ziller at digia.com>
> > Subject: Re: [Development] Remove OSX 10.6 Build?
> > To: Mohamed Fawzi <Fawzi.Mohamed at digia.com>
> > Cc: Sorvig Morten <Morten.Sorvig at digia.com>,
> > "<development at qt-project.org>" <development at qt-project.org>
> > Message-ID: <7F74D3A7-3D0C-4F60-A229-CE6278B609A6 at digia.com>
> > Content-Type: text/plain; charset="Windows-1252"
> >
> >
> > On Jan 21, 2014, at 3:01 PM, Mohamed Fawzi <Fawzi.Mohamed at digia.com> wrote:
> >
> > >
> > > On 21 Jan 2014, at 14:25, Jake Petroules <jake.petroules at petroules.com>
> > > wrote:
> > >
> > >> On Jan 21, 2014, at 7:36 AM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
> > >>
> > >>> On 21 Jan 2014, at 11:51, Simon Hausmann <simon.hausmann at digia.com> wrote:
> > >>>
> > >>> That depends on how much time we spend releasing Qt :)
> > >>>
> > >>> I realize that if I?m the only one who want?s to keep supporting 10.6 then that?s not going to work. The most important thing to me is to have a somewhat predictable deprecation plan. For example (and at the risk of making this example ?the plan?):
> > >>>
> > >>> 5.3 - Remove support from binary packages.
> > >>> 5.4 - 10.6 support is deprecated.
> > >>> 5.5? - Remove support.
> > >
> > > I also think that it looks reasonable, but I would also find announcing now that 5.4 drops 10.6 support ok (I don't see this big need for "deprecated but still there" if one knows long enough before).
> > > Anyway another thing (with ARC support) is also C++11.
> > > Is it clear when we will begin to require C++11?
> >
> > > Because supporting C++11 in 10.6 is *very* tricky (one might try to ship libc++, but system library will still use libstdc++ and I am not sure if binary compatibility with the version shipped in 10.6 is guaranteed.
> >
> > You can?t compile C++11 code if you use deployment target 10.6 (the Apple tools prevent that), so ?ship libc++? is out of question. The only maybe-possible path would be to use custom GNU libs instead of the Apple-provided ones, but I do not think that we want to support that in any way.
> >
> > ++ Eike
> >
> > > Fawzi
> > >>
> > >> I think this is relatively reasonable. By 5.5 (mid-2015, right?) we will have or almost have OS X 10.11 which is three versions into the OS X free pricing model. Given the fast uptake of OS X Mavericks in just a few short months, by then it seems to me that it will be the ideal time to say goodbye to the last of the Leopards. The gap between Snow Leopard and Lion is also probably the most technically significant between any two recent versions of OS X, so when it's 10.7's time to go we may not even need any code changes.
> > >> [...]
> > >
> > > _______________________________________________
> > > Development mailing list
> > > Development at qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/development
> >
> > --
> > Eike Ziller, Senior Software Engineer - Digia, Qt
> >
> > Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> > Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Tuula Haataja
> > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> >
> >
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Wed, 22 Jan 2014 07:53:23 +0000
> > From: Ziller Eike <Eike.Ziller at digia.com>
> > Subject: Re: [Development] Remove OSX 10.6 Build?
> > To: Sorvig Morten <Morten.Sorvig at digia.com>
> > Cc: "development at qt-project.org" <development at qt-project.org>
> > Message-ID: <FFFFEEBB-4BD5-4566-81E3-AB5744AD50EC at digia.com>
> > Content-Type: text/plain; charset="Windows-1252"
> >
> >
> > On Jan 21, 2014, at 3:15 PM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
> >
> > > On 20 Jan 2014, at 21:21, deDietrich Gabriel <Gabriel.deDietrich at digia.com> wrote:
> > >> The truth is, market share doesn?t mean anything. Point in case: According to the link above, OS X is less than 8% of the total market share. Should we then drop the Mac port completely?
> > >
> > > Good question! Possible arguments for not discontinuing the Mac port:
> > >
> > > - The holistic view. The single platform is not that important, but as a part of a comprehensive platform support package it becomes valuable.
> > > - The 8% OS X users represent a group we want to target.
> > > - We can use the Mac port to make Qt better. Case in point the high-dpi support developed for OS X can be used on Wayland as well.
> >
> > - A good part of the OS X port is useful for the iOS port, and on the smartphone market the numbers are pretty different
> >
> > --
> > Eike Ziller, Senior Software Engineer - Digia, Qt
> >
> > Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> > Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius, Tuula Haataja
> > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> >
> >
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Wed, 22 Jan 2014 08:02:59 +0000
> > From: Ziller Eike <Eike.Ziller at digia.com>
> > Subject: Re: [Development] Remove OSX 10.6 Build?
> > To: Vestbo Tor Arne <tor.arne.vestbo at digia.com>
> > Cc: Sorvig Morten <Morten.Sorvig at digia.com>,
> > "<development at qt-project.org>" <development at qt-project.org>
> > Message-ID: <E567ACC5-63B2-4169-8D9D-F2AF68E8DCB7 at digia.com>
> > Content-Type: text/plain; charset="Windows-1252"
> >
> >
> > On Jan 21, 2014, at 2:56 PM, Tor Arne Vestb? <tor.arne.vestbo at digia.com> wrote:
> >
> > > On 21/01/14 13:36 , Sorvig Morten wrote:
> > >> I realize that if I?m the only one who want?s to keep supporting 10.6
> > >> then that?s not going to work. The most important thing to me is to
> > >> have a somewhat predictable deprecation plan. For example (and at the
> > >> risk of making this example ?the plan?):
> > >>
> > >> 5.3 - Remove support from binary packages. 5.4 - 10.6 support is
> > >> deprecated. 5.5? - Remove support.
> > >
> > > 5.3:
> > >
> > > - Remove support from binary packages
> > > - No CI
> > > = In practice, deprecated, so let's be explicit about it for 5.3
> > >
> > > 5.4
> > >
> > > - Bump the dev branch to 5.4
> > > - Remove 10.6 code as see fit
> > > - Apply 10.6 fixes to 5.3.x (stable) as normal
> > >
> > > The message is "Qt 5.3 deprecates 10.6 support (but is available for
> > > source builds for the lifetime of 5.3), and 5.4 will remove it.?
> >
> > I?d support this plan, and additionally throw in:
> >
> > after 5.3 / Qt Creator 3.2:
> > - drop support for compiling & running Qt Creator on 10.6
> >
> > We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don?t necessarily need to keep ?its IDE? running there (yes, that?s a Qt-centric way of looking at Qt Creator).
> >
> > 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, Tuula Haataja
> > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> >
> > End of Development Digest, Vol 28, Issue 82
> > *******************************************
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.qt-project.org/pipermail/development/attachments/20140122/9993b978/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> End of Development Digest, Vol 28, Issue 84
> *******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140122/414f88f0/attachment.html>
More information about the Development
mailing list