[Development] Qt patches to support AArch64 architecture
Lars: this mail needs your attention. Hi, AArch64 is a new 64-bit ARM architecture, that will be used in a big range of devices, from servers to iPhones. See this Wikipedia article for details: https://en.wikipedia.org/wiki/ARM_architecture#64.2F32-bit_architecture In Debian/Ubuntu, we have been working to enable AArch64 (aka ARM64) support for Qt packages. We would like to forward those patches upstream. Please see https://bugs.debian.org/735488 for the full discussion and https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=200;bug=735488 for the patches. We understand that these patches might be seen as a new feature for Qt4, but the reality is that they will get applied on all distributions wanting to support arm64, so it's better to have them upstreamed. Let me describe the current situation and patches briefly: **Patches already applied in Git**: [qtbase] https://qt.gitorious.org/qt/qtbase/commit/410e9cd5b1a6eb87 (basic detection) [qtscript] https://qt.gitorious.org/qt/qtscript/commit/2e049836ee16f4ae (JavaScriptCore support) **Cherry-pick waiting for approval**: [qt4] https://codereview.qt-project.org/79602 (JavaScriptCore support) **Marcin Juszkiewicz’s patches (licensed under either Public Domain or BSD)**: [qt4] basic-aarch64-detection.patch [done differently to what was done in qtbase] [qt4] mkspecs.patch (mkspecs for qt4) [qtbase and qt4] syscalls.patch (inotify syscalls numbers) **Mark Salter’s patch (licensed under BSD)**: [qt4] qatomic.patch (atomics for qt4) The first issue comes with Marcin’s and Mark’s patches. They are RedHat employees, and they cannot sign the CLA. So we asked them to put the patches under a license which could enable us to merge the patches upstream. Marcin agreed to license his patches under CC0 (aka Public Domain) or simply BSD licensed [0], and Mark under the BSD license [1]. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735488#179 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735488#195 The second issue is that Qt may require, only for arm64, -fpermissive to build. This could mean that something is not really finished, but it will get certainly ironed out with some time. Finally we Debian maintainers are not able to verify the patches ourselves *yet*, as we don’t have access to porterboxes. So far only Debian arm64 porters have access. Non the less, patches are already applied in Ubuntu (and most probably Red Hat too, as the patches come from them), and the current Qt 4 packages built fine there. If you want testers for the patches, try asking Marcin or Wookey (CCed), they should be able to help you. I am going to submit the missing patches to Gerrit if you have nothing against that. Kind regards, -- Dmitry Shachnev (on behalf on Debian Qt maintainers) signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Harmonizing the Qt 5.x Documentation
> Em ter 11 mar 2014, às 17:17:46, Andre Somers escreveu: > > I seriously don't see the benefit of this "harmonization". When I look > > at the docs for a class, I often just look for method names that seem to > > do what I need. That usually works very with Qt. Now, I will need to go > > check for every method if it actually exists in the version of Qt I'm > > on, by looking for a "since" tag. How is that helping me to become more > > productive? > > If you want to be productive with the exact docs for the version you're using > and full, indexed text search, you should use Qt Assistant or the integrated > Help in Qt Creator. And as Jerome pointed out, the Qt 5.0 and 5.1 docs will be on doc.qt.digia.com too so they won't be completely gone from the web. I am all for the idea and I am having to look up the older documentation for various reasons all the time. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Harmonizing the Qt 5.x Documentation
Em ter 11 mar 2014, às 17:17:46, Andre Somers escreveu: > I seriously don't see the benefit of this "harmonization". When I look > at the docs for a class, I often just look for method names that seem to > do what I need. That usually works very with Qt. Now, I will need to go > check for every method if it actually exists in the version of Qt I'm > on, by looking for a "since" tag. How is that helping me to become more > productive? If you want to be productive with the exact docs for the version you're using and full, indexed text search, you should use Qt Assistant or the integrated Help in Qt Creator. -- 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
Re: [Development] Harmonizing the Qt 5.x Documentation
Em ter 11 mar 2014, às 12:35:02, haithem rahmani escreveu: > The Qt-5.2 has deprecated, added many APIs and attributes compared to > Qt-5.1 and till new the documentation doesn't completely reflect that. > Would this be fixed? Additions are documented along with the version they were added. -- 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
Re: [Development] Harmonizing the Qt 5.x Documentation
Matthew Woehlke schreef op 11-3-2014 17:04: > On 2014-03-11 05:01, Pasion Jerome wrote: >> Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1 >> documentation >> to "Qt 5" documentation. Subsequently, we will remove the 5.0 and 5.1 >> documentation >> from qt-project.org and we will place future Qt 5.x documentation in >> "Qt 5" (http://qt-project.org/doc/qt-5/). > How am I then supposed to find the 5.x documentation if I am developing > an application against 5.x but the latest release is 5.y? > > It's common practice to keep old documentation available so that users > can have a correct view of the state of the software /as of the version > they are using/. If you don't do this, you *MUST* accurately document > every *change* (not just additions) between versions and have that > documentation clearly visible in the documentation of the affected > classes/methods/etc. (Plus, I know from experience that \since is easily > overlooked.) Indeed. It seems like a Bad Idea(TM) to me. > >> People looking into the Qt 5 documentation will likely encounter the >> 5.0 version. Harmonizing the directories into one means that online >> viewers will always view the latest Qt 5 documentation. > That can be solved easily by having /doc/qt-5/ symlinked on the server > to the latest 5.x. > > I would also encourage doing like python.org and adding a widget to > select the documentation version. You could also add a big noisy warning > to the historic documentation pages. > >> B)Multiple directories hinders the search results. A single directory for Qt >> 5 >> documentation increases traffic to the /doc/qt-5/ directory. Currently, >> the /doc/qt-5.1 and /doc/qt-5.0 directories are taking away viewers from the >> main Qt 5 content. > So don't allow these to be indexed? I know there are ways to tell search > engines to not index certain pages... That would suck too... As the on-site search for the docs is quite bad, I resort to using the Qt Doc Search extension for Chrome to search for documentation with the right version. That works quite well, but would break if either the old docs are removed they are not allowed to be indexed any more. I seriously don't see the benefit of this "harmonization". When I look at the docs for a class, I often just look for method names that seem to do what I need. That usually works very with Qt. Now, I will need to go check for every method if it actually exists in the version of Qt I'm on, by looking for a "since" tag. How is that helping me to become more productive? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Harmonizing the Qt 5.x Documentation
On 2014-03-11 05:01, Pasion Jerome wrote: > Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1 > documentation > to "Qt 5" documentation. Subsequently, we will remove the 5.0 and 5.1 > documentation > from qt-project.org and we will place future Qt 5.x documentation in > "Qt 5" (http://qt-project.org/doc/qt-5/). How am I then supposed to find the 5.x documentation if I am developing an application against 5.x but the latest release is 5.y? It's common practice to keep old documentation available so that users can have a correct view of the state of the software /as of the version they are using/. If you don't do this, you *MUST* accurately document every *change* (not just additions) between versions and have that documentation clearly visible in the documentation of the affected classes/methods/etc. (Plus, I know from experience that \since is easily overlooked.) > People looking into the Qt 5 documentation will likely encounter the > 5.0 version. Harmonizing the directories into one means that online > viewers will always view the latest Qt 5 documentation. That can be solved easily by having /doc/qt-5/ symlinked on the server to the latest 5.x. I would also encourage doing like python.org and adding a widget to select the documentation version. You could also add a big noisy warning to the historic documentation pages. > B)Multiple directories hinders the search results. A single directory for Qt 5 > documentation increases traffic to the /doc/qt-5/ directory. Currently, > the /doc/qt-5.1 and /doc/qt-5.0 directories are taking away viewers from the > main Qt 5 content. So don't allow these to be indexed? I know there are ways to tell search engines to not index certain pages... -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem with QOpenGLContext?
Will this patch work? https://codereview.qt-project.org/#change,80620 Morten On 11 Mar 2014, at 12:12, Kurt Pattyn wrote: > Some more information. > > I work on OSX. > When digging into the platform specific implementation, I detected that in > the method qcgl_createNSOpenGLPixelFormat() > the color depth nor the alpha depth is not set. If it is not set, it defaults > to the screen color depth, which is 8-bit in my case. > I will file a bug report for that. > > Cheers, > > Kurt > > On 11 Mar 2014, at 11:28, Kurt Pattyn wrote: > >> Hi, >> >> as I understand correctly the ‘old’ QGLxxx classes will be replaced by new >> QOpenGLxxx classes. >> I tried the following code below, and found out that QGLContext is correctly >> setting the color depth, >> while QOpenGLContext always defaults to 8. >> >> QSurfaceFormat ogfrmt; >> ogfrmt.setRedBufferSize(6); >> ogfrmt.setGreenBufferSize(6); >> ogfrmt.setBlueBufferSize(6); >> QOpenGLContext *oglc = new QOpenGLContext; >> oglc->setFormat(ogfrmt); >> oglc->create(); >> qDebug() << "QOpenGLContext red buffer size:" << >> oglc->format().redBufferSize(); >> >> QGLFormat gfrmt; >> gfrmt.setRedBufferSize(6); >> gfrmt.setBlueBufferSize(6); >> gfrmt.setGreenBufferSize(6); >> QGLContext *glc = new QGLContext(gfrmt); >> glc->create(); >> qDebug() << "QGLContext red buffer size:" << >> glc->format().redBufferSize(); >> >> >> Is this a known bug, or is the above code simply wrong? >> >> Cheers, >> >> Kurt > > ___ > 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] Problem with QOpenGLContext?
Hi Morten, I reviewed the patch (no, it won’t work). Accidentally I already submitted a (working) patch: https://codereview.qt-project.org/#change,80610 Cheers, Kurt On 11 Mar 2014, at 15:00, Sorvig Morten wrote: > Will this patch work? > > https://codereview.qt-project.org/#change,80620 > > Morten > > > On 11 Mar 2014, at 12:12, Kurt Pattyn wrote: > >> Some more information. >> >> I work on OSX. >> When digging into the platform specific implementation, I detected that in >> the method qcgl_createNSOpenGLPixelFormat() >> the color depth nor the alpha depth is not set. If it is not set, it >> defaults to the screen color depth, which is 8-bit in my case. >> I will file a bug report for that. >> >> Cheers, >> >> Kurt >> >> On 11 Mar 2014, at 11:28, Kurt Pattyn wrote: >> >>> Hi, >>> >>> as I understand correctly the ‘old’ QGLxxx classes will be replaced by new >>> QOpenGLxxx classes. >>> I tried the following code below, and found out that QGLContext is >>> correctly setting the color depth, >>> while QOpenGLContext always defaults to 8. >>> >>>QSurfaceFormat ogfrmt; >>>ogfrmt.setRedBufferSize(6); >>>ogfrmt.setGreenBufferSize(6); >>>ogfrmt.setBlueBufferSize(6); >>>QOpenGLContext *oglc = new QOpenGLContext; >>>oglc->setFormat(ogfrmt); >>>oglc->create(); >>>qDebug() << "QOpenGLContext red buffer size:" << >>> oglc->format().redBufferSize(); >>> >>>QGLFormat gfrmt; >>>gfrmt.setRedBufferSize(6); >>>gfrmt.setBlueBufferSize(6); >>>gfrmt.setGreenBufferSize(6); >>>QGLContext *glc = new QGLContext(gfrmt); >>>glc->create(); >>>qDebug() << "QGLContext red buffer size:" << >>> glc->format().redBufferSize(); >>> >>> >>> Is this a known bug, or is the above code simply wrong? >>> >>> Cheers, >>> >>> Kurt >> >> ___ >> 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] New snapshot build from Qt 4.8.6 available
Please consider this change too: https://codereview.qt-project.org/#change,77496 Thanks, David ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Harmonizing the Qt 5.x Documentation
> > > Message: 1 > Date: Tue, 11 Mar 2014 11:06:21 +0100 > From: Tomasz Siekierda > Subject: Re: [Development] Harmonizing the Qt 5.x Documentation > To: Pasion Jerome > Cc: "development@qt-project.org" , > "inter...@qt-project.org" , > "w...@qt-project.org" > Message-ID: > < > cajb_605w2atz9jiyyozw5crlqwpqwigwrxq+ttefenn1tkr...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 11 March 2014 10:01, Pasion Jerome wrote: > > Hello all, > > > > Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1 > > documentation > > to "Qt 5" documentation. Subsequently, we will remove the 5.0 and 5.1 > > documentation > > from qt-project.org and we will place future Qt 5.x documentation in > > "Qt 5" (http://qt-project.org/doc/qt-5/). > > Nothing much to say, apart from a +1 from me. > + 0.75 The Qt-5.2 has deprecated, added many APIs and attributes compared to Qt-5.1 and till new the documentation doesn't completely reflect that. Would this be fixed? Or this is just to force Qt5 users to move to the latest version :)? regards Haithem. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem with QOpenGLContext?
Some more information. I work on OSX. When digging into the platform specific implementation, I detected that in the method qcgl_createNSOpenGLPixelFormat() the color depth nor the alpha depth is not set. If it is not set, it defaults to the screen color depth, which is 8-bit in my case. I will file a bug report for that. Cheers, Kurt On 11 Mar 2014, at 11:28, Kurt Pattyn wrote: > Hi, > > as I understand correctly the ‘old’ QGLxxx classes will be replaced by new > QOpenGLxxx classes. > I tried the following code below, and found out that QGLContext is correctly > setting the color depth, > while QOpenGLContext always defaults to 8. > > QSurfaceFormat ogfrmt; > ogfrmt.setRedBufferSize(6); > ogfrmt.setGreenBufferSize(6); > ogfrmt.setBlueBufferSize(6); > QOpenGLContext *oglc = new QOpenGLContext; > oglc->setFormat(ogfrmt); > oglc->create(); > qDebug() << "QOpenGLContext red buffer size:" << > oglc->format().redBufferSize(); > > QGLFormat gfrmt; > gfrmt.setRedBufferSize(6); > gfrmt.setBlueBufferSize(6); > gfrmt.setGreenBufferSize(6); > QGLContext *glc = new QGLContext(gfrmt); > glc->create(); > qDebug() << "QGLContext red buffer size:" << > glc->format().redBufferSize(); > > > Is this a known bug, or is the above code simply wrong? > > Cheers, > > Kurt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Problem with QOpenGLContext?
Hi, as I understand correctly the ‘old’ QGLxxx classes will be replaced by new QOpenGLxxx classes. I tried the following code below, and found out that QGLContext is correctly setting the color depth, while QOpenGLContext always defaults to 8. QSurfaceFormat ogfrmt; ogfrmt.setRedBufferSize(6); ogfrmt.setGreenBufferSize(6); ogfrmt.setBlueBufferSize(6); QOpenGLContext *oglc = new QOpenGLContext; oglc->setFormat(ogfrmt); oglc->create(); qDebug() << "QOpenGLContext red buffer size:" << oglc->format().redBufferSize(); QGLFormat gfrmt; gfrmt.setRedBufferSize(6); gfrmt.setBlueBufferSize(6); gfrmt.setGreenBufferSize(6); QGLContext *glc = new QGLContext(gfrmt); glc->create(); qDebug() << "QGLContext red buffer size:" << glc->format().redBufferSize(); Is this a known bug, or is the above code simply wrong? Cheers, Kurt___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Harmonizing the Qt 5.x Documentation
On 11 March 2014 10:01, Pasion Jerome wrote: > Hello all, > > Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1 > documentation > to "Qt 5" documentation. Subsequently, we will remove the 5.0 and 5.1 > documentation > from qt-project.org and we will place future Qt 5.x documentation in > "Qt 5" (http://qt-project.org/doc/qt-5/). Nothing much to say, apart from a +1 from me. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About ALIAS in Q_PROPERTY
If you have 10 properties, you only need to call initAliasNotify to connect all. 2014-03-11 14:59 GMT+06:00 André Somers : > Svetkin Mikhail schreef op 11-3-2014 04:12: > > Explain: > I was creating custom widgets with the help of Qt-designer. > And I have noticed I have to duplicate my code, if I want to edit > properties of the widget in qt-designer property editor. > Simple Example: > > I'm not a fan. You end up with a QProperty, but without actual accessor > functions to call. I also think that's what's wrong with the MEMBER version > we have now too, by the way. Also, the need to call initAliasNotify doesn't > appeal to me. What's the benefit over making the connect between the two > signals myself? > > André > > ___ > 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] Harmonizing the Qt 5.x Documentation
Hello all, Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1 documentation to "Qt 5" documentation. Subsequently, we will remove the 5.0 and 5.1 documentation from qt-project.org and we will place future Qt 5.x documentation in "Qt 5" (http://qt-project.org/doc/qt-5/). Note that the Qt 4.7, Qt 4.8, and Qt Creator Manual are not part of this change. Why are we doing this? Because, overall, it is easier to move the documentation as-a-product forward. But to be specific: A)When Qt 5.0 was released, much of the documentation such as pages and snippets were missing and were fixed for the Qt 5.1 release. People looking into the Qt 5 documentation will likely encounter the 5.0 version. Harmonizing the directories into one means that online viewers will always view the latest Qt 5 documentation. B)Multiple directories hinders the search results. A single directory for Qt 5 documentation increases traffic to the /doc/qt-5/ directory. Currently, the /doc/qt-5.1 and /doc/qt-5.0 directories are taking away viewers from the main Qt 5 content. Some Practicalities: -We need to be stricter with filename changes to minimize readers viewing non-existing pages. The Qt Writing Guidelines and QDoc already dictate the filenames for important pages, but overview and article authors should minimize filename changes. -It is even more important to make sure that the API has the correct QDoc commands and markup. API should have the \since and once needed, the \deprecated, and \obsolete commands. -I checked the doc notes database and there are only a handful of doc notes for both 5.0 and 5.1. It is likely that they will not be ported over. -The 5.0 and 5.1 HTML files will be hosted in doc.qt.digia.com. Regardless, they will always be available when downloading the packages. The exact timeline is not decided yet, but the redirects are being tested internally now and we hope to deploy them before the Qt 5.3 final release. Cheers, Jerome P. Documentation Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About ALIAS in Q_PROPERTY
Svetkin Mikhail schreef op 11-3-2014 04:12: Explain: I was creating custom widgets with the help of Qt-designer. And I have noticed I have to duplicate my code, if I want to edit properties of the widget in qt-designer property editor. Simple Example: I'm not a fan. You end up with a QProperty, but without actual accessor functions to call. I also think that's what's wrong with the MEMBER version we have now too, by the way. Also, the need to call initAliasNotify doesn't appeal to me. What's the benefit over making the connect between the two signals myself? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
