On Saturday, 2 September 2017 12:03:13 PDT Oswald Buddenhagen wrote:
> On Wed, Aug 30, 2017 at 12:45:44PM -0700, Thiago Macieira wrote:
> > a) revert the 5.6 backport of 88a8feeacb9bdaff9ee06164424e407eb904cd10 so
> >
> > that 5.6.x will forever calculate Keccak, not SHA3;
> >
> > b)
On piątek, 1 września 2017 08:38:19 CEST Thiago Macieira wrote:
> I'm also wondering if we shouldn't have a bigger repo for IoT-related
> things, instead of creating a small one for each thing.
Currently, from CI and releasing perspective heaving dozen of small repos is
easier and faster. All
On Wed, Aug 30, 2017 at 12:45:44PM -0700, Thiago Macieira wrote:
> a) revert the 5.6 backport of 88a8feeacb9bdaff9ee06164424e407eb904cd10 so
> that 5.6.x will forever calculate Keccak, not SHA3;
>
> b) additionally backport 12c5264d9add1826d543c36d893db77262195fc6 to both
> 5.6
> and 5.9,
El 12 jun. 2017 5:09 a.m., "Allan Sandfeld Jensen"
escribió:
On Montag, 12. Juni 2017 09:49:43 CEST René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > Check your environment. You must have something that tells Qt to use it.
>
> For Qt4 there's QT4_IM_MODULE indeed, and you
On sábado, 2 de septiembre de 2017 10:51:08 -03 you wrote:
[snip]
> > QT_LINUX_ACCESSIBILITY_ALWAYS_ON
> >
> > It forces Qt to send accessibility events with new content trees
> > everything
> > something changes.
> >
> > Though the real problem might be that Linux lacks a good way to enable
> >
On lunes, 12 de junio de 2017 10:32:17 -03 Allan Sandfeld Jensen wrote:
> On Montag, 12. Juni 2017 10:17:50 CEST René J. V. Bertin wrote:
> > Allan Sandfeld Jensen wrote:
> > > I am on Debian and found the same thing. Apt-get remove im-config solves
> > > the issue. Apparently it is a buggy
Hi all,
We have completed branching from 'dev' to '5.10' today. From now on 'dev' is
for Qt 5.11 and all changes targeted to Qt 5.10 release must be done in '5.10'
instead.
If you still have some change open in 'dev' and it must be in Qt 5.10 release
you need to send a re-targeting request to
Coming back startTimer()/killTimer(): I don't think they modify any externally
visible class state, do they? If not, would it be possible (and acceptable) to
add const versions (or mark them const) so that they can be called from a const
member function?
I just asked about this on the interest