Re: [Development] Platform / compiler support
Dr Craig Scott wrote: On 08/11/2011, at 1:31 AM, João Abecasis wrote: At the bare minimum, I think we should strive to support these compilers: - GCC 4.2 and up - MSVC 2008 and later - Clang (trunk) On the page above I also put in a list of platforms, splitting them between Desktop, Embedded and Mobile. The latter two categories only have a placeholder row, while for Desktop I put in the following platform-compiler mappings: - Linux: gcc 4.4 (Debian stable) - Microsoft Windows 7: MSVC 2008 - Mac OS X Lion: gcc 4.2, clang 2.9 I would strongly suggest that the LSB makes an appearance somewhere in the supported platform/compiler listing. To my knowledge, it is the only truly cross-distribution standard that exists for Linux. Does the LSB specify a compiler? Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
Thiago: Configure-time tests are very hard to write for Qt. Just compile something that is dependent upon the compiler features. If TestForVariadcMacros.cpp fails to compile, the user will probably figure it out! ;-) Atlant -Original Message- From: development-bounces+aschmidt=dekaresearch@qt-project.org [mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On Behalf Of Thiago Macieira Sent: Tuesday, November 08, 2011 07:27 To: development@qt-project.org Subject: Re: [Development] Platform / compiler support On Tuesday, 8 de November de 2011 06:39:23 Atlant Schmidt wrote: When you settle on the set of enhanced features that compilers must support to allow use with Qt, please design, as the VERY FIRST PORTIONS of the Qt build procedure, a small series of programs that deliberately test for and stress those features. Configure-time tests are very hard to write for Qt. I doubt we'll do this... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
Hey João, On 11/7/11 4:31 PM, ext João Abecasis joao.abeca...@nokia.com wrote: To bootstrap the discussion I started a wiki page with a short list of suggested supported compilers and platforms for Qt 5: http://wiki.qt-project.org/Supported_Platforms Cool! We should merge that with http://developer.qt.nokia.com/wiki/Qt_5.0, which linked from the Qt Roadmap pages at Qt Developer Network. I'm not sure which wiki would be the best location. The platform list on that Qt_5.0 wiki page is not in a sane state, so thanks for restarting the discussion! It'd be nice to have a list of reference platforms and even better if such platforms had maintainers who'd provide testing results, help fix issues and generally ensure the platforms are in a working state. Supporting a platform may also have implications on the release process. Anyway, all of that is a bigger discussion. Some discussion from QtCS in Berlin is documented here: http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5Product Definition#4582cf86974b397c8f3a2ed2fd502f8c I should probably move this page to the Qt Project wiki. Cheers, Henry ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
Friedemann Kleint wrote: Well, so far, no compiler has been suggested that doesn't support variadic macros :-) MSVC2010 does not support that (see b256d7b3bbe5ff6d3405255f0077e6b9635c8e7e in qtbase). Not all the world is g++ ;-) . MSVC actually supports variadic macros starting from VS 2005: http://msdn.microsoft.com/en-us/library/ms177415(v=vs.80).aspx Possibly not all gcc extensions to that are supported, but that's a different issue. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
On Tuesday 8. November 2011 14.20.35 ext Atlant Schmidt wrote: Thiago: Configure-time tests are very hard to write for Qt. Just compile something that is dependent upon the compiler features. If TestForVariadcMacros.cpp fails to compile, the user will probably figure it out! ;-) Atlant It is not so easy. Qt itself sometimes have different compiler setting then application that use Qt. It is possible that some feature are available during Qt configure phase but not during Qt application compilation. Good example are variadic macros in a public header. By default GCC would compile them, without any warning. But compilation, with options --Wall -- Werror --std=C++98, of an application including the header, would fail. So again, we have problem of features used in headers / implementation. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
On Tuesday, 8 de November de 2011 05:43:52 Charley Bay wrote: Atlant spaketh: When you settle on the set of enhanced features that compilers must support to allow use with Qt, please design, as the VERY FIRST PORTIONS of the Qt build procedure, a small series of programs that deliberately test for and stress those features. Thiago respondeth: Configure-time tests are very hard to write for Qt. I doubt we'll do this... I'm working on some static analysis tools for source files using Qt. What would these compiler-features-tests look like? Anything. There's no form. You need to make it compile and produce a valid result when running the Unix configure script. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] API review for a new QDnsResolver class
On 11/04/2011 09:37 PM, Thiago Macieira wrote: On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote: Me too. My point was, that we have slightly different patters for basically the same sort of thing in different places in Qt. QFuture is currently coupled with QtConcurrent, but is there a strong reason why is must be? I was not privy to that IRC chat, perhaps you could tell us the reasoning why it would not be possible? There's no reason why it has to be coupled with Concurrent. Or, to put in other words, it could be changed to work without Concurrent. However, the problem is, it is currently too tightly coupled with QtConcurrent. Unless someone is volunteering to do this work right now... OK so to sum up: - the QNAM-style API seems to be OK - I have implemented QDnsReply::abort() to cancel a lookup request - Robin mentioned adding a static QDnsResolver::instance() method, does anyone else have an opinion on this? - concerning QDnsReply ownership: * using QSharedPointerQDnsReply doesn't really help, it breaks QNAM expectations by making the user needs to hold an explicit reference to the reply * QFuture would be interesting, but it won't be split from QtConcurrent in the foreseable future * as a fallback I propose we stick with the same reply ownership model as QNAM (i.e. the reply is initially owned by the QDnsResolver, but the user can use setParent), it has the advantage of being well-known Unless there are any objections I will push the reworked QDnsResolver to gerrit. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Exposing QScreen API to QML
On 11/7/11 9:21 AM, ext Alan Alpert alan.alp...@nokia.com wrote:
On Wed, 2 Nov 2011 18:03:21 ext Samuel Rødal wrote:
Hello,
I'm one of the guys who have been working on the Lighthouse API changes
for Qt 5 and new Qt 5 APIs like QWindow and QScreen. For those who are
not familiar, QWindow is the low-level Qt abstraction of a native window
that has its own rendering surface (native means whatever the Lighthouse
platform plugin provides, ie with the minimal plugin native currently
means a QImage backing store that simply gets saved as images to disk).
The QWidget stack and the scene graph both use QWindow as the
abstraction to get input and to get content onto the screen.
QScreen provides a way to query information (like geometry, dpi,
orientation, etc) about screens, and to move a window to a certain
screen with QWindow::setScreen(). QGuiApplication provides screens()
which returns a list of all the available screens, primaryScreen() which
returns the default screen, as well as the screenAdded() signal when a
new screen is connected. The QScreen header can be seen here:
https://qt.gitorious.org/qt/qtbase/blobs/master/src/gui/kernel/qscreen.h
Looking at the QScreen header, would all of these properties really be
constant? virtualSize and availableVirtualGeometry sound like they could
change easily, as could logical size. If they can change, they'll need
NOTIFY
signals so that th bindings and update.
Currently we're trying to find a nice way to expose the QScreen API to
QML. The obvious way of exposing the QGuiApplication properties /
signals as Qt.application.screens, Qt.application.primaryScreen, and
Qt.application.screenAdded doesn't work too well unfortunately, since
there's no way of finding out which screen the QQuickView belongs to
from QML, and the screen list is useless as there's no way to control
which screen you're on from QML at the moment. We could limit ourselves
to only allowing a single declarative context to only be associated with
one screen, but that prevents future use cases like controlling the UI
for both the main display and the external display from a single QML
file, which might be useful in for example presentation tools or video
players / gallery viewers where the main display shows some controls
that are not shown on the external display. In the future we might want
to support these use cases as well as better support desktop
applications by having a Window item or similar to be able to explicitly
create new top-level windows from QML (a similar feature is already
exposed in QML desktop components, but it sounds like it would be useful
to have a generic abstraction in the QML core).
When you say QML core, you mean this should go in the QtQuick module? Or
into
the engine, and be available without an import statement? The QtQuick
module
is my preference.
Any API for accessing screens should be in the QtQuick module. The engine
itself shouldn't really contain anything tied to Gui.
My first guess is that it would need to hook into QQuickCanvas to easily
find
its QWindow* (for screen()) and to be notified of screen changes. That
could
affect where it can be placed. But if they're all in the QtDeclarative
library
then it's quite easy for it to work closely with the canvas to achieve
this.
Anyway, in the meantime the most future proof approach seems to be to
tie the screen information to an Item, instead of making it a global
property. The two approaches we're currently looking at is having a
ScreenInfo element, or using attached properties to dynamically insert a
Screen object with corresponding properties on demand.
Here's some example code for the two approaches:
Rectangle {
ScreenInfo {
id: screenInfo
onCurrentOrientationChanged: {
// do animation ...
}
}
width: 4.0 * screenInfo.physicalDotsPerInchX
height: 4.0 * screenInfo.physicalDotsPerInchY
}
Alternatively, with the attached property:
Rectangle {
width: 4.0 * Screen.physicalDotsPerInchX
height: 4.0 * Screen.physicalDotsPerInchY
Screen.onCurrentOrientationChanged: {
// do animation ...
}
}
The latter has less syntax, but it might be easier to create multiple
Screen objects. A way to solve that can be to compute the desired scale
factors etc once in a single element, and then re-use those factors in
child elements without accessing Screen directly.
I like the idea of the attached object, it's a cleaner looking API and
the
docs can explain the performance implications.
I'm not too fond of this. The reason is that I'd rather explicitly create
surfaces on a screen, than magically attach items in an existing view to a
screen.
I'll explain more in the thread about Window {}.
Another question is whether the x and y DPI should be easily accessed by
a property that simply averages the two (square or mostly square pixels
Re: [Development] Platform / compiler support
On 11/8/11 11:25 AM, ext Thiago Macieira thiago.macie...@intel.com wrote: On Tuesday, 8 de November de 2011 11:08:04 João Abecasis wrote: Thiago Macieira wrote: In reality, we won't have a major creep in of features, but over time it could happen. Imagine a Q_DECLARE_METATYPE with variadic macros to solve the problem of the comma in templates. As soon as people start using that in their code, which would be soon, a C99 preprocessor is mandatory. Well, so far, no compiler has been suggested that doesn't support variadic macros :-) Which is good. I'm not against variadic macros. I just want to make it a conscious decision. Yes. Making conscious and informed decisions about these things is IMO exactly the point of the discussion here. The problem is that we don't know which platforms Qt will be ported to in the future. So we will need to scan the list of platforms/compilers that are currently interesting and make an educated and conscious decision on whether we want to leave out a certain platform or compiler. MSVC6 or WINSCW are examples of compilers I would say we consciously decide to never support. Things like whether to rely on variadic macros in Qt can not be decided without doing some research on current compilers and what they accept/support. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Exposing QScreen API to QML
On 11/07/2011 09:21 AM, ext Alan Alpert wrote: On Wed, 2 Nov 2011 18:03:21 ext Samuel Rødal wrote: Hello, I'm one of the guys who have been working on the Lighthouse API changes for Qt 5 and new Qt 5 APIs like QWindow and QScreen. For those who are not familiar, QWindow is the low-level Qt abstraction of a native window that has its own rendering surface (native means whatever the Lighthouse platform plugin provides, ie with the minimal plugin native currently means a QImage backing store that simply gets saved as images to disk). The QWidget stack and the scene graph both use QWindow as the abstraction to get input and to get content onto the screen. QScreen provides a way to query information (like geometry, dpi, orientation, etc) about screens, and to move a window to a certain screen with QWindow::setScreen(). QGuiApplication provides screens() which returns a list of all the available screens, primaryScreen() which returns the default screen, as well as the screenAdded() signal when a new screen is connected. The QScreen header can be seen here: https://qt.gitorious.org/qt/qtbase/blobs/master/src/gui/kernel/qscreen.h Looking at the QScreen header, would all of these properties really be constant? virtualSize and availableVirtualGeometry sound like they could change easily, as could logical size. If they can change, they'll need NOTIFY signals so that th bindings and update. True, looking at QWindowSystemInterface it seems they can change. I'll change them to be NOTIFY. Currently we're trying to find a nice way to expose the QScreen API to QML. The obvious way of exposing the QGuiApplication properties / signals as Qt.application.screens, Qt.application.primaryScreen, and Qt.application.screenAdded doesn't work too well unfortunately, since there's no way of finding out which screen the QQuickView belongs to from QML, and the screen list is useless as there's no way to control which screen you're on from QML at the moment. We could limit ourselves to only allowing a single declarative context to only be associated with one screen, but that prevents future use cases like controlling the UI for both the main display and the external display from a single QML file, which might be useful in for example presentation tools or video players / gallery viewers where the main display shows some controls that are not shown on the external display. In the future we might want to support these use cases as well as better support desktop applications by having a Window item or similar to be able to explicitly create new top-level windows from QML (a similar feature is already exposed in QML desktop components, but it sounds like it would be useful to have a generic abstraction in the QML core). When you say QML core, you mean this should go in the QtQuick module? Or into the engine, and be available without an import statement? The QtQuick module is my preference. Right. My first guess is that it would need to hook into QQuickCanvas to easily find its QWindow* (for screen()) and to be notified of screen changes. That could affect where it can be placed. But if they're all in the QtDeclarative library then it's quite easy for it to work closely with the canvas to achieve this. Yeah, and even though QScreen has a lot of CONSTANT properties all of the ones in Screen would presumably have to be NOTIFY, since the QScreen the QQuickCanvas is on might change. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
On 08/11/2011, at 9:06 PM, João Abecasis wrote: Dr Craig Scott wrote: On 08/11/2011, at 1:31 AM, João Abecasis wrote: At the bare minimum, I think we should strive to support these compilers: - GCC 4.2 and up - MSVC 2008 and later - Clang (trunk) On the page above I also put in a list of platforms, splitting them between Desktop, Embedded and Mobile. The latter two categories only have a placeholder row, while for Desktop I put in the following platform-compiler mappings: - Linux: gcc 4.4 (Debian stable) - Microsoft Windows 7: MSVC 2008 - Mac OS X Lion: gcc 4.2, clang 2.9 I would strongly suggest that the LSB makes an appearance somewhere in the supported platform/compiler listing. To my knowledge, it is the only truly cross-distribution standard that exists for Linux. Does the LSB specify a compiler? Yes... to an extent! The LSB builds are performed using the lsbcc and lsbc++ compilers. I say compilers because what they generally do is forward to some other compiler with some additional flags merged into the command line to make that compiler build in LSB mode. In the vast majority of cases, the underlying compilers are the GNU compilers (gcc and g++), but the LSB standard doesn't explicitly require that to be the case. That said, I think you'd be pretty safe if you assumed GNU compilers for the purposes of the platform discussions for Qt. The LSB SDK provided by the linux foundation does indeed use the GNU compilers under the covers, so it seems reasonable for us to make this assumption within Qt. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote: - the QNAM-style API seems to be OK Correct, but all functions in QDnsResolver are static. That means they could go into QDnsReply and we could rename the class simply QDns. It worked for Qt 3... - I have implemented QDnsReply::abort() to cancel a lookup request Good. - Robin mentioned adding a static QDnsResolver::instance() method, does anyone else have an opinion on this? No need if all functions are static. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] Platform / compiler support
It occurred to me after my previous email that people may not be aware of what the LSB compilers do, so let me provide just a little bit of info to explain why they should be considered explicitly in addition to plain GCC compilers. In a nutshell, when you build your app with the LSB compilers, it will fail to build if your code uses types, interfaces, etc. that are not covered by the LSB. In addition, it invokes the linker in such a way that you get warnings when linking to libraries that are not in the LSB and it also tries to pull in those non-LSB libraries statically instead of dynamically (you can override this where needed). So the LSB compilers should have the same compiler *features* as the underlying gcc, but the supported interfaces, etc. are restricted to just those in the LSB. For Qt source code, supporting the LSB compiler ends up being similar to supporting GCC, with a few special cases where you need to put in LSB-specific bits (eg an alternative implementation for a function call that the LSB does not provide). On the plus side, if it builds with LSB compilers, then the code should also build with GCC. Of course, you can shoot yourself in the foot by changing the code that gets compiled between the LSB and non-LSB compiler (eg #ifdef blocks that build with LSB but not with non-LSB), but that's a different issue. ;) On 09/11/2011, at 8:48 AM, Scott, Craig (CMIS, Clayton) wrote: On 08/11/2011, at 9:06 PM, João Abecasis wrote: Dr Craig Scott wrote: On 08/11/2011, at 1:31 AM, João Abecasis wrote: At the bare minimum, I think we should strive to support these compilers: - GCC 4.2 and up - MSVC 2008 and later - Clang (trunk) On the page above I also put in a list of platforms, splitting them between Desktop, Embedded and Mobile. The latter two categories only have a placeholder row, while for Desktop I put in the following platform-compiler mappings: - Linux: gcc 4.4 (Debian stable) - Microsoft Windows 7: MSVC 2008 - Mac OS X Lion: gcc 4.2, clang 2.9 I would strongly suggest that the LSB makes an appearance somewhere in the supported platform/compiler listing. To my knowledge, it is the only truly cross-distribution standard that exists for Linux. Does the LSB specify a compiler? Yes... to an extent! The LSB builds are performed using the lsbcc and lsbc++ compilers. I say compilers because what they generally do is forward to some other compiler with some additional flags merged into the command line to make that compiler build in LSB mode. In the vast majority of cases, the underlying compilers are the GNU compilers (gcc and g++), but the LSB standard doesn't explicitly require that to be the case. That said, I think you'd be pretty safe if you assumed GNU compilers for the purposes of the platform discussions for Qt. The LSB SDK provided by the linux foundation does indeed use the GNU compilers under the covers, so it seems reasonable for us to make this assumption within Qt. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform / compiler support
Hi, Sorry for the top posting. I wanted to indicate that we are currently supporting the following compilers for Qt Commercial 4.8 (including primary and secondary): VS2005 VS2008 VS2010 MinGW 4.4 Gcc 4.2 - 4.4 Xcode 4 Sun Studio 12 (CC 5.9) Sun Studio 12.2 (CC 5.11) Integrity Multi IDE 6 xLC 7 aCC 6.10 For us, if Qt 5 works with these, as well as new versions is a good starting point. Making sure that Qt 5 works with latest compilers such as VS2011 is important, as they typically provide significant advantages over the previous version. It would be good to have more compilers supported, especially for the embedded platforms. And definitely it is very important that as few as possible compilers are ruled our by design choices in Qt. Yours, -- Tuukka Turunen Director, Qt Commercial RD Digia Plc Piippukatu 11, 40100 Jyväskylä, Finland Visit us at: www.digia.com or qt.digia.com Qt Developer Days 2011 Munich, Germany: Oct 24th 26th San Francisco, California: Nov 29th Dec 1st Meet Digia and Qt Commercial at both events! For more information, please visit: http://qt.digia.com/en/events-devdays2011 On 11/8/11 11:48 PM, craig.sc...@csiro.au craig.sc...@csiro.au wrote: On 08/11/2011, at 9:06 PM, João Abecasis wrote: Dr Craig Scott wrote: On 08/11/2011, at 1:31 AM, João Abecasis wrote: At the bare minimum, I think we should strive to support these compilers: - GCC 4.2 and up - MSVC 2008 and later - Clang (trunk) On the page above I also put in a list of platforms, splitting them between Desktop, Embedded and Mobile. The latter two categories only have a placeholder row, while for Desktop I put in the following platform-compiler mappings: - Linux: gcc 4.4 (Debian stable) - Microsoft Windows 7: MSVC 2008 - Mac OS X Lion: gcc 4.2, clang 2.9 I would strongly suggest that the LSB makes an appearance somewhere in the supported platform/compiler listing. To my knowledge, it is the only truly cross-distribution standard that exists for Linux. Does the LSB specify a compiler? Yes... to an extent! The LSB builds are performed using the lsbcc and lsbc++ compilers. I say compilers because what they generally do is forward to some other compiler with some additional flags merged into the command line to make that compiler build in LSB mode. In the vast majority of cases, the underlying compilers are the GNU compilers (gcc and g++), but the LSB standard doesn't explicitly require that to be the case. That said, I think you'd be pretty safe if you assumed GNU compilers for the purposes of the platform discussions for Qt. The LSB SDK provided by the linux foundation does indeed use the GNU compilers under the covers, so it seems reasonable for us to make this assumption within Qt. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ 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
