Re: [Development] Backporting the Keccak change

[Thiago Macieira]

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) additionally backport 12c5264d9add1826d543c36d893db77262195fc6 to both
> >  5.6> 
> > and 5.9, with the proper binary compatibility notices, so that people who
> > need to can adapt their code to calculate Keccak. It won't be pretty, but
> > it will work.
> > 
> > I'm actually leaning towards (a) for 5.6 and (b) for 5.9.
> 
> b) isn't legitimate for 5.9, either, as we can't add new api in a patch
> release (forward compat promise). so it would be a) for 5.9, too. the
> unfortunate effect is that this is a behavior change against 5.9.0, but
> 5.9.2+ will certainly have a longer lifetime than 5.9.x so far.

While technically correct, I think this one is worth breaking the promise. 
Please note that we will break the promise anyway by adding 
QOperatingSystemVersion::AndroidOreo and we did it already for 5.9.1 for 
QOperatingSystemVersion::MacOSHighSierra. You can blame MSVC 2013 for this 
need.

Reverting the SHA3 calculation might not be such a bad idea, though.


> if we wanted to be really conservative, we'd leave the old meaning of
> the sha3 constants and introduce realSha3 (or something to that effect)
> instead, in 5.10+. keccak aliases would be also provided for a smooth
> migration.

Yeah, we can do that and we can also provide a #define to opt-in or out-opt of 
the real SHA3. Having people add a #define to their code if they need to keep 
compatibility is much easier than using an enumerator that isn't yet present 
in any released version.

So I agree with Ossi here. I suggest we do:
 a) revert the previous enumeration values to calculate Keccak
 b) accept a forwards BC break by adding new values for SHA3
 c) introduce a macro so people who need algorithm compatibility across 
  versions can opt-in without introducing ugly #if in their code

-- 
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

Re: [Development] Adding Qt CoAP

[Jędrzej Nowacki]

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 these modules are quite distinct, so joining them would 
not give any adventage to our users nor us apart of a good feeling of grouping 
things together.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the Keccak change

[Oswald Buddenhagen]

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, with the proper binary compatibility notices, so that people who 
> need 
> to can adapt their code to calculate Keccak. It won't be pretty, but it will 
> work.
> 
> I'm actually leaning towards (a) for 5.6 and (b) for 5.9.
> 
b) isn't legitimate for 5.9, either, as we can't add new api in a patch
release (forward compat promise). so it would be a) for 5.9, too. the
unfortunate effect is that this is a behavior change against 5.9.0, but
5.9.2+ will certainly have a longer lifetime than 5.9.x so far.

if we wanted to be really conservative, we'd leave the old meaning of
the sha3 constants and introduce realSha3 (or something to that effect)
instead, in 5.10+. keccak aliases would be also provided for a smooth
migration.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

[Lisandro Damián Nicanor Pérez Meyer]

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 can configure the input
method
> via qtconfig too. For Qt5 I haven't found anything. In the end I did
rename
> ibus- daemon and ibus-x11, and only then found there's a package called
> im-config where you can configure this. Annoyingly I didn't write down
> exactly where that was on by Ubuntu rig, and judging from the file date it
> was not the
> /etc/defaults/im_config file I thought I remembered it was :-/
>
I am on Debian and found the same thing. Apt-get remove im-config solves the
issue. Apparently it is a buggy package that forces Qt to use ibus without
ensuring ibus is launched.

Btw. In a similar vain of packages having a negative impact on Qt. I also
recomment uninstalling at-spi2-core which sets the environment variable to
force accessibility always on which has a big negative performance impact.


Would it be possible to measure, demonstrate and/or explain the reasons for
this performance impact? It might be of help to convince people to try to
find a better way to only set this variable when needed.

Thanks in advance!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

[Lisandro Damián Nicanor Pérez Meyer]

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
> > accessibility interfaces at runtime. On macOS and Windows, the same
> > performance impact is only enabled if you start using a system
> > accessibility feature.
> 
> That's possibly it. A11y team: do you think we can start this only if the
> right hardware is detected?

I have just filled a [debian bug] for this. Allan and everyone: please do 
never hesitate in filing bugs against Debian packages for this or any other 
bug/sugegstion/performance issue you might find. We are mostly 2 people behind 
Qt but really try to give our users the best experience we can.

Pinging me or mitya57 on IRC is also a valid thing to do :-)

Thanks!

[debian bug] 


-- 
http://mx.grulic.org.ar/lurker/message/20081108.174208.4f42e55c.es.html
Así se corrobora el software legal en Argentina

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt/XCB applications and deadkeys and ibus (which cease working) (and sometimes the entire keyboard in Konsole)

[Lisandro Damián Nicanor Pérez Meyer]

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 package that forces Qt to use ibus
> > > without ensuring ibus is launched.
> > 
> > That's not what I saw. Ibus was always launched at login, and im-config
> > seems to get some length to ensure that applications always use the "best"
> > method available if the user didn't configure things to use a specific
> > method. That's why newly launched Qt applications work fine after exiting
> > ibus. The loss of keyboard input in Qt5 applications is a priori not a
> > packaging fault but a regression in Qt itself.
> > 
> > > Btw. In a similar vain of packages having a negative impact on Qt. I
> > > also
> > > recomment uninstalling at-spi2-core which sets the environment variable
> > > to
> > > force accessibility always on which has a big negative performance
> > > impact.

Right. We where asked to turn it on by default by the a11y team (CCIng). 
Granted we did not know it meant that it will have such a negative impact in 
performance.

> > Thanks for the suggestion, at least I could uninstall that one without
> > taking a sh*load of other packages along with it...
> > What env. variable would that be (I don't want to log off and on AGAIN
> > just
> > yet
> > 
> > :))
> 
> 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
> accessibility interfaces at runtime. On macOS and Windows, the same
> performance impact is only enabled if you start using a system accessibility
> feature.

That's possibly it. A11y team: do you think we can start this only if the 
right hardware is detected?


-- 
Mi experiencia me dice que lo que la gente quiere y necesita -en Indonesia, en
Turquía, en Italia, en los Estados Unidos, en Brasil, en la Argentina o donde
sea- es básicamente lo mismo. La gente quiere comida en la mesa, una vivienda
básica, un gobierno que funcione, que en las fuerzas de seguridad haya
personas confiables, a las que no tengan que tenerles miedo, educación y
salud. ¡La gente de todo el mundo quiere lo mismo!
  Padre Thomas Michel, jesuita, especialista en diálogo interreligioso,
  en una entrevista de Elisabetta Piqué para La Nación, 27/09/2006.
  http://www.lanacion.com.ar/844069

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] HEADS-UP: Branching from 'dev' to '5.10' completed

[Jani Heikkinen]

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 Frederik Gladhorn (Ossi is on 
vacation).

br,
Jani


From: Development 
[mailto:development-bounces+jani.heikkinen=qt...@qt-project.org] On Behalf Of 
Jani Heikkinen
Sent: sunnuntai 27. elokuuta 2017 12.02
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: [Development] HEADS-UP: Branching from 'dev' to '5.10' started

HI all,


We have finally soft branched '5.10' from 'dev'. Target is to have final 
downmerge from 'dev' to '5.10'  Friday 1st September



Please finalize ongoing changes in 'dev' and start using '5.10' for new changes 
targeted to Qt 5.10.0 release.



br,

Jani Heikkinen

Release Manager

The Qt Company



___
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] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

[René J . V . Bertin]

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 ML (re: a style's simple animation 
timer 
that I'd like to be able to start on demand only, IOW from 
Style::drawControl()).

R.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development