Re: [Interest] Two candidate updates for 5.3.x

..@qt-project.org] On Behalf Of Thiago Macieira Sent: Monday, May 12, 2014 3:57 PM To: interest@qt-project.org Subject: Re: [Interest] Two candidate updates for 5.3.x Em seg 12 maio 2014, às 15:30:39, Daniel Bowen escreveu: > 1. If -no-gui is specified, qtdiag tries to build, but encounters t

Re: [Interest] Size of libQt5Core in 5.3

Thanks again for the info. Here's where I've gotten to so far. Starting from the last ./configure command line I mentioned, plus -no-feature- for every qfeature.txt item (minus LIBRARY, SETTINGS and REGULAREXPRESSION, since it doesn't build without those), I was at 4.3 MB stripped. Added to the

[Interest] Two candidate updates for 5.3.x

In trying to reduce the size of Qt for an embedded environment, I've run into a couple problems that would be best solved by updates to the source. There was a comment that issues with 5.3.0 RC could be sent to the mailing list here. 1. If -no-gui is specified, qtdiag tries to build, but encounter

Re: [Interest] Size of libQt5Core in 5.3

ay 12, 2014 2:48 AM To: interest@qt-project.org Subject: Re: [Interest] Size of libQt5Core in 5.3 On 11.05.2014 09:20, Daniel Bowen wrote: > I have an embedded environment where we usenon-UI parts of Qt (Qt Core, Qt Networking)on an ARM host processor. > > We’ve been using 4.8.4for a little

[Interest] Size of libQt5Core in 5.3

I have an embedded environment where we use non-UI parts of Qt (Qt Core, Qt Networking) on an ARM host processor. We've been using 4.8.4 for a little while. There's some other changes coming to this code, and we've been looking to move to 5.x with the upcoming 5.3. After working through several is

[Interest] Cross platform Web services server

I'm wondering what other people are using these days for providing web services from a server point of view for embedded devices, where the server code is integrated as a shared library and geared more toward providing RESTful services for a limited number of clients on the local network. Something

Re: [Interest] Relashionship between time_t and QDateTime

One other note: > And since daylight saving transition dates and time tend to slightly drift from > year to year, there's absolutely no guarantees of getting correct time > conversion results; in general case 1-hour error is nearly inevitable. The timezone structure on Windows tracks the ST->DT

Re: [Interest] Relashionship between time_t and QDateTime

> One key is in the "Remarks" section of > SystemTimeToTzSpecificLocalTime()'s documentation > (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724949(v=vs.85).aspx): > > The SystemTimeToTzSpecificLocalTime function may calculate the local time > > incorrectly under the following condit

Re: [Interest] Relashionship between time_t and QDateTime

>From >http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx The MSDN library states: " To account for daylight saving time when converting a file time to a local time, use the following sequence of functions instead of using FileTimeToLocalFileTime: FileTimeToSystemTi

Re: [Interest] Heavily Commented Example: Simple Single Frontend with Two BackendsHi,

> >> Let me state for the record that I do not use volatiles for thread > >> synchronization. But the issue at hand is not whether a volatile > >> can be used for full-featured thread synchronization, but whether > >> it can be used by one thread to signal a second looping thread to > >> quit.