[Development] Nominating Peter Varga for approver status
Hi, I would like to nominate Peter for approver status. As part of the team in the University of Szeged he has completed the past few rebases of V8 in the qtjsbackend module, a task that is anything but easy, with a fast moving upstream and a very complex patch set on our side. Based on his contributions he has clearly shown an understanding of V8 and the way QML is using it. An understanding that I believe is deep enough for him to easily review and approve contributions. I trust him to follow the process and I trust him to review only patches he's comfortable reviewing. Seconds? :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Peter Varga for approver status
On Wednesday 23. May 2012 09.02.00 ext Simon Hausmann wrote: Hi, I would like to nominate Peter for approver status. As part of the team in the University of Szeged he has completed the past few rebases of V8 in the qtjsbackend module, a task that is anything but easy, with a fast moving upstream and a very complex patch set on our side. Based on his contributions he has clearly shown an understanding of V8 and the way QML is using it. An understanding that I believe is deep enough for him to easily review and approve contributions. I trust him to follow the process and I trust him to review only patches he's comfortable reviewing. Seconds? :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Seconded :-) Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mutex future directions
On quarta-feira, 23 de maio de 2012 04.54.11, bradley.hug...@nokia.com wrote: On May 22, 2012, at 11:01 AM, ext Thiago Macieira wrote: And I don't think they very much liked the idea of spinning while trying to acquire a lock (consumes power)... at least we have a call to QThread::yieldCurrentThread(), though it would be interesting to see what happens if we replace it with a PAUSE instruction. Have you seen the spin code in 4.8? It does use QThread::yieldCurrentThread(). ;) Indeed it does. I'm saying that it would be interesting to check what happens if we replace it with a simple PAUSE instruction. We might be able to achieve the same result with a much smaller overhead. -- 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] Nominating Peter Varga for approver status
Hi, Den 23. mai 2012 09:02, skrev ext Simon Hausmann: Hi, I would like to nominate Peter for approver status. As part of the team in the University of Szeged he has completed the past few rebases of V8 in the qtjsbackend module, a task that is anything but easy, with a fast moving upstream and a very complex patch set on our side. Based on his contributions he has clearly shown an understanding of V8 and the way QML is using it. An understanding that I believe is deep enough for him to easily review and approve contributions. I trust him to follow the process and I trust him to review only patches he's comfortable reviewing. Seconds? :) Yes. Peter has been doing great work with preparing and testing the V8 updates, and keeping our patch set clean. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] On QML, ownership, QObject-trees and QSharedPointer
Hello qtpies.
Disclaimer 1: I have read incessantly in the Quick documents, searched
the net and also extensively used QML. Please don't LMGTFY or RTFM me
instinctively ;-)
Disclaimer 2: I started a topic at QtCentre
(http://www.qtcentre.org/threads/49059-QSharedPointer-QWeakPointer-in-QML),
hoping to open up a larger discussion about the handling of objects
and types between C++ and QML, but I have closed down that broader
topic and moved it to this list instead.
Disclaimer 3: Discussing QML seems very poisonous these days, but I
still feel the need for a thread that focus on the good and bad with
the current design and/or the current documentation specifically
regarding exposing C++ to QML. Hopefully you agree and can accept that
I bring it up on the developer list.
So rewording the concerns to open up for (hopefully) useful comments -
I can perhaps try to make a wiki article which adds any missing
information:
OWNERSHIP...
These are the ownership universes (unless I'm mistaken):
1) Objects created in C++ owned via the QObject parent/child tree
e.g.: new MyGizmo.
2) Objects created in C++ owned via the QSharedPointer system, e.g.:
QSharedPointer (new MyGizmo).
3) Objects created by QDeclarativeEngine or Javascript owned by the
engine, e.g.: MyGizmo { ... properties ... }
Question: How can we expose objects governed by QSharedPointer to QML
safely? I *can* guarantee the lifecycle beyond the life of my
QDeclarativeEngine.
These are the ways to transfer values/references from C++ to QML
(let's ignore the other way around for now):
A) By calling QDeclarative::setRootContext (ownership not transferred:
http://qt-project.org/doc/qt-4.8/qdeclarativecontext.html#setContextProperty).
B) By calling QObject::setProperty on the instantiated component (ownership?)
C) By QML calling a method on a C++ object and getting a response
(ownership IS transferred to QML. In the docs somewhere.)
D) By QML accessing a Q_PROPERTY on a C++ object (ownership?).
Now, A+B lend themselves badly as mechanisms to expose subobjects, but
makes it easy to specify ownership via
QDeclarativeEngine::setObjectOwnership.
Conversely C+D are better at exposing subobjects or related
collections (in QML... myProperty: myGizmo.findAllTimelineEvents() ),
but I don't see how I can specify ownership in a QML-agnostic way (C++
models should not know about QML!)
Question: What happens to ownership in each of these transfers?
TYPESYSTEM...
Then there is the issue of what type is associated with the object.
This is relevant when specifying properties in QML. I believe that a
major source of confusion comes from the notion that there are three
type systems involved:
1) The traditional Qt/C++ moc/compiler types (perhaps QObjects,
perhaps declared Q_DECLARE_METATYPE to make QVariant understand them)
2) The types that the Javascript engine knows (Object, Function,
Number, String etc.)
3) The types that the QML engine understands
(http://doc-snapshot.qt-project.org/4.8/qdeclarativebasictypes.html
plus those registered with qmlRegisterType). QVariants can be used
too.
Question: Are there 2 or 3 typesystems?
I assume that each time a value crosses a boundary between from C++ =
QML = Javascript an automatic conversion takes place. This conversion
is probably the root of all evils, since a lot can happen with pointer
references being smashed to either some form of null (as in
unsuccessful C++ to QML assignment via (A) or (B) above) or
undefined (like when a javascript expression tries to access a QML
Component property) depending on factors not quite clear to me.
Question: What are the exact mechanisms that governs value conversion
from one space to another?
COLLECTIONS...
Collections (QList, QMap, QHash, QSet) of object references
constitutes a special scenario which in my view is less that ideally
solved. I would love a much simpler and more intuitive way to expose
those to QML. But given that this topic is way too large, I don't want
to bring it up here, although it does belong.
DOCUMENTATION...
The truth is that initially in ten out of ten cases I resorted to
guessing about the type and ownership of a value when I cross a
boundary. Since I have thoroughly cross examined the docs, it must
mean that (subjectively) I find it hard to extract the proper
information from them. I miss clear best practices, and often feel
more confused by reading the docs than I feel enlightened. In fact,
let me upgrade that statement:
We are quite a lot of programmers who do not have the luxury of
reading long passages of prose in documentation anymore! (For the same
reason I have avoided writing this email as long as I could to spare
*you* the burden of reading messy prose text). We need quick reference
cards containing COMPLETE information about all possibilities in one
place. You are only asking for trouble if you make it mandatory to
read every article under
http://doc-snapshot.qt-project.org/4.8/qtquick.html to be able to
write bug free code.
Sorry. But I'm
Re: [Development] On QML, ownership, QObject-trees and QSharedPointer
Hi Rene, I don't have real answers for your questions, but just a piece of advice: KISS. On 05/23/2012 01:25 PM, Rene Jensen wrote: Question: How can we expose objects governed by QSharedPointer to QML safely? I *can* guarantee the lifecycle beyond the life of my QDeclarativeEngine. As neither of us knows exactly how QML handles QSharedPointer (my guess is that it simply doesn't; QSharedPointer is a template class which can be used with many other types than QObject, so I don't think that exposing it in QML is trivial), I would simply recommend you not to use it. I actually mentioned QSharedPointer in a recent blog post of mine [0], which you might find interesting especially if your use of QSharedPointer is suggested by your previous experience with other toolkits. If you really think that QSharedPointer is absolutely necessary in your case (I still doubt), then just expose its QObject data to QML, since you also claim that you can make sure its lifetime will survive the engine. These are the ways to transfer values/references from C++ to QML (let's ignore the other way around for now): A) By calling QDeclarative::setRootContext (ownership not transferred: http://qt-project.org/doc/qt-4.8/qdeclarativecontext.html#setContextProperty). Note that you don't need to call setRootContext(); you can just get the existing context (with QDeclarative::rootContext()) and call setContextProperty() on it (maybe that's exactly the same you meant?). B) By calling QObject::setProperty on the instantiated component (ownership?) C) By QML calling a method on a C++ object and getting a response (ownership IS transferred to QML. In the docs somewhere.) Sure? That would seem a bit weird to me: how can QML know whether the object you return is a newly created one, or some object owned by some other object (and what if the object is const?)? D) By QML accessing a Q_PROPERTY on a C++ object (ownership?). E) Implement your own QDeclarative component in C++, which could wrap your hard-to-expose-to-QML object, and let it implement properties and methods which expose only data types that are safe and easy to use in QML. [...] As I said, I don't have the knowledge to reply to your other questions; but my gut feeling is that if you need to know the answers, you have already lost. :-) The key, IMHO, is to find a way to design your software so that you use the toolkit to the extent that you rely only on its well-documented properties. Refactoring your code and making it simple will not only help you to make it work with QML, but also make it easier for you to maintain it. IMHO, whatever the answers to your questions, you should try to forget them immediately or at least not rely on them. It will make your life easier on the long run. :-) Ciao, Alberto [0]: http://blog.mardy.it/2012/05/from-g-to-q.html -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On QML, ownership, QObject-trees and QSharedPointer
On quarta-feira, 23 de maio de 2012 14.16.12, Alberto Mardegan wrote: On 05/23/2012 01:25 PM, Rene Jensen wrote: Question: How can we expose objects governed by QSharedPointer to QML safely? I can guarantee the lifecycle beyond the life of my QDeclarativeEngine. As neither of us knows exactly how QML handles QSharedPointer (my guess is that it simply doesn't; QSharedPointer is a template class which can be used with many other types than QObject, so I don't think that exposing it in QML is trivial), I would simply recommend you not to use it. I actually mentioned QSharedPointer in a recent blog post of mine [0], which you might find interesting especially if your use of QSharedPointer is suggested by your previous experience with other toolkits. If you really think that QSharedPointer is absolutely necessary in your case (I still doubt), then just expose its QObject data to QML, since you also claim that you can make sure its lifetime will survive the engine. Just a tidbit... I've long wanted to make QSharedPointer on QObject-derivatives participate in the whole-tree ownership, somehow. I introduced QSharedPointer in 4.4 and I did some work in 4.5 to make that work. My original solution was to have a parent only deref its children's shared pointer counter, deleting it only if it became zero. That means that if you had a QSharedPointer to an object in the middle of the hierarchy, that object would be orphaned instead of deleted when the parent died. The converse was that when the last QSharedPointer reference to a QObject went away, the object might survive if it still had a parent. There were a few problems with that solution. I can remember now: 1) it didn't play very well with QWidgets after the Alien project. QWidgets often reference the top-level window, which is the ultimate parent widget (the one with no parents). Orphaning a QWidget from QWidget's destructor was a recipe for disaster, since the original TLW data might have been gone already. 2) it didn't play very well with QObject siblings talking to each other during destruction or, worse, deleting each other. This is a huge pain and source of complexity during QObject infanticide. 3) what happens if you had a QSharedPointerQObject with a parent, dropped the last QSharedPointer reference (it survives because of the parent) and later orphaned that object via setParent(0)? Should it be deleted? The worst of it all is that I remember having a discussion during 4.6 times with someone on IRC and coming up with a brilliant and simple solution. Something like don't orphan, but keep a refcount on the entire tree. The problem is that I didn't write it down, because I thought it was so simple and evident that I'd be able to remember or work it out again. I haven't been able to. Fermat would be proud. Anyway, that reminds me I have some pending QSharedPointer work to do. I'll get on with it. -- 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] On QML, ownership, QObject-trees and QSharedPointer
W00t should have a backlog which covers the conversation, if it was done on our public channels :-) -- Sent from my Nokia N9On 5/23/12 13:44 ext Thiago Macieira wrote: On quarta-feira, 23 de maio de 2012 14.16.12, Alberto Mardegan wrote: On 05/23/2012 01:25 PM, Rene Jensen wrote: Question: How can we expose objects governed by QSharedPointer to QML safely? I can guarantee the lifecycle beyond the life of my QDeclarativeEngine. As neither of us knows exactly how QML handles QSharedPointer (my guess is that it simply doesn't; QSharedPointer is a template class which can be used with many other types than QObject, so I don't think that exposing it in QML is trivial), I would simply recommend you not to use it. I actually mentioned QSharedPointer in a recent blog post of mine [0], which you might find interesting especially if your use of QSharedPointer is suggested by your previous experience with other toolkits. If you really think that QSharedPointer is absolutely necessary in your case (I still doubt), then just expose its QObject data to QML, since you also claim that you can make sure its lifetime will survive the engine. Just a tidbit... I've long wanted to make QSharedPointer on QObject-derivatives participate in the whole-tree ownership, somehow. I introduced QSharedPointer in 4.4 and I did some work in 4.5 to make that work. My original solution was to have a parent only deref its children's shared pointer counter, deleting it only if it became zero. That means that if you had a QSharedPointer to an object in the middle of the hierarchy, that object would be orphaned instead of deleted when the parent died. The converse was that when the last QSharedPointer reference to a QObject went away, the object might survive if it still had a parent. There were a few problems with that solution. I can remember now: 1) it didn't play very well with QWidgets after the Alien project. QWidgets often reference the top-level window, which is the ultimate parent widget (the one with no parents). Orphaning a QWidget from QWidget's destructor was a recipe for disaster, since the original TLW data might have been gone already. 2) it didn't play very well with QObject siblings talking to each other during destruction or, worse, deleting each other. This is a huge pain and source of complexity during QObject infanticide. 3) what happens if you had a QSharedPointerQObject with a parent, dropped the last QSharedPointer reference (it survives because of the parent) and later orphaned that object via setParent(0)? Should it be deleted? The worst of it all is that I remember having a discussion during 4.6 times with someone on IRC and coming up with a brilliant and simple solution. Something like don't orphan, but keep a refcount on the entire tree. The problem is that I didn't write it down, because I thought it was so simple and evident that I'd be able to remember or work it out again. I haven't been able to. Fermat would be proud. Anyway, that reminds me I have some pending QSharedPointer work to do. I'll get on with it. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On QML, ownership, QObject-trees and QSharedPointer
All: W00t should have a backlog which covers the conversation, if it was done on our public channels :-) If only Pierre de Fermat had had that feature! Atlant -Original Message- From: development-bounces+aschmidt=dekaresearch@qt-project.org [mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On Behalf Of marius.storm-ol...@nokia.com Sent: Wednesday, May 23, 2012 09:52 To: development@qt-project.org; thiago.macie...@intel.com Subject: Re: [Development] On QML, ownership, QObject-trees and QSharedPointer W00t should have a backlog which covers the conversation, if it was done on our public channels :-) -- Sent from my Nokia N9On 5/23/12 13:44 ext Thiago Macieira wrote: On quarta-feira, 23 de maio de 2012 14.16.12, Alberto Mardegan wrote: On 05/23/2012 01:25 PM, Rene Jensen wrote: Question: How can we expose objects governed by QSharedPointer to QML safely? I can guarantee the lifecycle beyond the life of my QDeclarativeEngine. As neither of us knows exactly how QML handles QSharedPointer (my guess is that it simply doesn't; QSharedPointer is a template class which can be used with many other types than QObject, so I don't think that exposing it in QML is trivial), I would simply recommend you not to use it. I actually mentioned QSharedPointer in a recent blog post of mine [0], which you might find interesting especially if your use of QSharedPointer is suggested by your previous experience with other toolkits. If you really think that QSharedPointer is absolutely necessary in your case (I still doubt), then just expose its QObject data to QML, since you also claim that you can make sure its lifetime will survive the engine. Just a tidbit... I've long wanted to make QSharedPointer on QObject-derivatives participate in the whole-tree ownership, somehow. I introduced QSharedPointer in 4.4 and I did some work in 4.5 to make that work. My original solution was to have a parent only deref its children's shared pointer counter, deleting it only if it became zero. That means that if you had a QSharedPointer to an object in the middle of the hierarchy, that object would be orphaned instead of deleted when the parent died. The converse was that when the last QSharedPointer reference to a QObject went away, the object might survive if it still had a parent. There were a few problems with that solution. I can remember now: 1) it didn't play very well with QWidgets after the Alien project. QWidgets often reference the top-level window, which is the ultimate parent widget (the one with no parents). Orphaning a QWidget from QWidget's destructor was a recipe for disaster, since the original TLW data might have been gone already. 2) it didn't play very well with QObject siblings talking to each other during destruction or, worse, deleting each other. This is a huge pain and source of complexity during QObject infanticide. 3) what happens if you had a QSharedPointerQObject with a parent, dropped the last QSharedPointer reference (it survives because of the parent) and later orphaned that object via setParent(0)? Should it be deleted? The worst of it all is that I remember having a discussion during 4.6 times with someone on IRC and coming up with a brilliant and simple solution. Something like don't orphan, but keep a refcount on the entire tree. The problem is that I didn't write it down, because I thought it was so simple and evident that I'd be able to remember or work it out again. I haven't been able to. Fermat would be proud. Anyway, that reminds me I have some pending QSharedPointer work to do. I'll get on with it. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Click https://www.mailcontrol.com/sr/Bj8gU1boyQLTndxI!oX7UjaeDmea67kX7SqObTicsrBLI7iRALOOZRgXDSSm+ebxNAjdtRoTpmRPbv5+FCDqIw== to report this email as spam. 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
[Development] Binary incompatible changes to Qt 4.8
Hi, I wanted to backport the support for Windows 8 to Qt 4.8, which is already done for Qt5 in https://codereview.qt-project.org/#change,22940 With this change a symbol is added and therefore binary compatibility is broken. I know i cannot do that for Qt 4.8, so my question if we should do this anyhow or how we want to handle this. The problem I am seeing is that Qt prints for every Qt application this: Qt: Untested Windows version 6.2 detected! And some tools are eg parsing the output of qmake and get confused by this(eg cmake). I would also like if we would handle such things differently, so that we are just using a qDebug there or similar. So that these tools are not breaking. Thank you Andreas -- Andreas Holzammer | andreas.holzam...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary incompatible changes to Qt 4.8
Hi Andreas, On Wed, May 23, 2012 at 11:12 AM, Andreas Holzammer andreas.holzam...@kdab.com wrote: Hi, I wanted to backport the support for Windows 8 to Qt 4.8, which is already done for Qt5 in https://codereview.qt-project.org/#change,22940 With this change a symbol is added and therefore binary compatibility is broken. I know i cannot do that for Qt 4.8, so my question if we should do this anyhow or how we want to handle this. That change preserves BC (enums don't create symbols either). It only breaks SC between patch releases which we avoid. I think it's fine to backport it and mark the enum with \internal for qdoc. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fixing input for eglfs and friends
Hi, as we are working on better support of embedded devices in Qt, we also are tapping into the input handling. The initial issue with our current input handling for platforms like eglfs, which do not handle input on its own, is, that we have input plugins for mouse/keyboard/touch (evdev), which are seperate from each other. So one needs to specify -plugin evdevkeyboard on the commandline in order to get keyboard input. The evdev* plugins are trying to use udev to detect all available devices and also handle the remove and add events for such input devices. To get rid of the -plugin argument we would like to create the keyboard/mouse/touch plugins always from eglfs directly. This works fine when udev is present, but fails badly without udev, as all plugins currently default to event0, if you dont specify the device explicitly again on the commandline. A fix would be to add a fallback device discovery, which picks up all available devices without udev and creates the specific keyboard/mouse handler. But this raised the problem of the lack of detecting if its a keyboard or mouse or whatever from the evdev side, as evdev does not have such a destinction. It just handles input events and does not care if its a key or mouse event. Thus udev has some tricks to probe different attributes through evdev to get the device type, which I dont really want to pull into our code. For those reasons, I will go ahead and merge evdevkeyboard and evdevmouse as a start. The merge potentially also adds the ability to properly send key and mouse events from devices, that have both event types (like a scroll wheel on the keyboard) I cannot merge evdevtouch for now, since I dont have a proper touchdevice to test with. Also the udev part in platformsupport will get a fallback to detect devices at startup. Are there any concerns or better ways to solve the currently broken out-of-the box experience with eglfs and such? Johannes ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Should we change the default codec of QTextStream to UTF-8?
Hi all, It might be a bit late for 5.0. But Qt 5 have started to enforce that source code file must be UTF-8. So perhaps it make sense to change the default codec of QTextStream to UTF-8. This won't break many things, as the old behavior can be obtained by calling QTextStream::setCodec(). I have push a commit for it: https://codereview.qt-project.org/#change,26985 In addition, this will improve the unicode handling ability of Qt tools with using bootstrap. Otherwise, tools such as qmake can not deal with UTF-8 encoded files. Any idea? Regards, Debao ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mutex future directions
Hi Bradley, And I don't think they very much liked the idea of spinning while trying to acquire a lock (consumes power)... at least we have a call to QThread::yieldCurrentThread(), though it would be interesting to see what happens if we replace it with a PAUSE instruction. Have you seen the spin code in 4.8? It does use QThread::yieldCurrentThread(). ;) I guess it depends a bit on if you want to yield to another thread or not ;-). Of course: burning cpu time is another way to solve this ;-) Greetings, Carsten -- Bradley T. Hughes bradley.hug...@nokia.com ___ 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] Current qt5 version from git does not compile
Hi all, I'm having a similar issue, but a bit farther off the beaten path. I'm on VS2008, but trying to cross compile for Wince. I can get the compile to finish after applying a number of patches and hacks, but only if I manually add QtV8 to the include and lib paths for a bunch of qtdeclarative Makefiles. Something is keeping qmake from adding them to the Makefiles automatically. I was able to see in the link that Rohan provided that the Win7 build's compile command adds the path to qtjsbackend, and my compile command doesn't. I'm not sure where to look in the .pro or qmake code to see what is missing and try to get this fixed, though. Can anyone point me in the right direction? Thanks! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary incompatible changes to Qt 4.8
On 23 May 2012 20:03, Girish Ramakrishnan gir...@forwardbias.in wrote: Hi Andreas, On Wed, May 23, 2012 at 11:12 AM, Andreas Holzammer andreas.holzam...@kdab.com wrote: Hi, I wanted to backport the support for Windows 8 to Qt 4.8, which is already done for Qt5 in https://codereview.qt-project.org/#change,22940 With this change a symbol is added and therefore binary compatibility is broken. I know i cannot do that for Qt 4.8, so my question if we should do this anyhow or how we want to handle this. That change preserves BC (enums don't create symbols either). It only breaks SC between patch releases which we avoid. I think it's fine to backport it and mark the enum with \internal for qdoc. But that breaks the purpose of the patch: having a publicdocumented way for Qt apps to detect if they're running under Windows 8. Generally speaking, are there no plans of going towards 4.9 for this kind of things? Or slightly change the policies for what regards 4.8? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mutex future directions
On quarta-feira, 23 de maio de 2012 22.52.55, Carsten Breuer wrote: Hi Bradley, And I don't think they very much liked the idea of spinning while trying to acquire a lock (consumes power)... at least we have a call to QThread::yieldCurrentThread(), though it would be interesting to see what happens if we replace it with a PAUSE instruction. Have you seen the spin code in 4.8? It does use QThread::yieldCurrentThread(). ;) I guess it depends a bit on if you want to yield to another thread or not ;-). Of course: burning cpu time is another way to solve this ;-) According to the Intel manual, if you *don't* yield and you don't have the PAUSE instruction, you may make things worse. For one thing, if you don't yield, the processor will continue executing your code, without giving a chance for other processes to run. There's no guarantee even in a multiprocessor system that the other thread is running. And even if it's running, if it was scheduled to another thread on the same hyperthreaded core, the processor may not execute the that thread because this thread still has instructions to execute. To make matters worse, if you spin too quickly, you issue a LOT of atomic compare-and-swap commands, which block the bus. So even if the other thread is scheduled by the OS and is running in a different core, it may have memory stall issues. Hence one of the most counter-intuitive (at first glance) recommendations: to make your spin lock loops faster, insert a PAUSE :-) -- 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] Should we change the default codec of QTextStream to UTF-8?
On quarta-feira, 23 de maio de 2012 13.30.05, 1+1=2 wrote: In addition, this will improve the unicode handling ability of Qt tools with using bootstrap. Otherwise, tools such as qmake can not deal with UTF-8 encoded files. That is irrelevant. qmake operates on Latin1 exclusively because it doesn't even include QTextCodec. -- 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] Mutex future directions
Hi Thiago, thanks for clearing this :-) I guess it depends a bit on if you want to yield to another thread or not ;-). Of course: burning cpu time is another way to solve this ;-) According to the Intel manual, if you *don't* yield and you don't have the PAUSE instruction, you may make things worse. What do you exactly mean with a PAUSE instruction. Is this a assembler processor command? For one thing, if you don't yield, the processor will continue executing your code, without giving a chance for other processes to run. There's no guarantee even in a multiprocessor system that the other thread is running. And even if it's running, if it was scheduled to another thread on the same hyperthreaded core, the processor may not execute the that thread because this thread still has instructions to execute. Interesting. Wouldn't it be better to change YieldCurrentThread? I guess, most of us are not aware of this and some of us learned in the 386 century that give back CPU performance to the OS is always a good thing. I guess it is even nowadays a good thing on single core machines. Isn't it? Thanks and Best Regards, Carsten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mutex future directions
On quarta-feira, 23 de maio de 2012 23.44.57, Carsten Breuer wrote: Hi Thiago, thanks for clearing this :-) I guess it depends a bit on if you want to yield to another thread or not ;-). Of course: burning cpu time is another way to solve this ;-) According to the Intel manual, if you *don't* yield and you don't have the PAUSE instruction, you may make things worse. What do you exactly mean with a PAUSE instruction. Is this a assembler processor command? The PAUSE instruction on x86. I don't know of equivalent in other architectures. Trivia: the instruction is encoded as REP NOP. For one thing, if you don't yield, the processor will continue executing your code, without giving a chance for other processes to run. There's no guarantee even in a multiprocessor system that the other thread is running. And even if it's running, if it was scheduled to another thread on the same hyperthreaded core, the processor may not execute the that thread because this thread still has instructions to execute. Interesting. Wouldn't it be better to change YieldCurrentThread? I guess, most of us are not aware of this and some of us learned in the 386 century that give back CPU performance to the OS is always a good thing. I guess it is even nowadays a good thing on single core machines. Isn't it? The yieldCurrentThread call is a system call: it tells the OS to think about scheduling another thread. The PAUSE instruction is a processor-only hint. They have different purposes and we should benchmark. -- 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] Binary incompatible changes to Qt 4.8
On Wed, May 23, 2012 at 2:00 PM, Giuseppe D'Angelo dange...@gmail.com wrote: On 23 May 2012 20:03, Girish Ramakrishnan gir...@forwardbias.in wrote: Hi Andreas, On Wed, May 23, 2012 at 11:12 AM, Andreas Holzammer andreas.holzam...@kdab.com wrote: Hi, I wanted to backport the support for Windows 8 to Qt 4.8, which is already done for Qt5 in https://codereview.qt-project.org/#change,22940 With this change a symbol is added and therefore binary compatibility is broken. I know i cannot do that for Qt 4.8, so my question if we should do this anyhow or how we want to handle this. That change preserves BC (enums don't create symbols either). It only breaks SC between patch releases which we avoid. I think it's fine to backport it and mark the enum with \internal for qdoc. But that breaks the purpose of the patch: having a publicdocumented way for Qt apps to detect if they're running under Windows 8. I thought the main purpose was to let Qt know about the existence of Windows 8. Usually, code in Qt usually just does = VISTA. But if the goal is for the user to use it, then yes, we have a problem. Generally speaking, are there no plans of going towards 4.9 for this kind of things? Or slightly change the policies for what regards 4.8? I would actually like to see a 4.9. At the very minimum, a master branch in qt4 repo would be nice to have. But the logistics both creating a minor release (and post minor release) will require somebody to step up and invest a lot of time. Do we have someone who can invest such time there? Otherwise, it only makes sense to change our policy a little. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Removing obsolete overload for QQmlEngine::importPlugin
As per QTBUG-25122 (https://bugreports.qt-project.org/browse/QTBUG-25122 ), I would like to remove the obsolete overload of the QQmlEngine::importPlugin() function. I am not aware of any remaining users of this overload - if you are still using it and need some time to migrate to using the improved signature, please let me know. Thanks, Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bugreports for Playground projects
Unfortunately, for all sysadmin-related jobs, we have legal issues that need to be dealt with, so it's not as simple as starting to do it. I don't know how to go from here. I would personally like to see as much Open Governance in the Qt Project as possible. This is also relevant for sysadmin-related jobs. If Nokia has sysadmin-job related maintainance manpower and legal issues, things either need to be prioritized higher on Nokia's side, like this request, or there should be steps taken to open up the process for the community as soon as possible. I am fine with either solution, but this is really suboptimal as it is now. Jira tasks essentially depend on Nokia, and if Nokia does not have time, man power and so forth: the Qt Project community is stuck. This should not remain this way, and we should begin to address this issue already now. I would appreciate to take this help request seriously as soon as possible, please! Thanks a lot in advance. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On QML, ownership, QObject-trees and QSharedPointer
Hi Rene,
I certainly agree that constructive discussion about the QML language and ways
that it could be improved are important. You raise a lot of important points,
some of which will be addressed in Qt5.0, some of which we still need to
consider how to fix, and what priority they should be, for future minor
releases of Qt.
More comments inline (some sections removed for brevity).
OWNERSHIP...
These are the ownership universes (unless I'm mistaken):
1) Objects created in C++ owned via the QObject parent/child tree
e.g.: new MyGizmo.
2) Objects created in C++ owned via the QSharedPointer system, e.g.:
QSharedPointer (new MyGizmo).
3) Objects created by QDeclarativeEngine or Javascript owned by the engine,
e.g.: MyGizmo { ... properties ... }
Question: How can we expose objects governed by QSharedPointer to QML
safely? I *can* guarantee the lifecycle beyond the life of my
QDeclarativeEngine.
Currently, QML isn't aware of QSharedPointer and friends, but internally uses
its own guard-types to react to QObject deletion.
If you want to ensure that the engine won't delete the QObject you pass in, you
need to explicitly set the ownership of the QObject to CppOwnership (there's a
QQmlEngine function to do so).
Alternatively, if the QObject has a parent (ownership parent) set, the engine
won't delete it.
These are the ways to transfer values/references from C++ to QML (let's
ignore the other way around for now):
A) By calling QDeclarative::setRootContext (ownership not transferred:
http://qt-project.org/doc/qt-
4.8/qdeclarativecontext.html#setContextProperty).
B) By calling QObject::setProperty on the instantiated component
(ownership?)
C) By QML calling a method on a C++ object and getting a response
(ownership IS transferred to QML. In the docs somewhere.)
D) By QML accessing a Q_PROPERTY on a C++ object (ownership?).
Now, A+B lend themselves badly as mechanisms to expose subobjects, but
makes it easy to specify ownership via
QDeclarativeEngine::setObjectOwnership.
Conversely C+D are better at exposing subobjects or related collections (in
QML... myProperty: myGizmo.findAllTimelineEvents() ), but I don't see how I
can specify ownership in a QML-agnostic way (C++ models should not know
about QML!)
I don't understand your last point. What do you mean in a QML-agnostic way?
The QML engine respects normal QObject parenting.
You are correct about (c) by the way: if the QObject returned from a
Q_INVOKABLE function to JS does not have CppOwnership explicitly set, it will
become JavaScriptOwnership owned. To avoid that, you can explicitly set the
ownership semantic prior to returning it.
With (b) ownership is not transferred. However, it should be noted that if you
define a QObject-derived-type property in QML with its value declared (ie, via
property Item propName: Item { id: child }) that property's QObject value
will be owned by the object with the propName property. But this isn't
directly related to interacting with QML from C++, and so is probably unrelated
to what you are talking about.
Question: What happens to ownership in each of these transfers?
To summarise:
a) no ownership change
b) no ownership change
c) ownership change if ownership semantics were not previously explicitly set
d) no ownership change
TYPESYSTEM...
Then there is the issue of what type is associated with the object.
This is relevant when specifying properties in QML. I believe that a major
source of confusion comes from the notion that there are three type
systems involved:
1) The traditional Qt/C++ moc/compiler types (perhaps QObjects, perhaps
declared Q_DECLARE_METATYPE to make QVariant understand them)
2) The types that the Javascript engine knows (Object, Function, Number,
String etc.)
3) The types that the QML engine understands (http://doc-snapshot.qt-
project.org/4.8/qdeclarativebasictypes.html
plus those registered with qmlRegisterType). QVariants can be used too.
Question: Are there 2 or 3 typesystems?
I guess it depends on how you define the term.
There are only two property types that the QML engine understands: JavaScript
vars, and QVariant properties.
It just happens that it builds type information from the loaded component set,
and enforces type safety when assigning to properties of those types (which is
why you cannot assign an Item {} to a property of type Rectangle).
But internally, all properties are stored as either QVariants or JavaScript
vars.
I assume that each time a value crosses a boundary between from C++ =
QML = Javascript an automatic conversion takes place. This conversion is
probably the root of all evils, since a lot can happen with pointer references
being smashed to either some form of null (as in unsuccessful C++ to QML
assignment via (A) or (B) above) or undefined (like when a javascript
expression tries to access a QML Component property) depending on factors
not quite clear to me.
Question:
[Development] QtSDK4.8 build options
Hi everyone, I have some questions about QTSDK4.8: 1)Are the libs used in QTSDK4.8 built from qt-everywhere-opensource? 2)if 1) is yes, is there anybody can tell me the total build options for the QTSDK4.8's libs building? Any help will be appreciated! Thanks! -- -??- -- Regards Zhang Da Wei A new email address of FJWAN is launched from Apr.1 2007. The updated address is: zhan...@cn.fujitsu.com -- Zhang Da Wei Development Dept.III Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No. 6 Wenzhu Road, Nanjing, 210012, China, Nanjing, 210012, China TEL: +86+25-79988633-8785 COINS: 79955-8227 MAIL: zhan...@cn.fujitsu.com - This communication is for use by the intended recipient(s) only and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not an intended recipient of this communication, you are hereby notified that any dissemination, distribution or copying hereof is strictly prohibited. If you have received this communication in error, please notify me by reply e-mail, permanently delete this communication from your system, and destroy any hard copies you may have printed ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing input for eglfs and friends
Hi, Please do not merge the plug-ins. A monolithic evdev monster plug-in is not desirable and would certainly not classify as generic anymore. The static device discovery should check the supported event types from the devices (this needs opening, an ioctl, and some bittesting so might not be lightning fast but on specific udev-less embedded devices it could be good enough). This is exactly what udev does too when it decides the device class (ID_INPUT_*). Although I'm not sure about the value this feature brings: if the embedded system does not have udev then its input device configuration is likely to be quite static so a simple hardcoded specification of the device nodes should be enough. Furthermore sending key events from mouse buttons is not acceptable in any case. There might also be other type of input devices under /dev/input (sensors, tablets, etc.) so the classification cannot be avoided. I somewhat disagree on the broken out of the box experience too: Specifying what input devices to use via -plugin parameters is perfectly fine on an embedded device because you will typically know what type of devices are or can get connected. Those special multi class devices (like the scrollwheel on keyboard example) will usually result in multiple device nodes under /dev/input, one providing key events, the other the pointer ones. Cheers, Laszlo From: development-bounces+laszlo.p.agocs=nokia@qt-project.org [development-bounces+laszlo.p.agocs=nokia@qt-project.org] on behalf of Zellner Johannes (Nokia-DXM/SiliconValley) Sent: Wednesday, May 23, 2012 11:36 PM To: development@qt-project.org Subject: [Development] Fixing input for eglfs and friends Hi, as we are working on better support of embedded devices in Qt, we also are tapping into the input handling. The initial issue with our current input handling for platforms like eglfs, which do not handle input on its own, is, that we have input plugins for mouse/keyboard/touch (evdev), which are seperate from each other. So one needs to specify -plugin evdevkeyboard on the commandline in order to get keyboard input. The evdev* plugins are trying to use udev to detect all available devices and also handle the remove and add events for such input devices. To get rid of the -plugin argument we would like to create the keyboard/mouse/touch plugins always from eglfs directly. This works fine when udev is present, but fails badly without udev, as all plugins currently default to event0, if you dont specify the device explicitly again on the commandline. A fix would be to add a fallback device discovery, which picks up all available devices without udev and creates the specific keyboard/mouse handler. But this raised the problem of the lack of detecting if its a keyboard or mouse or whatever from the evdev side, as evdev does not have such a destinction. It just handles input events and does not care if its a key or mouse event. Thus udev has some tricks to probe different attributes through evdev to get the device type, which I dont really want to pull into our code. For those reasons, I will go ahead and merge evdevkeyboard and evdevmouse as a start. The merge potentially also adds the ability to properly send key and mouse events from devices, that have both event types (like a scroll wheel on the keyboard) I cannot merge evdevtouch for now, since I dont have a proper touchdevice to test with. Also the udev part in platformsupport will get a fallback to detect devices at startup. Are there any concerns or better ways to solve the currently broken out-of-the box experience with eglfs and such? Johannes ___ 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] Qt5 binary installers
Hi, Finally there is some progress with the bin packaging. There is now jenkins creating desktop installers twice a day, if there is change in git. Currently it detects the git 7 am and pm (GMT +2). First it creates the beta src package (http://origin.releases.qt-project.org/qt5.0-beta-latest/), which is then built on Linux, Win and Mac. All latest installers can and will be found from here: http://releases.qt-project.org/qt5.0-beta-bin-latest/ BUT, there is still some buts… - The replication to that dir takes a while atm, hopefully we can fix it today. Currently there is only one installer from Yesterday visible - Win packages are still pending one additional python module. After that get installed you should see msvc2010 package in that dir. - Mac packages will get enabled as soon as we get the Mac node online. - The used src config, SHOULD be available if one installs also sources with the installers. I will modify this, and make the sha1 more clearly visible. Linux packages are built on Ubuntu 10.04, 11.10 and 12.04. All including 64 and 32 bit versions. Windows is 32 bit Win7 (Danimo, please correct if I'm wrong) Linux binaries are built as shadow from top level pro file. Running the configure and then running make + make install for each sub module in the order stated in generated Makefile. Currently webkit+webkit-examples are the ones which do not compile. Mac binaries will be built as in src, but also from top level pro file. Configure + make for each submodule separately. Win binaries are built with the build perl script. The installers are based on Installer-framework. Currently the ci is using static version of it (from Jan), but hopefully we can fix that also in the future. The SDK packaging scripts and configurations will be in qtrepotools. Once I get all nodes up an running I will start bootstrapping those directly from there. Currently those are updated manually. So as a summary, there is still lots of things to do but now there is at least something visible. Simo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
