Re: [Development] QUrl setPath Qt4 vs Qt5
Just for completeness ;) https://bugreports.qt-project.org/browse/QTBUG-27728 On Sep 28, 2014, at 9:52 AM, Samuel Gaist samuel.ga...@edeltech.ch wrote: On 28 sept. 2014, at 03:26, Thiago Macieira thiago.macie...@intel.com wrote: On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote: Hi, Following a post on the forum, I've checked and there's been a behavior change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the C++ API changes chapter. If I understood correctly: QUrl example1(http://www.example.com;); example1.setPath(pub/something); makes example1 invalid in Qt 5 due to the fact that pub/something is a relative path (following QUrl documentation and test) but in Qt 4 the result is http://www.example.com/pub/something;. Should it be considered bug in Qt 4 that needs fixing ? However fixing it might break existing application that could be relying on that behavior. In this case, simply add the API break in Qt 5's documentation ? Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important and would require a major change. QUrl in Qt 4 has quite a few known issues with encoding and decoding of delimiters too. And its QString constructor is a completely flawed design and should never be used. QUrl changed considerably in Qt 5 to comply better with the URL specifications and with brokenness out there. If we add anything to the documentation, it would be the previous sentence, with no extra details. I remember now following a discussion about that matter some time ago. Fine for me. I'll update the API change doc to include that so future users won't be surprised. Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUrl setPath Qt4 vs Qt5
On 29 sept. 2014, at 09:08, Ziller Eike eike.zil...@digia.com wrote: Just for completeness ;) https://bugreports.qt-project.org/browse/QTBUG-27728 Thanks :) Since it's a documentation update and 5.4 is not officially out, should I target 5.3 ? On Sep 28, 2014, at 9:52 AM, Samuel Gaist samuel.ga...@edeltech.ch wrote: On 28 sept. 2014, at 03:26, Thiago Macieira thiago.macie...@intel.com wrote: On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote: Hi, Following a post on the forum, I've checked and there's been a behavior change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the C++ API changes chapter. If I understood correctly: QUrl example1(http://www.example.com;); example1.setPath(pub/something); makes example1 invalid in Qt 5 due to the fact that pub/something is a relative path (following QUrl documentation and test) but in Qt 4 the result is http://www.example.com/pub/something;. Should it be considered bug in Qt 4 that needs fixing ? However fixing it might break existing application that could be relying on that behavior. In this case, simply add the API break in Qt 5's documentation ? Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important and would require a major change. QUrl in Qt 4 has quite a few known issues with encoding and decoding of delimiters too. And its QString constructor is a completely flawed design and should never be used. QUrl changed considerably in Qt 5 to comply better with the URL specifications and with brokenness out there. If we add anything to the documentation, it would be the previous sentence, with no extra details. I remember now following a discussion about that matter some time ago. Fine for me. I'll update the API change doc to include that so future users won't be surprised. Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copying QJSValue arrays
On Sunday 28. September 2014 15.17.34 Paul Lemire wrote:
Hi guys,
We're working on being able to set GLSL uniform arrays from QML.
Basically what we have is a QParameter QObject exposed to QML as Parameter.
It contains a QString name property and a QVariant value property.
Here's how it can be used for scalar types.
Parameter { name : uniformName; value : 1.0; }
What we want is to send a copy of value to our backend renderer, so that we
won't have any problem with threading. For scalar types, the copy is done
implicitly.
For array types, we'd like to be able to do something like that:
property var myArray : [1.0, 1.0, 1.0]
Parameter { name : uniformArray; value : myArray }
However in that case, value is a QJSValue containing a JS Array object.
We need a way to be able to copy that object.
The tricky part there is that we can't check the QVariant to to see if it
contains a QJSValue directly as we don't want to introduce a dependency to
the QML module.
We're thinking of maybe introducing a Qt.array helper function that would
return us a copy of the array directly or retrieve a QVectorQVariant.
If you've got ideas around that issue, please step in.
If you don't want to depend on QtQml (which seems odd for a library that offers
Qml bindings), then what you could do is utilize the conversion functions. So
after checking your QVariant for all other types you're interested in
supporting, you can try
canConvertQVariantList()
and afterwards convert to that. This will trigger a registered conversion
function that will convert the JavaScript array object, that the QJSValue
wraps, into a QVariant list that is not dependent on the JS engine anymore.
A QJSValue wrapped in a QVariant is (through QVariant) API always convertible
to a QVariantList and a QVariantMap - it's a shortcut to writing
qvariant_castQJSValue(variant).toVariant().valueTypeYouWant();
without using QJSValue. Due to the custom conversion functions being
unconditional you can however not distinguish between a regular JavaScript
object or an array. Therefore if the property contains an object the
conversion to an array will cause a loss of data.
If you don't want to loose any data, you're going to have to support the types
the QVariant can contain, and that includes direct support for QJSValue.
Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] clang-analyzer and qbs projects
Is there any way to analyze qbs projects with clang-analyzer? Отправлено с Почта Windows___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-analyzer and qbs projects
On 09/29/2014 09:29 AM, gorthaue...@yandex.ru wrote: Is there any way to analyze qbs projects with clang-analyzer? A cursory glance at how clang-analyzer works suggests it should be enough to set cpp.compilerPath to the location of the c++-analyzer tool (for C++ projects) and make sure the right compiler is found via PATH. Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copying QJSValue arrays
Hi Simon,
On Monday 29 Sep 2014 09:20:00 Simon Hausmann wrote:
On Sunday 28. September 2014 15.17.34 Paul Lemire wrote:
We're working on being able to set GLSL uniform arrays from QML.
Basically what we have is a QParameter QObject exposed to QML as
Parameter.
It contains a QString name property and a QVariant value property.
Here's how it can be used for scalar types.
Parameter { name : uniformName; value : 1.0; }
What we want is to send a copy of value to our backend renderer, so that
we
won't have any problem with threading. For scalar types, the copy is done
implicitly.
For array types, we'd like to be able to do something like that:
property var myArray : [1.0, 1.0, 1.0]
Parameter { name : uniformArray; value : myArray }
However in that case, value is a QJSValue containing a JS Array object.
We need a way to be able to copy that object.
The tricky part there is that we can't check the QVariant to to see if it
contains a QJSValue directly as we don't want to introduce a dependency to
the QML module.
We're thinking of maybe introducing a Qt.array helper function that would
return us a copy of the array directly or retrieve a QVectorQVariant.
If you've got ideas around that issue, please step in.
If you don't want to depend on QtQml (which seems odd for a library that
offers Qml bindings), then what you could do is utilize the conversion
functions.
Yeah it sounds odd. The reason is that we hope to offer both C++ and QML apis
for Qt3D where the plain C++ interface doesn't depend upon QtQml.
So after checking your QVariant for all other types you're
interested in supporting, you can try
canConvertQVariantList()
and afterwards convert to that. This will trigger a registered conversion
function that will convert the JavaScript array object, that the QJSValue
wraps, into a QVariant list that is not dependent on the JS engine anymore.
A QJSValue wrapped in a QVariant is (through QVariant) API always
convertible to a QVariantList and a QVariantMap - it's a shortcut to
writing
qvariant_castQJSValue(variant).toVariant().valueTypeYouWant();
without using QJSValue. Due to the custom conversion functions being
unconditional you can however not distinguish between a regular JavaScript
object or an array. Therefore if the property contains an object the
conversion to an array will cause a loss of data.
If you don't want to loose any data, you're going to have to support the
types the QVariant can contain, and that includes direct support for
QJSValue.
Right. We're also considering having the property setter function call a
helper virtual which in C++ lib does nothing but in the QML dependent lib
takes care of extracting and copying the data.
Thank you for your ideas.
Sean
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Wednesday 24. September 2014 23.10.01 BogDan wrote: [...] Hi, Do we all agree that the singletons, by definition, must be available to any object at any time until the end of the application? Yes, with emphasis on until. Note that we are now talking about the end of the application situation, so our agreement ends right there ;-). We are talking about the time the QQmlEngine destructor is executed, which from a QML engine perspective is the end of the application point of time. What happens during that period of time is just as fishy as when tearing down a C++ application: The order of destruction for global objects between several compilation units is undefined. In C++ you cannot rely on it (I think you can rely on the order within a unit), so you prepare yourself with levels of indirection and/or weak references. Right now the order of destruction in the QML engine is defined like this (by the existence of one implementation only): 1) Singletons are deleted first 2) The remaining JavaScript objects are deleted at random We can't change (2) really and we can't swap step 1 and 2 because it breaks for singletons that _are_ JavaScript objects. (to be continued further down) IMHO deleting first the QML singletons then the rest of the Active objects is also wrong, because some of the active objects might need these singletons. I think the right way is to delete all the active objects first, then QML singletons, try delete again all the active objects (supposing that the QML singletons will create new objects in Component.onDestruction), then at the very end, all the C++ singletons. IMHO this is the right way to do it, and is not a hack at all. Doing something right, even if it's harder, is not a hack ... And I feel that this is trying to solve a problem at the wrong level, hence me calling it a hack. No doubt we have many hacks in place, but they come at a cost of maintenance and complexity an already complex shutdown procedure. (/me points to qdeclarativeelement_destructor :) . So if we wanted to add this complexity, then I think it needs a better justification. I'm afraid I don't see that yet. At run-time you can rely on the life time of singletons. When the application is being shut down and you rely on a specific order of destruction, then I think you have to take care of it in your application. (And we may be missing tools to achieve that) Note that this is separate from the order of destruction between singletons - here it might makes sense to implement destruction in reversal to construction, although construction is non-deterministic from the framework's point of view. I don't see how using a weak pointer will fix the problem, who will delete the singleton object in the end? As we have established earlier, the singleton _does_ get deleted by the engine. The subject of this email thread gives it away :). Hmm, I apologize, I may have misunderstood or rather misinterpreted an earlier statement of yours about what's happening. I understood active objects may still need to access the singletons in their destructor as pointer based access and I (perhaps mistakenly?) concluded that you're experiencing crashes from users of the singleton _to_ the singleton due to dangling pointers. If that's not the case, could you elaborate a bit on what kind of access this is? I can't reference it for every object that depends on it, because, BTW, there are cases when the VM doesn't delete all the objects! Yes it has lots of memleaks at the end! What are you trying to say here? Is throwing mud supposed to motivate and convince me? :( If there are memory leaks, then I think we agree that those should be fixed. In this email thread we are talking about semantics during engine shutdown. At this point it's your word against mine :). You can try to convince me to invest time to implement the behavior you'd like. You can try to implement it yourself and convince me or some other approver to approve the change. Or you can try to convince somebody else to implement the change. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Mon, 29 Sep 2014, Simon Hausmann wrote: Yes, with emphasis on until. Note that we are now talking about the end of the application situation, so our agreement ends right there ;-). We are talking about the time the QQmlEngine destructor is executed, which from a QML engine perspective is the end of the application point of time. What happens during that period of time is just as fishy as when tearing down a C++ application: The order of destruction for global objects between several compilation units is undefined. In C++ you cannot rely on it (I think you can rely on the order within a unit), so you prepare yourself with levels of indirection and/or weak references. I was thinking the same for a long time. Until I discovered (the hard way) a that at least one aspect of the C++ behavior is standardized: the order of destruction is guaranteed to be the reverse of the construction (see [basic.start.term]). I ran into this because of a singleton being encapsuled within a function using a 'static' object. The crashes upon application exit seemed arbitrary at first but turned out to be well-defined :) Which deletion order is the best for QML... maybe it can't be changed anymore. I'd just generally vouch for a *defined* order (even if problematic) rather than an undefined one. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Monday, September 29, 2014 04:16:05 PM Harri Porten wrote: On Mon, 29 Sep 2014, Simon Hausmann wrote: Yes, with emphasis on until. Note that we are now talking about the end of the application situation, so our agreement ends right there ;-). We are talking about the time the QQmlEngine destructor is executed, which from a QML engine perspective is the end of the application point of time. What happens during that period of time is just as fishy as when tearing down a C++ application: The order of destruction for global objects between several compilation units is undefined. In C++ you cannot rely on it (I think you can rely on the order within a unit), so you prepare yourself with levels of indirection and/or weak references. I was thinking the same for a long time. Until I discovered (the hard way) a that at least one aspect of the C++ behavior is standardized: the order of destruction is guaranteed to be the reverse of the construction (see [basic.start.term]). I ran into this because of a singleton being encapsuled within a function using a 'static' object. The crashes upon application exit seemed arbitrary at first but turned out to be well-defined :) Which deletion order is the best for QML... maybe it can't be changed anymore. I'd just generally vouch for a *defined* order (even if problematic) rather than an undefined one. Right, that makes sense. In C++ the problem stems from the diversity of compilers, which we (unfortunately :) don't have with Qml. There is only one implementation and it defines the behavior. The question is how much we want to change the behavior. We could implement a reverse order destruction, if somebody makes a good case for it. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform maintainers
Hi, On Friday 26 September 2014 18:01:55 Robin Burchell wrote: On Fri, Sep 26, 2014 at 5:17 PM, Nichols Andy andy.nich...@digia.com wrote: My suggestions for replacement would be either Giulio Camuffo who as been main driver for the QtWayland project this year, or Jorgen Lind who was the previous QtWayland maintainer and who still has a deep interest in the project. +1 to either, but I have to say I'd lean towards a +2 for Giulio simply because he is more focused on Wayland, whereas Jørgen has many other things on his plate already (from what I've seen going around in Gerrit). Giulio has an extensive knowledge base in the area, and has proven a real asset in the time he's been working actively on QtWayland QtCompositor. (No offence intended to Jørgen if my understanding of the situation is incorrect!) Non taken :) Giulio has driven much of the QtWayland development for 3/4 of a year now, and I think he is a good fit for as the maintainer. I can be the maintainer if he does not want it, as I intend to pick up QtWayland development again. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform maintainers
On Monday 29 September 2014 18:22:22 Jorgen Lind wrote: Giulio has driven much of the QtWayland development for 3/4 of a year now, and I think he is a good fit for as the maintainer. I can be the maintainer if he does not want it, as I intend to pick up QtWayland development again. Given that, I hereby nominate Giulio Camuffo as the qtwayland maintainer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
