Re: [Development] Qt 5.2.1 Release Candidate available
And packages are now here: http://download.qt-project.org/community_releases/additional_qt_src_pkgs/ Br, Jani -Original Message- From: development-bounces+jani.heikkinen=digia@qt-project.org [mailto:development-bounces+jani.heikkinen=digia@qt-project.org] On Behalf Of Heikkinen Jani Sent: 31. tammikuuta 2014 7:58 To: Thiago Macieira; development@qt-project.org Subject: Re: [Development] Qt 5.2.1 Release Candidate available OK, I'll copy these somewhere later today Br, Jani -Original Message- From: development-bounces+jani.heikkinen=digia@qt-project.org [mailto:development-bounces+jani.heikkinen=digia@qt-project.org] On Behalf Of Thiago Macieira Sent: 31. tammikuuta 2014 2:59 To: development@qt-project.org Subject: Re: [Development] Qt 5.2.1 Release Candidate available On quarta-feira, 29 de janeiro de 2014 12:30:10, Thiago Macieira wrote: On quarta-feira, 29 de janeiro de 2014 18:55:53, Sergio Ahumada wrote: I fail to see how is this related to Qt 5.2.1 Are you sure a git build doesn't work? Even if it doesn't, that would need to be fixed in qtftp/qthttp That's the nature of the bug report: an extracted .tar.gz from gitorious.org does not build. If you use git clone, it does. All this takes is that someone create the correct .tar.gz and .zip. I've already volunteered to do it if someone can give me the instructions on how to build source packages. I'm calling it a showstopper for Qt because it used to work with 5.0. It's a Qt 5.1 regression that has gone unfixed. Release files ready: http://macieira.org/~thiago/tmp/ Someone with the appropriate rights, please download them from there and place somewhere in qt-project.org mirrors. I've also pushed v5.0.0 tags to the respective repositories. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Need suggestion for a new API
Hi All, I needed a suggestion on an API I'm adding to QNetworkAccessManager and co. I'm adding a HTTP redirect feature to QNAM. It can be enabled at a global (QNAM) level, or can be enabled/disabled on a per request (QNetworkRequest) basis. The per-request setting, if set, overrides the global one otherwise uses whatever is set in the global setting. The default value of the global setting is false, i.e don't follow redirects. The QNAM setting can be a simple bool which defaults to 'false' if not explicitly set by the user. However, the request level setting needs 3 states - true (follow redirects), false (don't follow) and unset (use global setting). I was thinking I can have the request level setting as a 'pointer to a bool' which is uninitialized (NULL) if a user does NOT explicitly set the behaviour for the request or is initialized to whatever value is passed (true/false). But this would mean allocating space for a pointer etc, though I can manage it with a scoped pointer. Or else I could have an enum in the request class identifying these 3 states (I don't want to add an enum for such a simple thing). Any other suggestions on how this could be handled? Thanks, -mandeep ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Need suggestion for a new API
On 01/31/2014 01:47 PM, Mandeep Sandhu wrote: (...) The QNAM setting can be a simple bool which defaults to 'false' if not explicitly set by the user. However, the request level setting needs 3 states - true (follow redirects), false (don't follow) and unset (use global setting). How about enabling the setting on a per-request basis first? In that case, the normal way would be to add a new value to the QNetworkRequest::Attribute enum, and a boolean would be enough I think. In general I also think it would be a good thing to have a way of setting such things globally in QNetworkAccessManager, but that would require some more API in that class then... So maybe we could have 2 commits: One that enables redirect settings on a request first, and then introduce global QNetworkAccessManager settings (which might be some more work)... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] ARM target expertise
Hello, I'd like to know if there is someone on this list who would like to collaborate with me on integrating a class that I've written (qfloat16 Ia52eb278) with the half-precision support offered by gcc on ARM targets. http://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html You can just contact me directly, or submit a review to the patch. Thanks, Glen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Need suggestion for a new API
Mandeep Sandhu schreef op 31-1-2014 13:47: Hi All, I needed a suggestion on an API I'm adding to QNetworkAccessManager and co. I'm adding a HTTP redirect feature to QNAM. It can be enabled at a global (QNAM) level, or can be enabled/disabled on a per request (QNetworkRequest) basis. The per-request setting, if set, overrides the global one otherwise uses whatever is set in the global setting. The default value of the global setting is false, i.e don't follow redirects. The QNAM setting can be a simple bool which defaults to 'false' if not explicitly set by the user. However, the request level setting needs 3 states - true (follow redirects), false (don't follow) and unset (use global setting). I was thinking I can have the request level setting as a 'pointer to a bool' which is uninitialized (NULL) if a user does NOT explicitly set the behaviour for the request or is initialized to whatever value is passed (true/false). But this would mean allocating space for a pointer etc, though I can manage it with a scoped pointer. Or else I could have an enum in the request class identifying these 3 states (I don't want to add an enum for such a simple thing). Any other suggestions on how this could be handled? I don't think that using a pointer to a bool would be good API. myRequest-setFollowRedirects(true); // ok, clear enough, but a bit weird myRequest-setFollowRedirects(false); // ok, clear enough, but a bit weird myRequest-setFollowRedirects(0); //what does this mean? vs. myRequest-setFollowRedirects(QNetworkAccessManager::UseGlobalSetting); //perfectly clear myRequest-setFollowRedirects(QNetworkAccessManager::AlwaysFollow); // perfectly clear myRequest-setFollowRedirects(QNetworkAccessManager::NeverFollow); //perfectly clear myQNam-setFollowRedirects(QNetworkAccessManager::UseGlobalSetting); // undefined, should fail I guess The enum way would be way clearer, and allows for extension later if needed. I would use the same enum at both levels, documenting that using the FollowGlobal value does not make sense at the QNAM level and perhaps using an assert on that one. Note that if you use an enum at the API surface, that does not mean you *have* to use the enum internally as well. Not that a pointer to a bool is smaller than an enum, but... The enum solution would allow for something like this to be added: myRequest-setFollowRedirects(QNetworkAccessManager::OnlyFollowWithinDomain); //if such a thing would make sense André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Need suggestion for a new API
Thanks Matt, André. I totally forgot the fact that QNetworkRequest has attributes for controlling request behavior. It looks like a suitable place for adding redirection control. Peter, I'm also looking at first enabling this on a per-request basis and then extend it to QNAM. By 2 commits, do you mean 2 separate tickets/tasks or just 2 git commits but under the same task? Thanks again. -mandeep On Fri, Jan 31, 2014 at 10:33 PM, Andre Somers an...@familiesomers.nlwrote: Mandeep Sandhu schreef op 31-1-2014 13:47: Hi All, I needed a suggestion on an API I'm adding to QNetworkAccessManager and co. I'm adding a HTTP redirect feature to QNAM. It can be enabled at a global (QNAM) level, or can be enabled/disabled on a per request (QNetworkRequest) basis. The per-request setting, if set, overrides the global one otherwise uses whatever is set in the global setting. The default value of the global setting is false, i.e don't follow redirects. The QNAM setting can be a simple bool which defaults to 'false' if not explicitly set by the user. However, the request level setting needs 3 states - true (follow redirects), false (don't follow) and unset (use global setting). I was thinking I can have the request level setting as a 'pointer to a bool' which is uninitialized (NULL) if a user does NOT explicitly set the behaviour for the request or is initialized to whatever value is passed (true/false). But this would mean allocating space for a pointer etc, though I can manage it with a scoped pointer. Or else I could have an enum in the request class identifying these 3 states (I don't want to add an enum for such a simple thing). Any other suggestions on how this could be handled? I don't think that using a pointer to a bool would be good API. myRequest-setFollowRedirects(true); // ok, clear enough, but a bit weird myRequest-setFollowRedirects(false); // ok, clear enough, but a bit weird myRequest-setFollowRedirects(0); //what does this mean? vs. myRequest-setFollowRedirects(QNetworkAccessManager::UseGlobalSetting); //perfectly clear myRequest-setFollowRedirects(QNetworkAccessManager::AlwaysFollow); // perfectly clear myRequest-setFollowRedirects(QNetworkAccessManager::NeverFollow); //perfectly clear myQNam-setFollowRedirects(QNetworkAccessManager::UseGlobalSetting); // undefined, should fail I guess The enum way would be way clearer, and allows for extension later if needed. I would use the same enum at both levels, documenting that using the FollowGlobal value does not make sense at the QNAM level and perhaps using an assert on that one. Note that if you use an enum at the API surface, that does not mean you *have* to use the enum internally as well. Not that a pointer to a bool is smaller than an enum, but... The enum solution would allow for something like this to be added: myRequest-setFollowRedirects(QNetworkAccessManager::OnlyFollowWithinDomain); //if such a thing would make sense André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2.1 Release Candidate available
Em sex 31 jan 2014, às 08:20:08, Heikkinen Jani escreveu: And packages are now here: http://download.qt-project.org/community_releases/additional_qt_src_pkgs/ Thanks Jani! -- 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
