Re: [Development] QLowEnergyController and obsolete ctor
Hi Alex, On Dienstag, 29. August 2017 13:18:02 CEST Alex Blasche wrote: > Hi Martin, > > > -Original Message- > > From: Development [mailto:development- > > bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Martin Koller > > > In Qt 5.9 I find that the following ctor is marked as obsolete: > > > > explicit QLowEnergyController(const QBluetoothAddress &remoteDevice, > > const QBluetoothAddress &localDevice, > > QObject *parent = Q_NULLPTR); // TODO Qt > > 6 remove ctor > > > > but there is no other way to create a QLowEnergyController which does not > > use > > the local default adapter. > > > > How is this supposed to work ? > > The ctor still exists and works. You can use it for Bluetooth Central use > cases. Having two local adapters is a very rare use case and only supported > when using Bluez. That's why it has moved to obsolete. The fix would be to > overload QLEController::createCentral(). Could you file a bug for it and > assign it to me? Done that now: https://bugreports.qt.io/browse/QTBUG-63019 -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Qt CoAP
On Tue, Sep 05, 2017 at 07:49:37PM +0200, Maurice Kalinowski wrote: > > what are you talking about? https://codereview.qt-project.org/201311 is up > > for > > more than a month already. > [Kalinowski Maurice] > And it is visible now after Frederik moved it. As I wrote in my initial mail, > there has been some work done before... > it's still a tad apocryphal to make a repository request in this situation. the admin side doesn't need to be public, while the public side is meant to allow for community veto (which was pre-empted anyway). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Qt CoAP
On Tuesday, 5 September 2017 14:49:37 -03 Maurice Kalinowski wrote: > > what are you talking about? https://codereview.qt-project.org/201311 is up > > for more than a month already. > > [Kalinowski Maurice] > And it is visible now after Frederik moved it. As I wrote in my initial > mail, there has been some work done before... We need to solve DTLS first. CoAP is pointless without it. -- 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
> > > what are you talking about? https://codereview.qt-project.org/201311 is up for > more than a month already. [Kalinowski Maurice] And it is visible now after Frederik moved it. As I wrote in my initial mail, there has been some work done before... Maurice ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on
On Tue, Sep 05, 2017 at 10:32:43AM +0200, Frederik Gladhorn wrote: > I'm a bit split here, let's try to find some middle ground :) > > I do think that we should always run with accessibility enabled I don't. Optional services should be opt-in, not opt-out. Always. Out of principle. And no, I don't want to have keyboard and mouse events more widely accessible then they necessarily are, completely independent of whether there is theoretically or practical an additional perceived or actual risk, or not. > [...] The next thing is to make sure we don't actually send the > keyboard and mouse events when not needed (pure insanity anyway, we > should have a sound approach...). For the time being sending all of > these events over dbus is the only way to make Orca happy [...] Same for other creatures. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backporting the Keccak change
On Tuesday, 5 September 2017 14:04:14 -03 Oswald Buddenhagen wrote: > On Tue, Sep 05, 2017 at 10:29:44AM -0300, Thiago Macieira wrote: > > On Tuesday, 5 September 2017 05:09:19 -03 Oswald Buddenhagen wrote: > > > # ifndef QT_FIXED_SHA3 > > > > > >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_224 = 7, > > >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_256, > > >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_384, > > >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_512, > > > > > > # else > > > > Almost. There are two things there: > > 1) I'dl ike people to opt into the broken code, so I think the #if should > > be> > > reversed. It will cause a few support tickets and bug reports, but I think > > it's best this way for the long term. At some point, we'd have to do it > > anyway. > > well, i know that you'd like to, but it's still breaking the compat > promise for no _really_ convincing reason. Other than correctness? And that we've done it in 5.9.0 and 5.9.1 anyway? I think people who want a *second* behaviour change should need to opt into it. > while the current implementation is clearly broken, it apparently works > well enough for those who use it, and the others don't use it anyway > (obviously). so the idea is to not fix the problem, but to do an, ehhm, > "specification update". ;) > > there isn't really much added value to making the wrong behavior opt-in, > because the user can then just use the new enum values straight away. Not if they need to keep compatibility with pre-5.9 code. That's the advantage of a #define solution over Peppe's original implementation. They may have one codebase that should keep working with both. Additionally, they can add the #define now and not worry about when they need to rebuild with 5.9 or 5.10. > > 2) you can't use QT_DEPRECATED or Q_DECL_DEPRECATED on enumerations > > unless __cpp_enumerator_attributes >= 201411 > > i sort of expected that. how about a separate macro for enums, to avoid > an ifdef mess? maybe we have it already? I thought we did. I distinctly remember doing this before, but I can't find it. It must have been in a change of mine that never panned out. I'm more afraid of the fall-out of other SD-6 issues, like Clang issuing warnings. So I'll add the deprecated macros for 5.9.3 or 5.10, as we have more time to test it. Let 5.9.2 go without warnings. -- 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
On Fri, Sep 01, 2017 at 12:06:23PM +, Maurice Kalinowski wrote: > a new repository is needed. > what are you talking about? https://codereview.qt-project.org/201311 is up for more than a month already. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backporting the Keccak change
On Tue, Sep 05, 2017 at 10:29:44AM -0300, Thiago Macieira wrote: > On Tuesday, 5 September 2017 05:09:19 -03 Oswald Buddenhagen wrote: > > # ifndef QT_FIXED_SHA3 > >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_224 = 7, > >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_256, > >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_384, > >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_512, > > # else > > Almost. There are two things there: > 1) I'dl ike people to opt into the broken code, so I think the #if should be > reversed. It will cause a few support tickets and bug reports, but I think > it's best this way for the long term. At some point, we'd have to do it > anyway. > well, i know that you'd like to, but it's still breaking the compat promise for no _really_ convincing reason. while the current implementation is clearly broken, it apparently works well enough for those who use it, and the others don't use it anyway (obviously). so the idea is to not fix the problem, but to do an, ehhm, "specification update". ;) there isn't really much added value to making the wrong behavior opt-in, because the user can then just use the new enum values straight away. > 2) you can't use QT_DEPRECATED or Q_DECL_DEPRECATED on enumerations > unless __cpp_enumerator_attributes >= 201411 > i sort of expected that. how about a separate macro for enums, to avoid an ifdef mess? maybe we have it already? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backporting the Keccak change
On Tuesday, 5 September 2017 05:09:19 -03 Oswald Buddenhagen wrote: > # ifndef QT_FIXED_SHA3 >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_224 = 7, >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_256, >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_384, >QT_DEPRECATED_SINCE(5, 10, 0) Sha3_512, > # else Almost. There are two things there: 1) I'dl ike people to opt into the broken code, so I think the #if should be reversed. It will cause a few support tickets and bug reports, but I think it's best this way for the long term. At some point, we'd have to do it anyway. 2) you can't use QT_DEPRECATED or Q_DECL_DEPRECATED on enumerations unless __cpp_enumerator_attributes >= 201411 -- 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] Fwd: Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on
-- Mensaje reenviado -- De: "Samuel Thibault" Fecha: 5 sep. 2017 5:40 a.m. Asunto: Re: [Development] Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on Para: "Frederik Gladhorn" Cc: , "Allan Sandfeld Jensen" , , "Sebastian Humenda" , < 874...@bugs.debian.org>, "Lisandro Damián Nicanor Pérez Meyer" < lisan...@debian.org>, "Alex ARNAUD" Hello, It seems my mails don't reach the development@qt-project.org mailing list. Could somebody who got them forward them to it? Frederik Gladhorn, on mar. 05 sept. 2017 10:32:43 +0200, wrote: > And then Allan is right, by setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON you ask > for it. All the stuff unconditionally. Please don't, why do you need it in the > first place? Because it would just not work at all in non-kde desktops in Debian 9 otherwise (and I didn't notice performance regression). AIUI, qt 5.7 was only looking at the "accessibility enabled" checkbox in kde configuration. > Right now Qt is trying to emulate Gnome's way, except since we don't > listen to the change signal, we never dynamically enable/disable a11y. With Debian testing (qt 5.9), I don't need to set QT_LINUX_ACCESSIBILITY_ALWAYS_ON, and accessibility seems to get enabled dynamically, so it seems something changed between 5.7 and 5.9. Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on
-- Mensaje reenviado -- De: "Samuel Thibault" Fecha: 3 sep. 2017 4:39 p.m. Asunto: Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on Para: "Allan Sandfeld Jensen" , "Lisandro Damián Nicanor Pérez Meyer" , "Sebastian Humenda" , "Lisandro Damián Nicanor Pérez Meyer" , "Alex ARNAUD" , <874...@bugs.debian.org>, < debian-qt-...@lists.debian.org>, Cc: Samuel Thibault, on dim. 03 sept. 2017 21:17:12 +0200, wrote: > I have checked with a vanilla reinstall of Debian 9, using the Mate > desktop, and Qt 5.7.1. > > When QT_LINUX_ACCESSIBILITY_ALWAYS_ON is not set, I don't see Qt > applications in accerciser, only the Mate applications. If I set > QT_LINUX_ACCESSIBILITY_ALWAYS_ON, I do see them. > > On my current desktop, I have Qt 5.9.1, I made quick tests, it seems > it behaves as I expect, so perhaps we can indeed avoid setting > QT_LINUX_ACCESSIBILITY_ALWAYS_ON now. I'll retest with a vanilla > reinstall of debian testing, to be sure. Yes, a vanilla reinstall behaves as expected. So we can drop that variable, good :) Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on
-- Mensaje reenviado -- De: "Samuel Thibault" Fecha: 3 sep. 2017 4:17 p.m. Asunto: Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on Para: "Allan Sandfeld Jensen" , "Lisandro Damián Nicanor Pérez Meyer" , "Sebastian Humenda" , "Lisandro Damián Nicanor Pérez Meyer" , "Alex ARNAUD" , <874...@bugs.debian.org>, < debian-qt-...@lists.debian.org>, Cc: Samuel Thibault, on dim. 03 sept. 2017 20:23:30 +0200, wrote: > Allan Sandfeld Jensen, on dim. 03 sept. 2017 20:19:31 +0200, wrote: > > On Sonntag, 3. September 2017 19:57:55 CEST Samuel Thibault wrote: > > > Allan Sandfeld Jensen, on dim. 03 sept. 2017 19:13:38 +0200, wrote: > > > > > > That's Qt's fault for not taking care of EventListenerRegistered > > > signals to determine whether someone is listening. > > > > So it is Qt's fault that is doing what you have told it to do? You have set > > the environment variable to ignore the absence of listeners. That is what > > QT_LINUX_ACCESSIBILITY_ALWAYS_ON does. > > Ah? That's not what I had gotten in my tests. I'll check again, then. I have checked with a vanilla reinstall of Debian 9, using the Mate desktop, and Qt 5.7.1. When QT_LINUX_ACCESSIBILITY_ALWAYS_ON is not set, I don't see Qt applications in accerciser, only the Mate applications. If I set QT_LINUX_ACCESSIBILITY_ALWAYS_ON, I do see them. On my current desktop, I have Qt 5.9.1, I made quick tests, it seems it behaves as I expect, so perhaps we can indeed avoid setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON now. I'll retest with a vanilla reinstall of debian testing, to be sure. Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on
-- Mensaje reenviado -- De: "Samuel Thibault" Fecha: 3 sep. 2017 3:34 p.m. Asunto: Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on Para: "Allan Sandfeld Jensen" Cc: "Lisandro Damián Nicanor Pérez Meyer" , "Sebastian Humenda" , "Lisandro Damián Nicanor Pérez Meyer" < perezme...@gmail.com>, "Alex ARNAUD" , < 874...@bugs.debian.org>, , < development@qt-project.org> Allan Sandfeld Jensen, on dim. 03 sept. 2017 20:31:58 +0200, wrote: > Note, the case where I saw the largest performance impact was not moving > the cursor, it was self-modifying web-content, it would send every text change > in the active focus. [...] > But it is what Chrome would send on macOS and Windows when a > screen-reader is detected as active. Uh. While it can be necessary to get such information. Getting every text change is the kind of spurious event I'm referring to. It should throttle the sends, to avoid the flurry that the screen reader won't be able to render as speech or braille anyway, and just make sure that the last version is sent. Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Qt CoAP
On Monday, September 4, 2017 11:58:13 AM CEST Thiago Macieira wrote: > > True, but we can re-evaluate if it is not working, modularization is > > harder > > in general as it requires some code changes. Regarding the "two weeks" > > delay, it is mostly a social problem, as we can not agree on how often qt5 > > submodule update should happen, the status quo is kept and it happens > > randomly and on a request. > > It's usually one week for someone to go and start the merge. And then one > more week to get that past the CI. There is a difference between merge and submodule update. If you do not work against different branches, a submodule update is enough and that one may be quite cheap. Again, it is a social issue, technically there is no problem in updating just one module in Qt5. Depending on the module, cost of it is; zero (leaf modules) to full Qt5 buid and test (qtbase), but currently we prefer to update all of them and that triggers full rebuild and test (currently we are reaching the target of 4.5h per qt5 integration, so assuming no failures it is not that bad). In addition you do not need to wait for someone to create a submodule update, it is quite easy operation. Just make a commit with a new sha1. We should do merges and submodule updates automatically, as often as possible (yes, even few times per day). Yes, it will pollute git log with "Update" and "Merge" commits, but I can not force myself to care about it (btw. it may be solvable for qt5 repo, but it would require a shadow copy and a direct push). Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on
I'm a bit split here, let's try to find some middle ground :) I do think that we should always run with accessibility enabled and we don't do that for a reason. One thing to fix for linux accessibility is listening to the change signal on for a11y being enabled or not. If I recall correctly listening to property changes on dbus is not implemented in Qt since it's impossible to know if there are any listeners to these change signals, Thiago knows the details I think. The next thing is to make sure we don't actually send the keyboard and mouse events when not needed (pure insanity anyway, we should have a sound approach...). For the time being sending all of these events over dbus is the only way to make Orca happy and thus the only way to make applications behave somewhat acceptable for blind users. Thinking about the code gives me nightmares though and I'd support anyone looking at it and making sure we don't overdo the sending of events. And then Allan is right, by setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON you ask for it. All the stuff unconditionally. Please don't, why do you need it in the first place? Maybe it's time to sit down and create a somewhat defined way when it should be enabled? Right now Qt is trying to emulate Gnome's way, except since we don't listen to the change signal, we never dynamically enable/disable a11y. The code is there, it's just actually reacting to the notification that's missing. Cheers, Frederik On søndag 3. september 2017 19.13.38 CEST Allan Sandfeld Jensen wrote: > On Sonntag, 3. September 2017 18:15:15 CEST Samuel Thibault wrote: > > On the long run, it really should. Just hiding issues is not the way > > forward :) > > > > Also, note that if the performance is so bad, it means something *needs* > > to be fixed, otherwise blind users will get the bad performance, and > > nobody will be there to fix it, because nobody notices it except blind > > users, who are left with little hope to fix it by themselves. > > It is not a issue or a bug. The performance impact comes from sending > everything the mouse hovers over to the accessibility framework (for > instance to be spoken aloud), when there is not any accessibility tools > running. > > You are deliberately crippling Qt to always send dbus events even when no > one is listening. > > Note the performance impact is the same in all applications regardless of > framework. Running accessibility tools has a substantional performance cost > on mouse movements, but a mouse rendered or text scrolling at 60 fps is > completely pointless to blind people, but rather important to everybody > else. > > 'Allan > ___ > 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] Backporting the Keccak change
On Tue, Sep 05, 2017 at 06:57:38AM +, Lars Knoll wrote: > On 4 Sep 2017, at 14:12, Thiago Macieira wrote: > > 2) enum names > > I'd like to do: > > > >Keccak_224 = 7, > >Keccak_256, > >Keccak_384, > >Keccak_512 > >RealSha3_224 = 11, > >RealSha3_256, > >RealSha3_384, > >RealSha3_512, > > # ifndef QT_SHA3_KECCAK_COMPAT > >Sha3_224 = RealSha3_224, > >Sha3_256 = RealSha3_256, > >Sha3_384 = RealSha3_384, > >Sha3_512 = RealSha3_224, > > # else > >Sha3_224 = Keccak_224, > >Sha3_256 = Keccak_256, > >Sha3_384 = Keccak_384, > >Sha3_512 = Keccak_224, > > # endif > > That was pretty much what I thought of :) > that's one way to do it. is this possible? RealSha3_224 = 11, RealSha3_256, RealSha3_384, RealSha3_512, Keccak_224 = 15, Keccak_256, Keccak_384, Keccak_512 # ifndef QT_FIXED_SHA3 QT_DEPRECATED_SINCE(5, 10, 0) Sha3_224 = 7, QT_DEPRECATED_SINCE(5, 10, 0) Sha3_256, QT_DEPRECATED_SINCE(5, 10, 0) Sha3_384, QT_DEPRECATED_SINCE(5, 10, 0) Sha3_512, # else Sha3_224 = RealSha3_224, Sha3_256 = RealSha3_256, Sha3_384 = RealSha3_384, Sha3_512 = RealSha3_224, # endif ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Qt CoAP
OK, I'll create the repository, we can still merge several projects later as seen fit. Cheers, Frederik On fredag 1. september 2017 14.06.23 CEST Maurice Kalinowski wrote: > Hi everyone, > > Most of you might have noticed the IoT related discussion happening on this > mailing list. If not, check here in the archive: > http://lists.qt-project.org/pipermail/development/2017-August/030723.html > > One of the items mentioned has been CoAP and that it would make a great > addition to Qt. Interestingly, there has been discussions between the Qt > Company and Witekio about exactly this topic. Thanks to the people at > Witekio these resulted in actual code already available to get reviewed. To > avoid any duplicate effort and have everyone participating as early as > possible a new repository is needed. > > Name of the project: Qt CoAP > > Responsible person: > Cedric Amarger > Gerrit user/email: Cedric Amarger > Desired repository name: qtcoap > > For now, I will leave any technical detail to Cedric. > > BR, > Maurice > ___ > 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
