Re: [Development] Abandoning the container changes
Hey, I would rather we don't *rush* the container changes in, but get them up to snuff in a separate branch, instead. I would also like to challenge the assumptions I've seen repeated that probability for breakage is low and autotest coverage is high. It isn't and it isn't. It is very easy to break less-often used features and corner cases that will not get caught by autotests. I don't think this is acceptable for fundamentals like QVector and friends. I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. Cheers, João From: development-bounces+joao.abecasis=nokia@qt-project.org [development-bounces+joao.abecasis=nokia@qt-project.org] on behalf of ext André Pönitz [andre.poen...@mathematik.tu-chemnitz.de] Sent: 17 July 2012 23:59 To: development@qt-project.org Subject: Re: [Development] Abandoning the container changes On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote: On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. this is absurd. Incidentally, I agree. [Even if I lack the skill to express myself so clearly at times ;-}] we said A, now we need to say B. or unsay A, which i don't think anyone wants. i for one don't believe in qt6 anytime soon. it's the do-never release qt5 was for years. The suggested 4 years are 3 1/2 years too much anyway. That's 3 1/2 years more of forcing people to re-invent the wheel when it comes to performance-sensitive components in a Qt environment, and it's 3 1/2 years on top of the past half decade or so where Qt containers fail to deliver on one of the original reasons to have them at all (portability, convenience of use, _and_ performance). We do have the chance to fix it _now_, and we have a fairly decent idea of how the fix looks like. The whole change is essentially source compatible, i.e. has a low probability of breaking other components, and it is very well covered by autotests. The chances to be ready before the rest (Webkit Windows? Mac?) is ready for a 5.0 release are good. To get back on the constructive side I propose to do any of the following, in decreasing order of desirability: (A) Have the QString/QByteArray related bits in 5.0. (B) Have everything in 5.0. (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1 next. (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple but binary incompatible. (E) Don't do anything for 5.0, and provide a compile-time switch for 5.1 to select between current and patched versions, default to current. [This is probably the most expensive solution, but the one that fits best to the rules] Andre' ___ 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] Suggestion on QML portability
On Jul 17, 2012, at 9:17 PM, ext Andreas Aardal Hanssen wrote: 2012/7/17 marius.storm-ol...@nokia.com (2D accelerators are often bundled with GPUs and perform 2D rendering ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see pvr2d). 2D accelerators bundled with GPUs perform 2D rendering ops faster than GPUs? Uhmm... that sentence is conflicting in my head, unless you mean that you are using highly specialized boards with multiple GPUs (n*PVR) on them to do things really really fast in parallel. [OT] No, I really mean dedicated 2D hardware chips outperform GPUs by far. It's easy to do certain common simple 2D graphics faster than most embedded GPUs I know of, even using the CPU. GPUs are built for (1) 3D transformations on textures, (2) vertex-heavy objects and (3) per-pixel shading operations. But it's easily beat for simple 2D operations like blit (e.g., DMA), filtering/scaling (e.g., FPGAs). Most mobiles / tablet UIs are 90% 2D. My point is simply that Qt 5 is best served with a painting backend for QML 2 that can support non-OpenGL technologies. Though true that 2D blitters support the basic features needed by many UI's it also comes with a lot of limitations. They often operate on contiguous memory blocks, which need to be allocated by the kernel and comes which is limited in terms of what you can allocate. On several chips I've worked on, this is a system-wide pool, specified at boot-time. They would also not support basic primitives, such as drawing rounded rectangles, antialiasing, free rotation, perspective transformation and 9-patch border images. So all of these would have to be rendered in software. This means a heavy mixing of CPU and accelerated drawing and we both know that combination does indeed suck. OpenGL is flexible enough to support what we need while at the same time providing us with very good performance, so it is the best thing we got. If you know you are not using any of these features, then you could write your own renderer using the scene graph adaptation layer. A renderer that only looks at translate and scale transforms, maybe supports opacity and draws solid color boxes and pre-generated images. Text could be done using the adaptation for glyph nodes to render text using QPainter and then that could also be blitted in the renderer. This is doable today, but it would not support the full QML feature set, so it is not something we will invest time in. There is also the possibility of using a software emulation library for the OpenGL stack to do all the rasterization in software, if there is no OpenGL chip. QML2 on llvmpipe beats QML1 on QPainter/raster, after all.. cheers, Gunnar -- Andreas Aardal Hanssen ___ 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] How to configure qt-4.8 with v8?
Hello, I'm trying to configure the qt-4.8.0 to be linked against the V_, but I didn't find any configure option to do that. can someone help me on that? regards Haithem. -- * Never say that's impossible, the word itself says I'm Possible * ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to configure qt-4.8 with v8?
On Wednesday 18 July 2012 09:34:51 haithem rahmani wrote: Hello, I'm trying to configure the qt-4.8.0 to be linked against the V_, but I didn't find any configure option to do that. can someone help me on that? Qt 4.8 do not use V8. Are you trying to use V8 with QtWebkit or QtScript or Qml? There exists some experimental branches that try to, but nothing released. If you just want to use V8 API dirrectly in yout Qt 4.8 application, you should just use upstream V8 dirrectly. (You could also try to compile the qtjsbackend repository with Qt 4.8. If that works, that could possibly simplify the integration with your build system) -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wed, Jul 18, 2012 at 07:06:55AM +, joao.abeca...@nokia.com wrote: Hey, I would rather we don't *rush* the container changes in, but get them up to snuff in a separate branch, instead. I would also like to challenge the assumptions I've seen repeated that probability for breakage is low and autotest coverage is high. It isn't and it isn't. It is very easy to break less-often used features and corner cases that will not get caught by autotests. I don't think this is acceptable for fundamentals like QVector and friends. I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. That's essentially option (D) with a somewhat longer lead time. I think that would be ok. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. Right. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wednesday July 18 2012, joao.abeca...@nokia.com wrote: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. That will exclude non-C++11 compilers from seeing the more efficient implementations, or else from the BC guarantee. Do we care? Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wednesday July 18 2012, joao.abeca...@nokia.com wrote: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. if it's qt 6, then you call it qt 6. you need to do that because of SOVERSION requirements anyway. but this instantly forces the question: what's the point of rushing out 5.0 now if we already know that we'll deprecate it in a year? The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. every linux distributor will slaughter you for this statement. On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote: We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. and how exactly is this supposed to work? we are not talking about changing some private implementation details, but the publicly visible data structures which are fundamental parts of our api+abi. even if it's somehow possible to have different classes use different container implementations, the conversion overhead would be ridiculous. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On 18/07/2012 02:06, ext joao.abeca...@nokia.com wrote: Hey, I would rather we don't *rush* the container changes in, but get them up to snuff in a separate branch, instead. I would also like to challenge the assumptions I've seen repeated that probability for breakage is low and autotest coverage is high. It isn't and it isn't. It is very easy to break less-often used features and corner cases that will not get caught by autotests. I don't think this is acceptable for fundamentals like QVector and friends. I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. If there's reasons to break BC, there's reasons for a new Major version. We don't circumvent the policies because is looks silly to have a new major version in such a short time after 5.0. However, I can imagine there's other significant changes we'll notice after 5.0 which will warrant other BC-incompatible changes, and maybe we'd want to refactor out more of the modules from QtBase into their own repos? As such, we might have several valid reason for having another major, to quickly correct learned lessons from Qt 5, and to ensure Qt 6 can live on for a very long time. Still, if Qt 6 would be on the road-map then, we should aim for making transitioning as simple as a pure recompile. We don't _have_ to do significant restructuring just because we're going a new major. Simply saying that we need to do it because of BC issues is fine. If major speed improvements is a result of that, I'm sure many people would understand. Anyways, several people and Thiago himself has said that now is not the time for such a change to our tools classes, and we should listen to that. I don't think you want to add them both and let the end user decide, as it will create a maintenance nightmare, and you will have applications which both use Qt 5 but are incompatible with each others run-time. (Some apps will demand that you use the optimized Qt5 for plug-ins etc.) -- .marius Cheers, João From: development-bounces+joao.abecasis=nokia@qt-project.org [development-bounces+joao.abecasis=nokia@qt-project.org] on behalf of ext André Pönitz [andre.poen...@mathematik.tu-chemnitz.de] Sent: 17 July 2012 23:59 To: development@qt-project.org Subject: Re: [Development] Abandoning the container changes On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote: On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. this is absurd. Incidentally, I agree. [Even if I lack the skill to express myself so clearly at times ;-}] we said A, now we need to say B. or unsay A, which i don't think anyone wants. i for one don't believe in qt6 anytime soon. it's the do-never release qt5 was for years. The suggested 4 years are 3 1/2 years too much anyway. That's 3 1/2 years more of forcing people to re-invent the wheel when it comes to performance-sensitive components in a Qt environment, and it's 3 1/2 years on top of the past half decade or so where Qt containers fail to deliver on one of the original reasons to have them at all (portability, convenience of use, _and_ performance). We do have the chance to fix it _now_, and we have a fairly decent idea of how the fix looks like. The whole change is essentially source compatible, i.e. has a low probability of breaking other components, and it is very well covered by autotests. The chances to be ready before the rest (Webkit Windows? Mac?) is ready for a 5.0 release are good. To get back on the constructive side I propose to do any of the following, in decreasing order of desirability: (A) Have the QString/QByteArray related bits in 5.0. (B) Have everything in 5.0. (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1 next. (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple but binary incompatible. (E) Don't do anything for 5.0, and provide a compile-time switch for 5.1 to select between current and patched
Re: [Development] Abandoning the container changes
On Wednesday July 18 2012, Oswald Buddenhagen wrote: On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote: We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. and how exactly is this supposed to work? we are not talking about changing some private implementation details, but the publicly visible data structures which are fundamental parts of our api+abi. even if it's somehow possible to have different classes use different container implementations, the conversion overhead would be ridiculous. That's a question of how the new classes are designed. I don't see an a-priori reason why, say, a v50::QVector couldn't share data with a v51::QVector, esp. considering the flexibility that was already present in Thiago's branch. There will be a conversion penalty of some form, but only for applications that continue to use the old version (because Qt will internally use the newest, of course). There will also be a maintenance penalty, but we already pay it in the form of BC guarantees. If we used inline namespaces, we would trade one form of maintenance burden (keeping BC) for another (maintaining inline namespaces). The question is just: which one is more work? And frankly, no-one knows, because there's no experience with inline namespaces (even though GCC uses something similar for the debug STL containers for a long time). Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wednesday 18 July 2012 14:00:08 Marc Mutz wrote: On Wednesday July 18 2012, Oswald Buddenhagen wrote: On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote: We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. and how exactly is this supposed to work? we are not talking about changing some private implementation details, but the publicly visible data structures which are fundamental parts of our api+abi. even if it's somehow possible to have different classes use different container implementations, the conversion overhead would be ridiculous. That's a question of how the new classes are designed. I don't see an a-priori reason why, say, a v50::QVector couldn't share data with a v51::QVector, esp. considering the flexibility that was already present in Thiago's branch. There will be a conversion penalty of some form, but only for applications that continue to use the old version (because Qt will internally use the newest, of course). There will also be a maintenance penalty, but we already pay it in the form of BC guarantees. If we used inline namespaces, we would trade one form of maintenance burden (keeping BC) for another (maintaining inline namespaces). The question is just: which one is more work? And frankly, no-one knows, because there's no experience with inline namespaces (even though GCC uses something similar for the debug STL containers for a long time). We discussed namespaces long time ago already, and decided not to put Qt in a namespace. The reason is that it breaks source compatibility by breaking all the forward declarations. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wednesday, July 18, 2012 14:00:08 Marc Mutz wrote: The question is just: which one is more work? And frankly, no-one knows, because there's no experience with inline namespaces (even though GCC uses something similar for the debug STL containers for a long time). I believe the llvm community libc++ uses inline namespaces, but that might not have the widespread use and multiple versions required to really get the required experience. I don't think breaking binary compatibility in a 5.x release is a good idea. As was said previously, if it's Qt 6, call it Qt 6. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] How to configure qt-4.8 with v8?
Hi Olivier, thanks for the quick answer. I want to build the QtWebKit with V8? is it possible, working? regards Haithem. On Wed, Jul 18, 2012 at 11:21 AM, Olivier Goffart oliv...@woboq.com wrote: On Wednesday 18 July 2012 09:34:51 haithem rahmani wrote: Hello, I'm trying to configure the qt-4.8.0 to be linked against the V_, but I didn't find any configure option to do that. can someone help me on that? Qt 4.8 do not use V8. Are you trying to use V8 with QtWebkit or QtScript or Qml? There exists some experimental branches that try to, but nothing released. If you just want to use V8 API dirrectly in yout Qt 4.8 application, you should just use upstream V8 dirrectly. (You could also try to compile the qtjsbackend repository with Qt 4.8. If that works, that could possibly simplify the integration with your build system) -- Olivier Woboq - Qt services and support - http://woboq.com -- * Never say that's impossible, the word itself says I'm Possible * ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to configure qt-4.8 with v8?
On Wednesday, July 18, 2012 03:11:37 PM ext haithem rahmani wrote: Hi Olivier, thanks for the quick answer. I want to build the QtWebKit with V8? is it possible, working? Nope. We had a few developments towards that but ultimately abandoned those efforts, largely due to the community not accepting V8 support in WebKit2. The Qt port of WebKit will stay with JavaScriptCore at this point. Simon On Wed, Jul 18, 2012 at 11:21 AM, Olivier Goffart oliv...@woboq.com wrote: On Wednesday 18 July 2012 09:34:51 haithem rahmani wrote: Hello, I'm trying to configure the qt-4.8.0 to be linked against the V_, but I didn't find any configure option to do that. can someone help me on that? Qt 4.8 do not use V8. Are you trying to use V8 with QtWebkit or QtScript or Qml? There exists some experimental branches that try to, but nothing released. If you just want to use V8 API dirrectly in yout Qt 4.8 application, you should just use upstream V8 dirrectly. (You could also try to compile the qtjsbackend repository with Qt 4.8. If that works, that could possibly simplify the integration with your build system) -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behaviour change of opacity property in QtQuick 2.0
On 18.07.2012 13:47, ext Nils Jeisecke wrote:
Hi,
In QtQuick 1 an element with opacity == 0 is treated as invisible
(e.g. it won't see mouse events).
This has changed in QtQuick 2.0 which breaks existing code that
assumes that opacity == 0 means !visible.
This example illustrates the change. A mouse click will print:
QtQuick 1.1: CLICKED A
QtQuick 2.0: CLICKED B
A workaround is to set visible: opacity 0
Is this change intentional?
---
//import QtQuick 2.0
import QtQuick 1.1
Rectangle {
width: 360
height: 360
MouseArea {
anchors.fill: parent
onClicked: console.log(CLICKED A)
}
Rectangle {
anchors.fill: parent
opacity: 0
MouseArea {
anchors.fill: parent
onClicked: console.log(CLICKED B)
}
}
}
---
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Apparently, it was intentional: QTBUG-19193, and commit
9bf96613c1be7d4df7132a9c3c9ac1a8740f698f. It would be nice to know what
the arguments for changing the behaviour were...
Kim
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behaviour change of opacity property in QtQuick 2.0
Apparently, it was intentional: QTBUG-19193, and commit 9bf96613c1be7d4df7132a9c3c9ac1a8740f698f. It would be nice to know what the arguments for changing the behaviour were... Ok, thanks. I should have checked the git log. Sorry. However this change makes QtQuick porting even more complicated because it can be quite hard to figure out why a mousearea that is below some invisible popup (visible but opacity==0) no longer reacts to clicks but to hover events... Nils ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behaviour change of opacity property in QtQuick 2.0
I've just figured out this issue on Snowshoe. The change is not that simple. Assuming visible: opacity 0 will make the property rely on this binding, but other entities may change it manually what would break that binding, and we really did that. :-( On Wed, Jul 18, 2012 at 12:59 PM, Nils Jeisecke njeise...@saltation.dewrote: Apparently, it was intentional: QTBUG-19193, and commit 9bf96613c1be7d4df7132a9c3c9ac1a8740f698f. It would be nice to know what the arguments for changing the behaviour were... Ok, thanks. I should have checked the git log. Sorry. However this change makes QtQuick porting even more complicated because it can be quite hard to figure out why a mousearea that is below some invisible popup (visible but opacity==0) no longer reacts to clicks but to hover events... Nils ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Rafael Brandao @ INdT ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
André Pönitz wrote: On Wed, Jul 18, 2012 at 07:06:55AM +, joao.abeca...@nokia.com wrote: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. That's essentially option (D) with a somewhat longer lead time. Somewhat. If it's a binary break we should still call it Qt 6. I'm thinking we should get 5.0 out, use 5.1 to stabilize, react to feedback and generally (im)prove on the Qt 5 vision. Some container changes sneaked in, but they're not what we're trying to deliver *now*. In parallel, we actually write the container changes everyone's up in arms about (Thiago's changes are unfinished and not-fully-published work in progress), we review those changes, take them for a spin, kick the hell out of those tires and then make an informed decision whether it is worth the binary break and how to handle it, in case it is. Besides autotests coverage, we also have no benchmarks showing improvements. I assume we can see improvements for the inlining of size and offset/data in iteration benchmarks, but we haven't fully explored the impact of *growing* the size of the container itself. Anyway, we can discuss potential options now, but we can't make any decisions and can hardly make commitments, other than than let's do the container changes and release them when they're ready. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
João spaketh: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. André respondeth: That's essentially option (D) with a somewhat longer lead time. João respondeth again: Somewhat. If it's a binary break we should still call it Qt 6. I'm thinking we should get 5.0 out, use 5.1 to stabilize, react to feedback and generally (im)prove on the Qt 5 vision. Some container changes sneaked in, but they're not what we're trying to deliver *now*. In parallel, we actually write the container changes everyone's up in arms about (Thiago's changes are unfinished and not-fully-published work in progress), we review those changes, take them for a spin, kick the hell out of those tires and then make an informed decision whether it is worth the binary break and how to handle it, in case it is. Besides autotests coverage, we also have no benchmarks showing improvements. I assume we can see improvements for the inlining of size and offset/data in iteration benchmarks, but we haven't fully explored the impact of *growing* the size of the container itself. Anyway, we can discuss potential options now, but we can't make any decisions and can hardly make commitments, other than than let's do the container changes and release them when they're ready. IMHO this seems reasonable. I view QML2 as the stabilized version of QML1 (significant technical differences, as well as underlying implementation). I was quite impressed with what QML1 offered (it's a new paradigm), but I think the community would benefit from learning-to-work with QML2 as opposed to extending their learning curves on QML1. I understand the value of the container-changes, and while warranted, it doesn't seem to be the biggest part of the core-offering of Qt5, and it's possible some of the benchmarks/changes associated with that effort might be better understood after the C++11 Rvalue-references are better implemented and made available through compiler vendors. The ideal for me is that if container-changes would push the Qt release back six months (to arbitrarily pick-a-fictitious-number), I'd rather have a release now, and another release in six months. I know it's been discussed before (don't want to re-open that discussion), but I don't care about binary compatibility (I know how to recompile); and only somewhat care about interface compatibility (adding-member-functions seems incredibly cheap to me, I'd prefer to have the APIs mature properly since they represent new designs); and, I'd support any renaming/refactoring to enforce best-practice-use-models as these are discovered when applying this new paradigm. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Marius Storm-Olsen wrote: On 18/07/2012 02:06, ext joao.abeca...@nokia.com wrote: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. If there's reasons to break BC, there's reasons for a new Major version. We don't circumvent the policies because is looks silly to have a new major version in such a short time after 5.0. Agreed. However, I can imagine there's other significant changes we'll notice after 5.0 which will warrant other BC-incompatible changes, and maybe we'd want to refactor out more of the modules from QtBase into their own repos? As such, we might have several valid reason for having another major, to quickly correct learned lessons from Qt 5, and to ensure Qt 6 can live on for a very long time. Yes, by all means when we notice these needed changes and have them ready let's bundle them together and call them a release. Let's not plan releases based on features and let's not plan to do work based on the assumption that we're doing a binary break anyway, at least for as long as we can avoid it. Still, if Qt 6 would be on the road-map then, we should aim for making transitioning as simple as a pure recompile. We don't _have_ to do significant restructuring just because we're going a new major. Simply saying that we need to do it because of BC issues is fine. If major speed improvements is a result of that, I'm sure many people would understand. Agreed. Anyways, several people and Thiago himself has said that now is not the time for such a change to our tools classes, and we should listen to that. I don't think you want to add them both and let the end user decide, as it will create a maintenance nightmare, and you will have applications which both use Qt 5 but are incompatible with each others run-time. (Some apps will demand that you use the optimized Qt5 for plug-ins etc.) My suggestion is not to have both variants in the common code base or to advertise two alternative Qt 5 implementations. I'm suggesting we treat this as feature development happening in a feature branch (reviewed, CI-tested and all that, if feasible). I'm also suggesting we consider the posibility of doing an earlier BC break with stronger SC guarantees and use that if/when there's significant value being added. Having this *possibility* at all can encourage people to try out things, instead of waiting for a Do Never Qt 6 (tm) release and rushing half-baked features out. João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behaviour change of opacity property in QtQuick 2.0
On Wed, 18 Jul 2012 13:47:36 ext Nils Jeisecke wrote:
Hi,
In QtQuick 1 an element with opacity == 0 is treated as invisible
(e.g. it won't see mouse events).
This has changed in QtQuick 2.0 which breaks existing code that
assumes that opacity == 0 means !visible.
This example illustrates the change. A mouse click will print:
QtQuick 1.1: CLICKED A
QtQuick 2.0: CLICKED B
A workaround is to set visible: opacity 0
Is this change intentional?
Yes, this was intentional. Opacity is now a purely visual property, and only
visible is used for optimizations (such as not receiving input or being
positioned). Sorry, this should have been listed in What's New;
https://codereview.qt-project.org/31057 fixes this.
The reason, apart from better conceptual consistency, is that this makes
opacity a lot easier to use and animate in some circumstances. Key edge cases
involved wanting to fade something out but not actually lose the 'visible'
behavior, such as collecting mouse events or being positioned by positioner
elements. Previously the below snippet would have the green rectangle jerk
around a lot because it was repositioned in the instant that opacity became 0
for the blue rectangle, and again when it became non-zero.
Column {
Rectangle { color: red; width: 40; height: 40}
Rectangle
{
color: blue; width: 40; height: 40
SequentialAnimation on opacity {
NumberAnimation{ from: 1; to: 0 }
NumberAnimation{ from: 0; to: 1 }
}
}
Rectangle { color: green; width: 40; height: 40}
}
You can imagine the analagous situation with a MouseArea, where its subtree is
pulsing in opacity and if the user clicks at the wrong time then it
inexplicably doesn't work.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wed, Jul 18, 2012 at 05:49:12PM -0600, Charley Bay wrote: The ideal for me is that if container-changes would push the Qt release back six months (to arbitrarily pick-a-fictitious-number), I'd rather have a release now, and another release in six months. This was not meant to put anything on the critical path or to change the timing of Qt 5.0 at all. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behaviour change of opacity property in QtQuick 2.0
On Wed, Jul 18, 2012 at 10:08 PM, Alan Alpert alan.alp...@nokia.com wrote:
On Wed, 18 Jul 2012 13:47:36 ext Nils Jeisecke wrote:
Hi,
In QtQuick 1 an element with opacity == 0 is treated as invisible
(e.g. it won't see mouse events).
This has changed in QtQuick 2.0 which breaks existing code that
assumes that opacity == 0 means !visible.
This example illustrates the change. A mouse click will print:
QtQuick 1.1: CLICKED A
QtQuick 2.0: CLICKED B
A workaround is to set visible: opacity 0
Is this change intentional?
Yes, this was intentional. Opacity is now a purely visual property, and only
visible is used for optimizations (such as not receiving input or being
positioned). Sorry, this should have been listed in What's New;
https://codereview.qt-project.org/31057 fixes this.
The reason, apart from better conceptual consistency, is that this makes
opacity a lot easier to use and animate in some circumstances. Key edge cases
involved wanting to fade something out but not actually lose the 'visible'
behavior, such as collecting mouse events or being positioned by positioner
elements. Previously the below snippet would have the green rectangle jerk
around a lot because it was repositioned in the instant that opacity became 0
for the blue rectangle, and again when it became non-zero.
Column {
Rectangle { color: red; width: 40; height: 40}
Rectangle
{
color: blue; width: 40; height: 40
SequentialAnimation on opacity {
NumberAnimation{ from: 1; to: 0 }
NumberAnimation{ from: 0; to: 1 }
}
}
Rectangle { color: green; width: 40; height: 40}
}
You can imagine the analagous situation with a MouseArea, where its subtree is
pulsing in opacity and if the user clicks at the wrong time then it
inexplicably doesn't work.
Just to point out that this is the way HTML/CSS behave. Opacity is a
purely visual property and visible (e.g. display: none for invisible)
is used to optimize away (not creating the node in the render tree).
An opacity : 0 div will receive the mouse inputs whereas a display:
none will not. Though later on I'm sure WebKit has optimization to
filter away opacity:0 element to speed up rendering but that's not
part of the discussion :).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
--
Alexis Menard (darktears)
Software Engineer
openBossa @ INdT - Instituto Nokia de Tecnologia
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behaviour change of opacity property in QtQuick 2.0
On Wed, 18 Jul 2012 19:00:01 ext Rafael Brandao wrote: I've just figured out this issue on Snowshoe. The change is not that simple. Assuming visible: opacity 0 will make the property rely on this binding, but other entities may change it manually what would break that binding, and we really did that. :-( There's a new enabled property which also prevents mouse input. It also affects keyboard focus, but if you aren't using keyboard focus you can bind enabled: opacity 0 and get effectively the same results as before. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Project CI outage on 19th-20th July 2012
Hi all, Please be advised that tonight/tomorrow the Qt Project CI system will have a temporary outage for planned maintenance of a site UPS. The system will stop accepting new builds at: 18:30 UTC, 19th 20:30 CET, 19th 04:30 AEST, 20th The outage is estimated to last somewhere from 4-7 hours. It is fine to stage changes in this time, but they won't make progress until the maintenance is completed. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
