Getting back to the topic of these releases - what is our decision?
Shall we do the RC2 as proposed, but with shmget fix in 4.7.6, and later go to
release unless problems are found? This would mean we accept that there is not
perfect history available and that we trust the way changes were che
On Sat, Feb 23, 2013 at 12:29 PM, Thiago Macieira
wrote:
> I haven't seen any patches fixing warnings or compilation errors come in for
> 4.8. Usually, there are a few warnings that need fixing but until my -Werror
> patches land, those are not stoppers.
>
> Usually, there are no compilation error
On sábado, 23 de fevereiro de 2013 09.40.09, David Narvaez wrote:
> Hi,
>
> Is anybody currently working on compatibility with GCC 4.8? I know
> that, at the moment, qtdelcarative (stable) can be built with GCC 4.8
> and qtbase (stable) cannot; and I'd like to know if anybody has a
> branch where t
On sábado, 23 de fevereiro de 2013 20.26.11, Sze Howe Koh wrote:
> On 23 February 2013 00:11, Thiago Macieira
wrote:
> > The fact is that any QObject that is returned from those functions -- if
> > any -- must belong to the calling thread. That implies the necessary
> > guarantees in terms of sign
On 21 February 2013 01:07, Thiago Macieira wrote:
> Conclusion:
>
> There are risks associated with this fix, including a change of behaviour.
> Those are well understood and are deemed acceptable in face of the fix itself.
Just to say, that I agree with this. The fix should be included in any
po
Hello,
in a few days I would like to stage
https://codereview.qt-project.org/48657
which will cause QOpenGLShaderProgram to ignore QT_OPENGL_ES (defined at
build time) and rely on renderable type returned from the current
context (via QOpenGLContext::format()).
This means that platform plu
Hi,
Is anybody currently working on compatibility with GCC 4.8? I know
that, at the moment, qtdelcarative (stable) can be built with GCC 4.8
and qtbase (stable) cannot; and I'd like to know if anybody has a
branch where this is being fixed.
David E. Narváez
___
Anybody made fully working patch for Qt Multimedia and gstreamer 1.0
any progress with this
https://codereview.qt-project.org/#change,37266
--
Best Regards
Michal Lazo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org
On 23 February 2013 00:11, Thiago Macieira wrote:
> The fact is that any QObject that is returned from those functions -- if any
> -- must belong to the calling thread. That implies the necessary guarantees in
> terms of signal emissions.
>
> For example, if the functions return a QObject pointer,
On 22 February 2013 21:31, Corentin Jabot wrote:
> Here again, two different issues.
> 1/ can we use the c++11 features and variadic templates
> for the biding part.
> 2/ should we use the c++11 thread api somehow ( that looks like a huge
> - unnecessary ? - change )
I don't think there's a need
On 22 February 2013 21:58, André Somers wrote:
> Op 22-2-2013 14:31, Corentin Jabot schreef:
>> Think about QNetworkAccessManager :
>> reply = nam->get(url); // start the request
>> connect(reply, QNetworkReply::finished(), doSomething()); // you can
>> connect later
>>
>> I think that work just f
On 22 February 2013 20:06, André Somers wrote:
> I don't really like the need to create a watcher in order to get a
> signal at all, to be honest. Never did.
>
> My own implementation of a task-based system that I recently did,
> involved returning a QSharedPointer from the task manager. Task
> de
Am 22.02.2013 um 19:13 schrieb Thiago Macieira :
> Note that we changed again the release procedures after complaints on how we
> handled 5.0.1.
>
> There will be no 5.0.2 tags until the final release.
I have updated the reference version, the next coverage report will have as
base Qt5.0.1 (n
13 matches
Mail list logo
