Re: [Interest] QT 5.4 - Windows Phone (WinRT) - Blank Screen

[Oliver Wolff]

Hi Raphael,

that sounds like you are hit by 
https://bugreports.qt-project.org/browse/QTBUG-41768 We hope to fix that 
soonish.


Cheers,
Olli

On 10/10/2014 04:31, Raphael Couto wrote:


I've tested on a Lumia 920.

The filename of dump generated in Documents folder (phone):

meubrt - aa1e427f-8131-4947-b723-af0d5f6f8cda with exception C194 
on 10-09-2014 14.41.dmp


I opened the dump with WinDBG:

ERROR: Exception C194 occurred on unknown thread 

Seaching the net about this exception:

https://answers.madewithmarmalade.com/questions/25370/gametutorial-stage6-stage7-will-not-run-on-windows.html 
(last post - this can be related?)




@swarnamuki 
https://answers.madewithmarmalade.com/users/2245/swarnamuki.html It 
is crashing in Angle when virtual resolution is used. it appears to be 
running out of memory. That is running out of graphics memory, not 
memory controlled by s3e, so to fix this you need to decrease the s3e 
memory or change the capabilities to support a higher memory amount 
(see the docs for this).




Em , Raphael Couto escreveu:


Hi,

I've compiled Qt 5.4 today for winrt:

..\qt5\configure.bat -xplatform winphone-arm-msvc2013 -prefix 
C:\quati\develop\build\qt5.4\winphone_arm -opensource 
-confirm-license -nomake tests -nomake examples


Then, after setup QtCreator, I've tried to compile my project (Qml - 
that works on Android and IOS). But application stops, and a dump 
file is created in Documents folder.


I've made another test:

C:\Quati\develop\build\qt5.4\winphone_arm\bin\qmake.exe 
C:\xxx\\x\x.pro -r -spec winphone-arm-msvc2013 
CONFIG+=declarative_debug  -tp vc CONFIG+=windeployqt


Open VS2013, and try to run the application. Some logs (console.log 
in qml's) appear in Output Window, but the application shows a blank 
screen.



___
Interest mailing list
Interest@qt-project.org  mailto:Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] No network reply received in WinRT after calling QNetworkAccessManager::post

[Oliver Wolff]

Hi,


On 5/12/2015 11:05, Rogerio Nicolau wrote:
 Hi

 I'm using Qt 5.4.1 and have an App which runs fine on all the other
 platforms except on winrt where after a QNetworkAccessManager::post, the
 QNetworkAccessManager::finished signal never gets triggered. The post is
 just an http message and I can see that the server receives and responds
 to the post.
 So the call to post is working fine but no timeout is triggered and the
 finished signal is never emitted so the app just sits and waits for the
 reply.

 The only clue that I can see are some error messages in the debug output
 indicating exceptions being thrown by the windows libraries:

 First-chance exception at 0x7FF9A3578B9C (KernelBase.dll) in
 app.exe: 0x40080202: WinRT transform error (parameters:
 0x800B, 0x80070490, 0x0014,
 0x001CD208EF00)

 If I enable breaking on exceptions I can trace these back to this
 method/line
 QEventDispatcherWinRTPrivate::fetchCoreDispatcher()
 {
 ...
 hr = view2-get_Dispatcher(coreDispatcher);
 ...
 }
 where coreDispatcher is a ComPtr object.

 I get a couple of these exceptions before the call to post and then at
 least one after, so there may be other things that have been affected.

 Any suggestions on what might be wrong?

that sounds like https://bugreports.qt.io/browse/QTBUG-43837. I am still 
trying to work around the issue we are having with threading in this 
case on WinRT. I hope to be able to come up with a fix soon.

BR,
Olli


 Thanks.

 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to run a WinRT app on a Window 8 intel tablet?

[Oliver Wolff]

Hi,

I am afraid that deployment to a device from Creator only works for 
Windows Phone but not for Windows Tablets. For Tablets you have to 
package/deploy everything manually using windeployqt for example. The 
other option (that I would tend to avoid) would be building on your 
tablet (if it has an x86 CPU).
Another option would be to use Visual Studio. There it should be 
possible to select your tablet and deploy the application you created 
(for example by calling qmake -tp vc CONFIG+=windeployqt).
Some more information can be found on 
http://doc.qt.io/qt-5/winrt-support.html#package-content but the content 
here is partially outdated and being updated at the moment. The D3D 
shader service for example is no longer needed.

BR,
Olli

On 6/4/2015 12:57, Nuno Santos wrote:
 Hi,

 I'm doing my first experiments with WinRT.

 I have a Dell Window 8 tablet and i'm trying to run a QtQuick Hello
 World program on it.

 I was able to start the app on the computer but not on the tablet.

 I thought there was a mechanism like iOS and Android, in which I could
 select the device.

 Is there any guide line on how to proceed?

 Regards,

 Nuno
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth LE: HowTo inspect QBluetoothDeviceInfo::serviceUuids

[Oliver Wolff]

On 13/04/2017 19:01, ekke wrote:


from QBluetoothDeviceInfo::serviceUuids I'm getting a list of Service 
UUIDs ( QBluetoothUuid) without connecting to the device and 
inspecting the Services.


there's per ex:

{180d--1000-8000-00805f9b34fb}

and I know this means the device supports


HeartRate

0x180d


How can I inspect the QBluetoothUuid to get 0x180d


I found some Java code like this:


private static int getAssignedNumber(UUID uuid) {
// Keep only the significant bits of the UUID
return (int) ((uuid.getMostSignificantBits() & 
0xL) >> 32);

}


but have no idea HowTo do the same from Qt



Hi ekke,

I am not sure I fully understand the problem. If you want to check the 
availability of a heart rate sensor, you can just compare the Uuids with 
QBluetoothUuid(QBluetoothUuid::HeartRate) can't you?



thx for hints


ekke



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth LE: HowTo inspect QBluetoothDeviceInfo::serviceUuids

[Oliver Wolff]

On 18/04/2017 11:12, ekke wrote:

Am 18.04.17 um 10:26 schrieb Oliver Wolff:

On 13/04/2017 19:01, ekke wrote:


from QBluetoothDeviceInfo::serviceUuids I'm getting a list of 
Service UUIDs ( QBluetoothUuid) without connecting to the device and 
inspecting the Services.


there's per ex:

{180d--1000-8000-00805f9b34fb}

and I know this means the device supports


HeartRate

0x180d


How can I inspect the QBluetoothUuid to get 0x180d


I found some Java code like this:


private static int getAssignedNumber(UUID uuid) {
// Keep only the significant bits of the UUID
return (int) ((uuid.getMostSignificantBits() & 
0xL) >> 32);

}


but have no idea HowTo do the same from Qt



Hi ekke,

I am not sure I fully understand the problem. If you want to check 
the availability of a heart rate sensor, you can just compare the 
Uuids with QBluetoothUuid(QBluetoothUuid::HeartRate) can't you?

Hi Oliver,

as soon as I connect to the device and discovered Services I can 
compare with QBluetoothUuid::HeartRate (0x180d)


if I only discover the Devices without connecting, most devices 
provide ServiceUUIDs

http://doc.qt.io/qt-5/qbluetoothdeviceinfo.html#serviceUuids
but here the UUID isn't 0x180d for HeartRateService, but 
{180d--1000-8000-00805f9b34fb}


so looking at the ServiceUUIDs I don't have to nonnect to the device 
to know that it supports HeartRate :)


now I'm simply comparing found ServiceUUIDs with the full value
{180d--1000-8000-00805f9b34fb}
to detect the Device as a HeartRate Device
You don't need to compare to the full value. Comparing to 
QBluetoothUuid::HeartRate also works (at least it does here). I think if 
that does not work it's a bug or I am still not understanding the 
problem at hand.


googled and found that there's a (Java) way to get the most 
significant Bits from ServiceUUID to compare with

QBluetoothUuid::HeartRate (0x180d)

would make the example app easier to understand

I'm just finishing a new BT LE Example APP - will be published soon

ekke



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.9 and QtAngle library

[Oliver Wolff]

Hi Lars,


On 03/07/2017 10:52, Lars wrote:


Hello,


Downloaded and installed qt-enterprise-windows-x86-5.9.0.


Reading the following web page 
http://doc.qt.io/qt-5/windows-deployment.html 
 I saw this line;


/"If //ANGLE/ 
/(the 
default) is used, you additionally need to include both |QtANGLE.dll| 
from Qt's 'lib' directory as well as the HLSL compiler from DirectX." /

/
thanks for the pointer, I will fix the documentation. QtANGLE.dll is 
split in libEGL.dll and libGLESv2.dll again. We merged these to before 
but realized, that this change is not binary compatible to previous 
versions, so the change was reverted. Just include libEGL.dll and 
libGLESv2.dll (and the compiler) and you should be fine.


Olli
/


We searched c:\Qt\Qt5.9.0 and subdirs without finding QtAngle.dll.

A bit confussed, it appears installer is not including a library that 
documentation says should be included. Please help me understand.


kind regards, Lars


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] windeployqt

[Oliver Wolff]

Hi,


On 14/12/2017 14:54, Nuno Santos wrote:

Robert,

I believe that windeployqt will only search for imports on qml files. You can 
trick it by specifying a path that contains one or several qml files that 
contains all the imports that you need.

Regards,

--
Nuno Santos

No dia 14/12/2017, às 13:36, Robert Bielik  escreveu:


We have a project with several QML directories, can windeployqt be fed several 
--qmldir options ?
yes that's possible. Example from the Qt Creator readme: windeployqt 
-quick -qmldir share\qtcreator\welcomescreen -qmldir 
src\plugins\qmlprofiler bin\qtcreator.exe lib\qtcreator 
lib\qtcreator\plugins


Cheers,
Olli



Regards
/Robert

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth library and old windows versions

[Oliver Wolff]

No the message comes from Qt not Windows (and we call exit(-1)) 
\src\bluetooth\qbluetoothutils_win.cpp. If we would not 
show the message, windows would show a more cryptic error message if I 
remember correctly.



On 23/08/2018 15:34, Maurice Kalinowski wrote:

The message resides from Windows as it is not able to resolve all dependencies 
and hence the application is not launched at all.

Plugins getting loaded is an API call at runtime, which simply returns a 
nullptr and you could add error handling to this. So there is no system dialog 
involved or such.
Hence this is a valid workaround. However, as Olli mentioned, you then need to 
resolve all functions you need.

BR,
Maurice


-Original Message-
From: Interest  On 
Behalf Of maitai
Sent: Thursday, August 23, 2018 3:32 PM
To: interest@qt-project.org
Subject: Re: [Interest] Bluetooth library and old windows versions

Hi Oliver, thanks for your reply

This message is from Qt or from Windows? Because if it is from Qt then maybe it is worth 
adding a "compatibility-check" method and let the developer decide if it is 
fatal or not?
We could mirror the dummy plugin's behavior in this case, but that would 
mean a lot of ifdefery in the windows code. Not sure about the 
compatibility check, because the problem is that loading the dll will 
fail on runtime on an older Windows version (as mentioned above).


Otherwise I will go with yet another build and install option I think.
The plugin method will probably display the message each time the app is 
launched and that is annoying.

Philippe


Le 23-08-2018 15:00, Oliver Wolff a écrit :

Hi,


On 23/08/2018 13:30, maitai wrote:

Hello,

I have a problem with users equipped with an old version of Windows
(8, or 7). The latest version of my app (Qt 5.11.1/MSVC 2017 based)
required QtBluetooth but when users load the app they get a message
saying:

"This Windows version does not support the required Bluetooth API.
Consider updating to a more recent Windows (10.0.10586 or above)"

Then they press OK and the app shuts down.

I understand the message and have no problem removing BT
functionalities for these users with old Windows versions, but my
question is: can I avoid to build several binaries, i.e. is there a
way not to load QtBluetooth if windows version is not recent enough ?
Any other suggestion ?

The message is shown when the dll is loaded, so unfortunately I only
see two other ways of working around the problem.
1) You could try to dlopen the library and lazy load all the
functionality you need. That would mean, that you have to resolve
every function though...
2) You could put your Bluetooth code into a plugin. If that fails to
load, the application will not exit immediately, but only the plugin
loading will fail then.

Thanks
Philippe.



BR,
Olli

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth library and old windows versions

[Oliver Wolff]

On 23/08/2018 16:38, maitai wrote:
Ok, so if I understand well windows will show the cryptic message only 
when trying to actually use the library? Because it seems to me that 
if Qt is able to display a message then the lib loaded successfully 
from Windows point of view, even if unusable, no? Here the BT feature 
is really optional and is eventually activated only after many other 
checks and settings, never during app loading.


No the message is shown in the library's main entry point function. That 
function is run while the dll is being loaded. We just hook in there to 
be able to show a "proper" error message and return instead of getting a 
cryptic error message and a terminating app. So the library is not 
loaded successfully by Windows at that point in time. Any hints about 
how to solve that problem differently are of course welcome :)


Olli



I will disable BT on Windows platforms for the time being.

Philippe.

Le 23-08-2018 15:41, Oliver Wolff a écrit :

No the message comes from Qt not Windows (and we call exit(-1))
\src\bluetooth\qbluetoothutils_win.cpp. If we would
not show the message, windows would show a more cryptic error message
if I remember correctly.


On 23/08/2018 15:34, Maurice Kalinowski wrote:
The message resides from Windows as it is not able to resolve all 
dependencies and hence the application is not launched at all.


Plugins getting loaded is an API call at runtime, which simply 
returns a nullptr and you could add error handling to this. So there 
is no system dialog involved or such.
Hence this is a valid workaround. However, as Olli mentioned, you 
then need to resolve all functions you need.


BR,
Maurice


-Original Message-
From: Interest 
 On Behalf 
Of maitai

Sent: Thursday, August 23, 2018 3:32 PM
To: interest@qt-project.org
Subject: Re: [Interest] Bluetooth library and old windows versions

Hi Oliver, thanks for your reply

This message is from Qt or from Windows? Because if it is from Qt 
then maybe it is worth adding a "compatibility-check" method and let 
the developer decide if it is fatal or not?

We could mirror the dummy plugin's behavior in this case, but that
would mean a lot of ifdefery in the windows code. Not sure about the
compatibility check, because the problem is that loading the dll will
fail on runtime on an older Windows version (as mentioned above).


Otherwise I will go with yet another build and install option I think.
The plugin method will probably display the message each time the 
app is launched and that is annoying.


Philippe


Le 23-08-2018 15:00, Oliver Wolff a écrit :

Hi,


On 23/08/2018 13:30, maitai wrote:

Hello,

I have a problem with users equipped with an old version of Windows
(8, or 7). The latest version of my app (Qt 5.11.1/MSVC 2017 based)
required QtBluetooth but when users load the app they get a message
saying:

"This Windows version does not support the required Bluetooth API.
Consider updating to a more recent Windows (10.0.10586 or above)"

Then they press OK and the app shuts down.

I understand the message and have no problem removing BT
functionalities for these users with old Windows versions, but my
question is: can I avoid to build several binaries, i.e. is there a
way not to load QtBluetooth if windows version is not recent enough ?
Any other suggestion ?

The message is shown when the dll is loaded, so unfortunately I only
see two other ways of working around the problem.
1) You could try to dlopen the library and lazy load all the
functionality you need. That would mean, that you have to resolve
every function though...
2) You could put your Bluetooth code into a plugin. If that fails to
load, the application will not exit immediately, but only the plugin
loading will fail then.

Thanks
Philippe.



BR,
Olli

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth library and old windows versions

[Oliver Wolff]

Hi,


On 23/08/2018 13:30, maitai wrote:

Hello,

I have a problem with users equipped with an old version of Windows 
(8, or 7). The latest version of my app (Qt 5.11.1/MSVC 2017 based) 
required QtBluetooth but when users load the app they get a message 
saying:


"This Windows version does not support the required Bluetooth API. 
Consider updating to a more recent Windows (10.0.10586 or above)"


Then they press OK and the app shuts down.

I understand the message and have no problem removing BT 
functionalities for these users with old Windows versions, but my 
question is: can I avoid to build several binaries, i.e. is there a 
way not to load QtBluetooth if windows version is not recent enough ? 
Any other suggestion ?
The message is shown when the dll is loaded, so unfortunately I only see 
two other ways of working around the problem.
1) You could try to dlopen the library and lazy load all the 
functionality you need. That would mean, that you have to resolve every 
function though...
2) You could put your Bluetooth code into a plugin. If that fails to 
load, the application will not exit immediately, but only the plugin 
loading will fail then.


Thanks
Philippe.



BR,
Olli

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth on Windows 10

[Oliver Wolff]

Hi Philippe,

The current implementation requires the devices to be paired in order to 
use Bluetooth on Windows. There is a bug report about getting rid of 
that requirement (https://bugreports.qt.io/browse/QTBUG-58660) but 
that's the status quo atm.


Olli


On 24/07/2018 16:59, maitai wrote:

Hi Oliver,

No the 2 machines are not paired with anything. I've tried pairing the 
Android Phone with the Windows machine just to check that the BT 
device is OK, that worked, but I have removed all connections after that.


Philippe.

Le 24-07-2018 14:00, Oliver Wolff a écrit :

Hi Philippe,

are the two machines paired? Windows API does not allow pairing them,
so the initial pairing has to be using the system UI.

Olli


On 24/07/2018 10:32, maitai wrote:

Thanks Alex,

I have done that, but although it seems to do things, I cannot make 
it work on Windows (server or client). It works finally between a 
Mac and an Android device.


For instance if I run the BT discovery example I get:

qt.bluetooth.winrt: Worker started
qt.bluetooth.winrt: BT  scan completed
qt.bluetooth.winrt: BTLE  scan completed
qt.bluetooth.winrt: onBluetoothLEDeviceFound: No device given

And nothing is found (it actually finishes the scan almost 
immediately, which I believe is not a good sign).


For the pingpong example as a server it gives:

qt.bluetooth.winrt: Port 1 registered
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid 
attribute with length 16

qt.bluetooth.winrt: Registering sequence attribute
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid 
attribute with length 2 "{1002--1000-8000-00805f9b34fb}"
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registered sequence 
attribute with length 3

qt.bluetooth.winrt: Registering sequence attribute
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid 
attribute with length 2 "{1101--1000-8000-00805f9b34fb}"
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registered sequence 
attribute with length 3
qt.bluetooth.winrt: bool __cdecl 
repairProfileDescriptorListIfNeeded(class 
Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> &) Repairing profile 
descriptor list
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering attribute of 
type QMetaType::QString


I tried with 2 windows machines, making sure they are discoverable, 
etc. The mac machine detects the Windows machine, but not the opposite.


Probably I am doing something wrong, still investigating.
Philippe

Le 24-07-2018 10:13, Alex Blasche a écrit :

Adding

QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = 
true"));


to your main() might help.

-- Alex


From: Interest
 on behalf of
maitai 
Sent: Monday, 23 July 2018 6:34:15 PM
To: Interest@qt-project.org
Subject: Re: [Interest] Bluetooth on Windows 10

Ok, thanks Alex for the clear answer, that is a great news.

I have tried the pingpong-bluetooth example and couldn't make it 
work. I
tried various machines (2 Windows 10/1803, 1 Windows/1 Android, 1 
Mac/1
Android, etc), I do not see any debug or strange messages but the 
client

never finds the server (Qt 5.11.1).

Now that I know that it should work I will dig deeper

Thanks again
Philippe.

Le 23-07-2018 17:17, Alex Blasche a écrit :

-Original Message-
From: Interest
 On
Behalf Of maitai


I have already read many posts on this topic, but I cannot 
understand

the
following statement in the documentation:

"Despite there not being a Win32 port yet, the WinRT backend is
automatically
used if the win32 target platform supports the required WinRT APIs.
Minimal
requirement is Windows 10 version 1507 with slightly improved 
service

discovery
since Windows 10 version 1607. Therefore Windows 7 and 8.x 
targets are

excluded."


The Win32 build will silently use WinRT-only API to enable this
feature. This works because we can assume that the relevant windows
builds have the required API. There is a runtime check that guards 
the

implementation.

Does it mean QBluetooth (regular) will work on Windows 10 version 
1803

out of
the box?


Yes, it should.

-- Alex

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth low energy on Windows 10

[Oliver Wolff]

Hi Glenn,

I am not sure I understand your situation. The Windows BT implementation 
needs a paired device in order to work. You said, that you paired the 
device in the beginning. Have you paired the device and it does not work 
for you? If this is the case please create a bug report which also 
states your Windows version and the device you are trying to connect to. 
You can assign the bug report to me.


Olli


On 25/07/2018 05:37, Glenn Ramsey wrote:

Hi,

I'm trying to get Qt(5.11.1) communicating with a BLE device on Windows 10 using
the win32/WinRT backend.

Using the lowenergyscanner example it can 'see' the device, only after it has
been manually paired,  but hangs when querying the services. The Microsoft BLE
Explorer app from the Microsoft Store is able to 'see' all of the services and
characteristics of the device and the UWP version of lowenergyscanner also seems
to work correctly. Also the same version (in 5.11.1) works correctly on OSX.

In the debugger I can see that the hang occurs somewhere in
QLowEnergyControllerPrivateWinRT::connectToDevice().

This bug [1] suggests this might be because windows needs to pair with the
device, although I'm not seeing any indication of this in the UI when I run
lowenergyscanner but I don't see the the device listed until I manually pair it.

Is there some step that I have missed, or should I file a bug report about this?

Glenn

[1] https://bugreports.qt.io/browse/QTBUG-58660
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bluetooth on Windows 10

[Oliver Wolff]

Hi Philippe.

I can reproduce the problem and it looks like the server functionality 
broke. Can you create a bug report and assign it to me? I will have a 
look as soon as possible.


Olli


On 25/07/2018 09:07, maitai wrote:

Hi Olli

Yes it is better but still not perfect:

When I try the pingpong sample, it now works if I set Android as the 
server, and Windows as the client. But the opposite does not work, the 
paired Android device cannot find the server (no special message in 
the server console). Problem is that in my real case Windows will need 
to be the server of possibly several Android Wear devices. Good point 
though it is not a problem for me if the devices need to be paired 
before running the app.


Philippe

Le 25-07-2018 07:46, Oliver Wolff a écrit :

Hi Philippe,

The current implementation requires the devices to be paired in order
to use Bluetooth on Windows. There is a bug report about getting rid
of that requirement (https://bugreports.qt.io/browse/QTBUG-58660) but
that's the status quo atm.

Olli


On 24/07/2018 16:59, maitai wrote:

Hi Oliver,

No the 2 machines are not paired with anything. I've tried pairing 
the Android Phone with the Windows machine just to check that the BT 
device is OK, that worked, but I have removed all connections after 
that.


Philippe.

Le 24-07-2018 14:00, Oliver Wolff a écrit :

Hi Philippe,

are the two machines paired? Windows API does not allow pairing them,
so the initial pairing has to be using the system UI.

Olli


On 24/07/2018 10:32, maitai wrote:

Thanks Alex,

I have done that, but although it seems to do things, I cannot 
make it work on Windows (server or client). It works finally 
between a Mac and an Android device.


For instance if I run the BT discovery example I get:

qt.bluetooth.winrt: Worker started
qt.bluetooth.winrt: BT  scan completed
qt.bluetooth.winrt: BTLE  scan completed
qt.bluetooth.winrt: onBluetoothLEDeviceFound: No device given

And nothing is found (it actually finishes the scan almost 
immediately, which I believe is not a good sign).


For the pingpong example as a server it gives:

qt.bluetooth.winrt: Port 1 registered
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid 
attribute with length 16

qt.bluetooth.winrt: Registering sequence attribute
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid 
attribute with length 2 "{1002--1000-8000-00805f9b34fb}"
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registered sequence 
attribute with length 3

qt.bluetooth.winrt: Registering sequence attribute
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid 
attribute with length 2 "{1101--1000-8000-00805f9b34fb}"
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registered sequence 
attribute with length 3
qt.bluetooth.winrt: bool __cdecl 
repairProfileDescriptorListIfNeeded(class 
Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> &) Repairing profile 
descriptor list
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering attribute 
of type QMetaType::QString


I tried with 2 windows machines, making sure they are 
discoverable, etc. The mac machine detects the Windows machine, 
but not the opposite.


Probably I am doing something wrong, still investigating.
Philippe

Le 24-07-2018 10:13, Alex Blasche a écrit :

Adding

QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = 
true"));


to your main() might help.

-- Alex


From: Interest
 on 
behalf of

maitai 
Sent: Monday, 23 July 2018 6:34:15 PM
To: Interest@qt-project.org
Subject: Re: [Interest] Bluetooth on Windows 10

Ok, thanks Alex for the clear answer, that is a great news.

I have tried the pingpong-bluetooth example and couldn't make it 
work. I
tried various machines (2 Windows 10/1803, 1 Windows/1 Android, 1 
Mac/1
Android, etc), I do not see any debug or strange messages but the 
client

never finds the server (Qt 5.11.1).

Now that I know that it should work I will dig deeper

Thanks again
Philippe.

Le 23-07-2018 17:17, Alex Blasche a écrit :

-Original Message-
From: Interest
 On
Behalf Of maitai


I have already read many posts on this topic, but I cannot 
understand

the
following statement in the documentation:

"Despite there not being a Win32 port yet, the WinRT backend is
automat

Re: [Interest] Bluetooth on Windows 10

[Oliver Wolff]

Hi Philippe,

are the two machines paired? Windows API does not allow pairing them, so 
the initial pairing has to be using the system UI.


Olli


On 24/07/2018 10:32, maitai wrote:

Thanks Alex,

I have done that, but although it seems to do things, I cannot make it 
work on Windows (server or client). It works finally between a Mac and 
an Android device.


For instance if I run the BT discovery example I get:

qt.bluetooth.winrt: Worker started
qt.bluetooth.winrt: BT  scan completed
qt.bluetooth.winrt: BTLE  scan completed
qt.bluetooth.winrt: onBluetoothLEDeviceFound: No device given

And nothing is found (it actually finishes the scan almost 
immediately, which I believe is not a good sign).


For the pingpong example as a server it gives:

qt.bluetooth.winrt: Port 1 registered
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid attribute 
with length 16

qt.bluetooth.winrt: Registering sequence attribute
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid attribute 
with length 2 "{1002--1000-8000-00805f9b34fb}"
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registered sequence 
attribute with length 3

qt.bluetooth.winrt: Registering sequence attribute
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering Uuid attribute 
with length 2 "{1101--1000-8000-00805f9b34fb}"
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registered sequence 
attribute with length 3
qt.bluetooth.winrt: bool __cdecl 
repairProfileDescriptorListIfNeeded(class 
Microsoft::WRL::ComPtr 
&) Repairing profile descriptor list
qt.bluetooth.winrt: class Microsoft::WRL::ComPtrABI::Windows::Storage::Streams::IBuffer> __cdecl 
bufferFromAttribute(const class QVariant &) Registering attribute of 
type QMetaType::QString


I tried with 2 windows machines, making sure they are discoverable, 
etc. The mac machine detects the Windows machine, but not the opposite.


Probably I am doing something wrong, still investigating.
Philippe

Le 24-07-2018 10:13, Alex Blasche a écrit :

Adding

QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = 
true"));


to your main() might help.

--
Alex


From: Interest
 on behalf of
maitai 
Sent: Monday, 23 July 2018 6:34:15 PM
To: Interest@qt-project.org
Subject: Re: [Interest] Bluetooth on Windows 10

Ok, thanks Alex for the clear answer, that is a great news.

I have tried the pingpong-bluetooth example and couldn't make it work. I
tried various machines (2 Windows 10/1803, 1 Windows/1 Android, 1 Mac/1
Android, etc), I do not see any debug or strange messages but the client
never finds the server (Qt 5.11.1).

Now that I know that it should work I will dig deeper

Thanks again
Philippe.

Le 23-07-2018 17:17, Alex Blasche a écrit :

-Original Message-
From: Interest
 On
Behalf Of maitai



I have already read many posts on this topic, but I cannot understand
the
following statement in the documentation:

"Despite there not being a Win32 port yet, the WinRT backend is
automatically
used if the win32 target platform supports the required WinRT APIs.
Minimal
requirement is Windows 10 version 1507 with slightly improved service
discovery
since Windows 10 version 1607. Therefore Windows 7 and 8.x targets are
excluded."


The Win32 build will silently use WinRT-only API to enable this
feature. This works because we can assume that the relevant windows
builds have the required API. There is a runtime check that guards the
implementation.


Does it mean QBluetooth (regular) will work on Windows 10 version 1803
out of
the box?


Yes, it should.

--
Alex

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt for WinRT and openssl

[Oliver Wolff]

Hi,


On 16/03/2018 07:06, Maurice Kalinowski wrote:


Hi,

I’ll let Oliver provide the detailed answer, but the history as such is:

  * WinRT uses a new networking API. When released Winsock was not
only deprecated but disallowed to be used
  * We implemented network features using that new API.
  * In the meantime there were sufficient complaints/feature requests,
that Microsoft created a new OpenSSL fork
(https://bugreports.qt.io/browse/QTBUG-51871 )
  * A bit later, Winsock2 has been allowed to be used in WinRT (which
is called UWP now) again.
  * The aim is to rather use this in Qt as well, as it shares then the
desktop/classic implementation, which gives bigger coverage.

In the meantime we are using the new, but not widely adopted API. SSL 
is handled via the platform capabilities similar to what we do on mac. 
If you encounter a specific issue, please create a bugreport and we 
will follow up there.


BR,

Maurice



yes Maurice is right. At the moment it is not possible to use openssl on 
winrt, as we are not using the winsock2 API it uses as its foundation. I 
would like to port over the network implementation over to winsock2 
"now" that it is available, but haven't found the time for doing that 
yet. Besides the bug report Maurice mentioned, there is also 
https://bugreports.qt.io/browse/QTBUG-63907 to track that issue.


BR,
Olli


*From:*Interest 
[mailto:interest-bounces+maurice.kalinowski=qt...@qt-project.org] *On 
Behalf Of *Rogerio Nicolau

*Sent:* Thursday, March 15, 2018 4:21 PM
*To:* interest@qt-project.org
*Subject:* [Interest] Qt for WinRT and openssl

Hi

The WinRT platform version of ssl seems to be very limited and doesn't 
work when accessing web services with certain ssl certificates.


On Android I am using the openssl library successfully so I wanted to 
use this on WinRT as well. I have built the openssl libraries and 
included them in the build but it still seems to use the platform ssl 
version. (I have tried on Qt 5.9 and 5.10)
I used the Microsoft openssl (https://github.com/Microsoft/openssl) 
version 1.0.2.


Is using openssl supported in Qt for WinRT and if so do I need to do 
anything else to get it to use those libs?


Thanks
Rogério



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Missing header file d3d11_3.h

[Oliver Wolff]

Hi,

On 08/01/2019 10:42, Nuno Santos wrote:
> Hi,
>   
> I’m trying to compile Qt 5.12 from source on Windows.
>   
> It is complaining about a missing header file, d3d11_3.h.
>   
> After some googling I realized that this header is part of direct x and I’m 
> trying to understand how to get it, oficially.

yes the ANGLE update increased the minimal Direct X SDK we need in order 
to be able to build ANGLE. The old Direct X SDK is no longer enough to 
build Qt on Windows. For MinGW we use the Direct X headers shipped with 
MinGW, for MSVC builds, they can be found inside the Windows Kit. To be 
able to compile 5.12 with MSVC you will need any Windows 10 Kit.

>   
> I have already installed the latest DirectX installer and it is not there.
>   
> Now i’m trying to install the latest Windows SDK kit (10.0.X) but installing 
> hangs…
>   
> Does anyone knows what-s the most straight forward way of getting it?

I think you are on the straight forward way of getting it. Installing a 
Windows 10 Kit/SDK is the way to go here.

BR,
Olli

>   
> Thanks!
> 
> --
> Nuno Santos
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Missing header file d3d11_3.h

[Oliver Wolff]

Hi Nuno,

On 08/01/2019 19:16, Nuno Santos wrote:
> Nikos,
> 
> Thanks for your reply. I’m battling against windows.
> 
> The machine I’m trying to do this is my 4 year old windows dev machine. 4 
> years isn’t much unless it’s a windows machine with the registry full of shit.
> 
> I’m not able to install the latest Windows 10 SDK. Installing hangs at 50%.
> 
> I have realized that on a newer machine in which I have installed Microsoft 
> Visual Studio Community recently, that header is present.

I don't know whether that's also the case with 2015, but Visual Studio 
2017's installers gives you the option to install Windows Kits as part 
of its installation.

> 
> I will battle a bit more with it.
> 
> Thanks,
> 
> Best regards,
> 
> --
> Nuno Santos
> 
> No dia 08/01/2019, às 11:14, Nikos Chantziaras  escreveu:
> 
>>> On 08/01/2019 11:42, Nuno Santos wrote:
>>> I’m trying to compile Qt 5.12 from source on Windows.
>>>   It is complaining about a missing header file, d3d11_3.h.
>>> [...]
>>>   Does anyone knows what-s the most straight forward way of getting it?
>>
>> The easiest way is to use the mingw version of Qt instead. It ships its own 
>> version of that header file. That might not be a good option for you though 
>> if you use Visual Studio instead of Qt Creator for development.
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt 6 Planning: Consideration of dropping support for Windows 7

[Oliver Wolff]

Hi,

as you might have heard, we are currently in Qt 6's planning phase and 
thus check things, that have to be done to make Qt even better.
Of course we also want to use this opportuniy to drop support for 
platforms, that are no longer relevant in Qt's new environment.

One of these platforms is Windows 7, which will reach its end of life in 
the beginning of 2020. Please keep in mind, that we are talking about 
dropping support with Qt 6, so the last version, that will support 
Windows 7 will be Qt 5's last LTS release, which will be 5.15 (will be 
relased mid 2020). So having the LTS status, Windows 7 will be - without 
extended support - supported until 2023 - which will be roughly 3 years 
after its end of life. So even if we drop Windows 7 for Qt 6, it will 
not be the immediate end of Windows 7 support in Qt.

To be able to make the right decision, we now want your input as well. 
If you can give some input on why support should be kept or have 
additional reasons for dropping support, please reply to this mail or 
add your input to https://bugreports.qt.io/browse/QTBUG-74687 where we 
want to gather all the needed information before making a decision.

As said before, nothing is set in stone. At the moment we are gathering 
information, so that we can make a well informed decision.
Olli
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.13 Bluetooth Windows

[Oliver Wolff]

Hi Ekke,

On 11/03/2019 14:54, ekke wrote:
> from https://wiki.qt.io/New_Features_in_Qt_5.13 I noticed this:
> 
> Qt Bluetooth
> 
>   * Removed need for pairing on Windows to discover and connect
> 
> 
> Does this mean it is possible to connect with Bluetooth LE Devices where 
> no pairing is needed from default binaries ? (Windows 10, MSVC2017)

yes if you are using desktop Windows, that should work out of the box.

The situation is different for UWP applications as we use the minimal 
supported version of the Windows Kit (10.0.14393.0) for building the 
installer packages and the new functionality is not available there. In 
order to use the new functionality in UWP apps, users have to build Qt 
themselves for the time being.

Cheers,
Olli

> 
> thx
> ekke
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt 6 Planning: Consideration of dropping support for UWP applications

[Oliver Wolff]

Hi,

as you might have heard, we are currently in Qt 6's planning phase and 
thus checking things that have to be done to make Qt even better.
Of course we also want to use this opportuniy to drop support for 
platforms that are no longer relevant in Qt's new environment.

One of these platforms is Microsoft's Universal Windows Platform which 
is used on desktop PCs (for "Tiled" UWP applications, no classic desktop 
applications), Windows Phone, Xbox one, Microsoft Hololens, and 
Microsoft IoT devices. With Windows Phone no longer being relevant and 
Microsoft's IoT strategy being unclear we now consider dropping support 
for these platforms. Additional benefits and reasons can be found in 
https://bugreports.qt.io/browse/QTBUG-74755

To be able to make the right decision, we now want your input as well. 
If you can give some input on why support should be kept or have 
additional reasons for dropping support, please reply to this mail or 
add your input to https://bugreports.qt.io/browse/QTBUG-74755 where we 
want to gather all the needed information before making a decision.

As said before, nothing is set in stone. At the moment we are gathering 
information so that we can make a well informed decision.
Olli
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Linking issues with Angle and Qt 5.12.x

[Oliver Wolff]

Hi Frederico,

I am not aware of an issue with ANGLE when using MinGW. Can you create a 
bug report on http://bugreports.qt.io/ ,attach a minimal example, and 
assign it to me so that it does not get lost?

Olli

On 25/05/2019 17:47, Federico Buti wrote:
> Hi all.
> 
> We are facing a quite strange behaviour with qnanopainter 
> .
> Building/running the library and the examples works smoothly on Qt 5.9.8 
> and no issue is found. I guess everything was fixed there, see for 
> instance here 
> .
> 
> Building the code on 5.12.x results in a similar linker issue as 
> depicted in the last link. In particular we have a series of undefined 
> references as shown below:
> 
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x12b):
>  
> undefined reference to `_imp__glDeleteTextures@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1b4):
>  
> undefined reference to `glDeleteShader@4'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1d5):
>  
> undefined reference to `glDeleteBuffers@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1e5):
>  
> undefined reference to `glDeleteShader@4'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1f5):
>  
> undefined reference to `glDeleteProgram@4'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x988):
>  
> undefined reference to `_imp__glBindTexture@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x9a0):
>  
> undefined reference to `_imp__glPixelStorei@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x9fc):
>  
> undefined reference to `_imp__glTexSubImage2D@36'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0xa43):
>  
> undefined reference to `_imp__glBindTexture@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1361):
>  
> undefined reference to `_imp__glDeleteTextures@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1388):
>  
> undefined reference to `_imp__glGetError@0'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1407):
>  
> undefined reference to `_imp__glGenTextures@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x143a):
>  
> undefined reference to `_imp__glBindTexture@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1442):
>  
> undefined reference to `_imp__glPixelStorei@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x14ae):
>  
> undefined reference to `_imp__glTexImage2D@36'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x14d7):
>  
> undefined reference to `_imp__glTexParameteri@12'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1638):
>  
> undefined reference to `_imp__glBindTexture@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x16b9):
>  
> undefined reference to `glGenerateMipmap@4'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x16fa):
>  
> undefined reference to `_imp__glTexImage2D@36'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x171a):
>  
> undefined reference to `_imp__glTexParameteri@12'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x17e0):
>  
> undefined reference to `glUniform4fv@12'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1828):
>  
> undefined reference to `_imp__glBindTexture@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x185f):
>  
> undefined reference to `_imp__glBindTexture@8'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x18bb):
>  
> undefined reference to `glGetProgramInfoLog@16'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x192e):
>  
> undefined reference to `glGetShaderInfoLog@16'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x19c9):
>  
> undefined reference to `glCreateProgram@0'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x19d7):
>  
> undefined reference to `glCreateShader@4'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x19e8):
>  
> undefined reference to `glCreateShader@4'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1a19):
>  
> undefined reference to `glShaderSource@16'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1a44):
>  
> undefined reference to `glShaderSource@16'
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1a4f):
>  
> undefined reference to `glCompileShader@4'
> 

Re: [Interest] Linking issues with Angle and Qt 5.12.x

[Oliver Wolff]

Hi Frederico,

This indeed looks like a problem. I will create a patch for Qt tomorrow. 
(new functions that were introduced by the ANGLE update have to be added 
to the def file from 5.9).

Thanks for pointing that out and for the time spent on investigating the 
problem.

Olli

On 28/05/2019 15:24, Federico Buti wrote:
> Hi all.
> 
> Maybe I'm wrong - that's not exactly my cup of tea here - but I've 
> noticed something that feels off to me.
> The def file 
> <https://code.qt.io/cgit/qt/qtbase.git/tree/src/3rdparty/angle/src/libGLESv2/libGLESv2_mingw32.def?h=5.9.8>
>  
> included in Qt 5.9.x for the exported functions seems to correctly match 
> the undefined references that I reported in the original email. Things 
> like "glBindTexture@8" or  "glDeleteTextures@8" are indeed there and 
> there is no undefined reference. Instead, the corresponding file 
> <https://code.qt.io/cgit/qt/qtbase.git/tree/src/3rdparty/angle/src/libGLESv2/libGLESv2d_mingw32.def?h=5.12.3>
>  
> in Qt 5.12.x seems to export different names and it matches exactly the 
> non ming32 
> <https://code.qt.io/cgit/qt/qtbase.git/tree/src/3rdparty/angle/src/libGLESv2/libGLESv2d.def?h=5.12.3>
>  one.
> 
> Is that correct?
> 
> Thanks,
> F.
> 
> 
> On Mon, 27 May 2019 at 17:12, Federico Buti  <mailto:fed.b...@gmail.com>> wrote:
> 
> An update.
> 
> We used chroot from Archlinux and repos which provides a patched
> ANGLE, as seen here
> 
> <https://github.com/edubart/archlibs/blob/master/mingw-w64/mingw-w64-angleproject/angleproject-fix-mingw-compatibility.patch#L51>,
>  and
> it worked like a charm. We were able to compile qnanopainter and
> deploy it via qtwindeploy to a Windows host. Not sure if this rings
> some bells but just thought it was worth mentioning.
> 
> Regards,
> F.
> 
> 
> On Mon, 27 May 2019 at 14:08, Federico Buti  <mailto:fed.b...@gmail.com>> wrote:
> 
> Hi Vadim,
> 
> Thanks for the reply.
> No, quite sure we are not mixing packages in MXE. Compilation is
> forced for 32 bit target only. On native Windows we are using
> plain Qt 5.12.x from qt.io <http://qt.io> so there everything
> should be correctly aligned too.
> F.
> 
> 
> On Mon, 27 May 2019 at 13:11, Vadim Peretokin
> mailto:vpereto...@gmail.com>> wrote:
> 
> Are you mixing 64bit and 32bit libraries by accident during
> linking? I had similar messages in that scenario.
> 
> On Mon, May 27, 2019 at 12:57 PM Oliver Wolff
> mailto:oliver.wo...@qt.io>> wrote:
> 
> Hi Frederico,
> 
> I am not aware of an issue with ANGLE when using MinGW.
> Can you create a
> bug report on http://bugreports.qt.io/ ,attach a minimal
> example, and
> assign it to me so that it does not get lost?
> 
> Olli
> 
> On 25/05/2019 17:47, Federico Buti wrote:
>  > Hi all.
>  >
>  > We are facing a quite strange behaviour with
> qnanopainter
>  > <https://github.com/QUItCoding/qnanopainter>.
>  > Building/running the library and the examples works
> smoothly on Qt 5.9.8
>  > and no issue is found. I guess everything was fixed
> there, see for
>  > instance here
>  >
> 
> <https://github.com/QUItCoding/qnanopainter/issues/16#issue-235192684>.
>  >
>  > Building the code on 5.12.x results in a similar
> linker issue as
>  > depicted in the last link. In particular we have a
> series of undefined
>  > references as shown below:
>  >
>  >
> 
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x12b):
> 
>  > undefined reference to `_imp__glDeleteTextures@8'
>  >
> 
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1b4):
> 
>  > undefined reference to `glDeleteShader@4'
>  >
> 
> libqnanopainter.a(qnanobackendgles2.cpp.o):qnanobackendgles2.cpp:(.text+0x1d5):
> 
>  > undefined reference to `glDeleteBuffers@8'
>  &

Re: [Interest] [Development] Qt 6 Planning: Consideration of dropping support for UWP applications

[Oliver Wolff]

On 21/04/2019 10:43, Allan Sandfeld Jensen wrote:
> On Donnerstag, 18. April 2019 14:46:59 CEST Oliver Wolff wrote:
>> Hi,
>>
>> as you might have heard, we are currently in Qt 6's planning phase and
>> thus checking things that have to be done to make Qt even better.
>> Of course we also want to use this opportuniy to drop support for
>> platforms that are no longer relevant in Qt's new environment.
>>
>> One of these platforms is Microsoft's Universal Windows Platform which
>> is used on desktop PCs (for "Tiled" UWP applications, no classic desktop
>> applications), Windows Phone, Xbox one, Microsoft Hololens, and
>> Microsoft IoT devices. With Windows Phone no longer being relevant and
>> Microsoft's IoT strategy being unclear we now consider dropping support
>> for these platforms. Additional benefits and reasons can be found in
>> https://bugreports.qt.io/browse/QTBUG-74755
>>
>> To be able to make the right decision, we now want your input as well.
>> If you can give some input on why support should be kept or have
>> additional reasons for dropping support, please reply to this mail or
>> add your input to https://bugreports.qt.io/browse/QTBUG-74755 where we
>> want to gather all the needed information before making a decision.
>>
>> As said before, nothing is set in stone. At the moment we are gathering
>> information so that we can make a well informed decision.
> 
> How does UWP support relate to using UWP APIs?
> 
> It seems a lot of new Windows API is UWP specific. For instance for HDR
> support I need to read the luminance level for SDR content in HDR mode, and I
> could only find UWP API for that.

UWP APIs are available for "classic" Windows applications as long as the 
applications run on Windows >= 10. So they can be used in Qt's desktop 
port (they might need a compile and run time check though)

This of course also means, that backends that are available on desktop 
Qt (like Sensors, Bluetooth, and Location for example) will keep working 
on Windows desktop (>= 10). These backends would not be part of UWP's 
deprecation and would be kept alive and supported.

Olli

> 
> 'Allan
> 
> 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dark mode for other platforms

[Oliver Wolff]

On 16/10/2019 14:14, Allan Sandfeld Jensen wrote:
> On Wednesday, 16 October 2019 13:59:54 CEST Nikos Chantziaras wrote:
>> On 15/10/2019 13:46, Allan Sandfeld Jensen wrote:
>>> On Tuesday, 15 October 2019 11:58:42 CEST Vadim Peretokin wrote:
 Hello!

 I've noticed that Qt on macOS now automatically uses dark mode, and it
 looks amazing
 . My
 question is: how can I enable this for Windows and Linux as well?
>>>
>>> Linux and Window have had such modes forever.
>>
>> Well, I wouldn't say "forever" in the case of Windows. It only got a
>> dark mode theme exactly 1 year ago (October 2018.) Which is one month
>> *after* macOS 10.14 was released (September 2018.)
> 
> Windows have had color schemes since at least Window95. It recently added a
> single button to switch the default white color scheme to a dark one, instead
> of selecting a dark on from a list of schemes, but the ability to change them
> has existed for 25 years if not more.

Please note that triggering "dark mode" is not the same as changing the 
color scheme in Windows 10. The dark mode switch did not replace color 
scheme support and behaves differently.

Olli

> 
> 'Allan
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dictation to Qt-Software on Windows-10 Is Broken

[Oliver Wolff]

Hi Robert,

On 12.05.2020 13:14, coroberti . wrote:

Hi,
If somebody in charge could consider increasing priority of the below
major Accessibility issue, it would be really appreciated.

You cannot dictate to Qt text controls on Windows 10, 8 and 7.

https://bugreports.qt.io/browse/QTBUG-83671

There is no workaround within Qt platform.

Thanks in advance!


Sorry for the late reply. Andre had a look at the issue yesterday and 
commented on the bug report. He is currently busy with something else 
but promised to get back to the topic afterwards.


Kind regards,
Olli



Kind regards,
Robert

On Tue, Apr 21, 2020 at 9:54 AM coroberti .  wrote:

You cannot dictate to Qt-software on Windows-10:
https://bugreports.qt.io/browse/QTBUG-83671

Actually, it was always a broken area at least since 2015:

https://bugreports.qt.io/browse/QTBUG-45980

If people on the list have a chance to vote, please vote.

Thanks,

Kind regards,
Robert

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt’s UWP backend will be dropped in Qt 6

[Oliver Wolff]

Hi,

with Qt 6 approaching it is time to have a look at our set of supported 
platforms.


One candidate for removal of support was our port for Microsoft's 
Universal Windows Platform (UWP). Some considerations about dropping 
this support have been communicated on Qt's development mailing list in 
April last year [1] and there were some discussions about this topic on 
the corresponding bug report [2]


During this year's Microsoft Build conference Microsoft announced the 
unification of Win32 and UWP for their IoT offering. In general, it 
looks like Microsoft is stepping away from their strict stance about the 
usage of UWP technology and the Windows Store. Getting a classic Windows 
application into the Windows Store is much easier nowadays and will be 
even simpler in the future. Microsoft's new direction in their IoT 
offering will bring more "classic Windows development" into the IoT 
world and there will be no need for a dedicated UWP port.


With this official Microsoft standing in mind our current plan is to 
drop our dedicated UWP platform backend for Qt 6. According to these 
plans the last Qt version that will support "native Qt UWP application" 
will be Qt 5.15.


There are two main reasons for this decision:
- The number of bug reports for the port as well as the company's user 
data indicate that there is not much interest in the port.
- Keeping the port alive and up to date is a big effort (I will spare 
the details but can of course elaborate further if there is interest). 
The company decided developers' time is better spent in other areas. By 
dropping the dedicated UWP port the company's Windows developers can 
concentrate on our "classic" win32 port and other areas that didn't get 
the attention they needed.


All in all, we hope that dropping support for the UWP port will result 
in higher quality for other parts of Qt. From the company's point of 
view this benefit outweighs the "reduced cross-platformness of Qt" as 
the port is not used that much anyway.


Backends that use UWP APIs (bluetooth, sensors and positioning for 
example) are not affected by this decision and there will most likely be 
additional backends that use new MS technology.


Best regards,
Olli

[1] 
https://lists.qt-project.org/pipermail/development/2019-April/035673.html

[2] https://bugreports.qt.io/browse/QTBUG-74755
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Oliver Wolff]

Hi,

On 13.06.2020 09:20, Konrad Rosenbaum wrote:

On 2020-06-12 02:44, Hamish Moffatt wrote:

On 12/6/20 10:17 am, Scott Bloom wrote:

Why is Win7 being dropped?  I (my company) has gotten burned pretty
hard by the dropping of CentOS 6, similar reasons listed for win7..


It's funny that there's so much discussion about dropping Windows 7
which was released 11 years ago.

Yet Qt 5.15 already dropped macOS prior to 10.13, which is not even 3
years old. And Qt trunk requires 10.14, which is only 2 years old.
This is really a major PITA.



 From an industry perspective: I have seen lots of machines running all
kinds of outdated versions of Windows(*) or rather old versions of
RedHat or embedded Linux(**), but it has been a very very long time
since I have seen a machine running some Apple product of any version.
I.e. there are plenty of Windows users who have the bucks to demand long
term support for their systems, the same cannot be said for Apple users.

(*)if you walk into a running factory it is pretty normal to find a
large portion of the machines running XP, I would not be surprised to
find a W2k machine or even a machine running DOS in a factory that has
been running for 15 years. New factories will have plenty of machines
running Win7, because new OSes is simply not what the machine suppliers
care about most.


The topic of some machines that are running medieval versions of windows 
in some factory seems to come up again and again. While these use cases 
are valid, you also state that the companies "do not touch these running 
systems". So the big question that remains here is the following: Why 
would anyone update Qt on a machine like that? They have been happily 
been running DOS for the last decade and longer. On other systems they 
are using Windows XP or Windows 7. If you cannot update the operating 
system for these systems and are stuck with an unsupported OS, being 
"stuck" with an unsupported Qt version does not sound like a dealbreaker 
to me.


How many of these machines would get a Qt update if Qt 6 supported 
Windows 7?


Olli



(**)you will regularly find machines running a 2.6 kernel, some may even
run 2.4. Many GUIs look suspiciously Motif-like and if you get to see
the window manager behind the full-screen GUI it may look eerily CDE-ish
or FVWM-like.

Industry is willing to pay large amounts of support and maintenance
costs for the machines they run - this is what keeps people like Roland
and me well fed. Unless you can find a large industry or two that care
about legacy MacOS and are willing to pay tons of money for support, it
will stay bleeding edge because maintenance cost goes up exponentially
with the number of systems you have to support.



     Konrad



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Windows 7 support will be dropped in Qt 6

[Oliver Wolff]

Hi,

with Qt 6 approaching it is time to have a look at our set of supported 
platforms.


One candidate for removal of support was Windows 7. Some considerations 
about dropping this support have been communicated on Qt's development 
mailing list in March last year [1] and there were some discussions 
about this topic on the corresponding bug report [2]


The operating system was initially launched in 2009 and reached its 
official end of life in January 2020. That means that Microsoft no 
longer provides security updates and instances running Windows 7 should 
be replaced as soon as possible.


With this official Microsoft standing in mind our current plan is to 
remove support for Windows 7 in Qt 6.0 onwards. Qt 6.0 release is 
planned towards the end of 2020, roughly one year after Windows 7’s end 
of life.


Of course, we do not make decisions like this easily or to upset our 
users but there are clear advantages that speak in favor of dropping 
support:
- We can rely on Windows functions being available instead of 
trying to dynamically load libraries which might or might not be available.
- We can use functionality that only became available in later 
Windows versions unconditionally. One example of this can be UWP APIs 
which are Microsoft's "new way of writing APIs". Our new graphics 
abstraction (RHI) can also rely on newer features being available on 
Windows
- We can focus our Windows resources on bug fixes and new 
functionality instead of maintaining this "legacy" operating system
- CI resources that are used for Windows 7 tests can be used to 
test other configurations


Br, Olli


[1] 
https://lists.qt-project.org/pipermail/development/2019-March/035532.html

[2] https://bugreports.qt.io/browse/QTBUG-74687
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Oliver Wolff]

Hi,

On 12.06.2020 02:17, Scott Bloom wrote:

One thing that I probably missed in this thread, though I have been reading it 
with quite a lot of interest.

Why is Win7 being dropped?  I (my company) has gotten burned pretty hard by the 
dropping of CentOS 6, similar reasons listed for win7..

Is win 7 being dropped because the Visual Studio versions being supported, can 
no longer target Win7?


From the R perspective the main reason for dropping Windows 7 is 
"resources". We just do not have the manpower/processing power to 
support every configuration out there. Some examples for the decreased 
maintenance effort are shown in initial mail, the mail that was sent 
back in March last year and inside the bug report.


That having been said this discussion wasn't done by R alone. Other 
departments like product management were involved and according to the 
available customer data dropping support for Windows 7 should be "ok". 
Of course dropping support for an OS is never ideal but weighing up pros 
and cons we came to the conclusion that Qt6 is the right time to do this 
cut.


Of course not everyone will agree on this conclusion, but that's the way 
the decision was made.


BR, Olli



Our customers (multi-national, semiconductor companies) often will not change OS's the moment a 
chip design is started.  They "may" patch security, but often, they simply limit access 
to the outside world so connectivity security is not really their concern. The applications aren’t 
"online" they are usually command line drive, with UI interfaces for debugging the issues 
found.

We still had to support CentOS 5 until about 2 years ago, when our customer 
finally was able to drop it in their process.

For CentOS 6, I understand it was for enhancements in the Qt functionality.  
However, I think it’s a major mistake for any MAJOR version to drop an OS.  
Adding is fine, but dropping shouldn’t happen.

If I were king for a day, if its "mostly source compatible" then the OS (and 
compilers) should still be supported.  In this case, unless it’s a patch required on the 
compiler (to fix a bug) I should be able to build Qt 5.X even if it requires a dev-tools 
patch.  Same for Win7 and VS 2013.
  
Moving from Qt5 to 6, I am ok with dropping Win7 and/or CentOS 6.  I disagree with Roland here.  Yes, it would be "better", if I could easily build against the latest version of Qt, and build it for an ancient version of any particular OS. But in order to do that, I would expect the configuration options would go insane.  Any item that doesn’t build for that OS (it might not have that functionality that code was added for a newer version of the OS) would have to be ifdef'ed out via configuration. It’s a possible but expensive solution.


However, I do think, and from a commercial license holder POV (which my current 
company is), in general it is really painful when an OS is dropped from one LTS 
to another.  We are actually hitting that issue right now.  We want to move to 
5.15, but have a 20 million + a year, contract tied to CentOS 6.  We really 
can't even consider  dropping centos 6, instead we have to port Qt to CentOS, 
or stay on the last version of Qt that built on it.  It’s a really crappy 
position to be in.

Telling a customer such as us, for Qt 6, you cant build for CentOS 6, would 
mean, we would simply stay on the Qt 5 tree even longer, and likely pay for 
extended support until we could move off of CentOS 6.  But we know of bugs, 
that directly affect us that have been fixed in newer versions of Qt, and we 
wind up having to back patch them to the Qt we are using, so we can still 
support our OSes

Scott

-Original Message-
From: Interest [mailto:interest-boun...@qt-project.org] On Behalf Of Roland 
Hughes
Sent: Thursday, June 11, 2020 4:57 PM
To: Sérgio Martins 
Cc: Qt Project 
Subject: Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6


On 6/11/20 6:07 PM, Sérgio Martins wrote:

On Thu, Jun 11, 2020 at 9:51 PM Roland Hughes
 wrote:


On 6/11/20 1:47 PM, Michael Jackson wrote:

Windows 7 is EOL. Period. If it costs you, as a developer, additional money to 
support an EOL'ed, unsupported version of an operating system then you will 
need to pass that onto the customer. By still supporting Windows 7 we, as 
developers, are just enabling those customers to keep from updating. There are 
very few real reasons*not*  to update to at least Windows 8. At some point the 
customer needs to understand that they are not going to get any new features. 
They current piece of software will keep working (Assuming a perpetual license) 
but nothing new will be supported. I've had requests to back port our software 
to CentOS 6 and once you explain the cost to them for us to maintain all the 
extra development hardware, extra engineering to develop codes that are not 
supported on the old compilers, it becomes cost prohibitive to maintain those 
versions.

Personally I don't think anyone should be running 

Re: [Interest] [Qt BLE] multiple devices connected to an app

[Oliver Wolff]

Hi Simon,

On 14/12/2020 16:36, Simon FEUTRIER wrote:
I don't really have something useful to share and my code is quite big. 
Moreover it is mainly inspired by the lowEnergyScanner example.


Here is my algorithm for BLE :
-> MainWindow initiates a class called "apiComBluetooth".
-> Then MainWindow calls ApiComBluetooth.startDiscovery() which is just 
QBluetoothDeviceDiscoveryAgent.startDiscovery()
-> After 5 seconds, the ApiComBluetooth receives the signal of 
discoveryFinished. It sorts devices that I want and stores them in a 
list of BleDevice (bluetooth device class like in the lowEnergyScanner 
example).
-> Then the (only) service that I use starts to be discovered for each 
BleDevice created.
-> To write or read to a specific device, MainWindow just accesses the 
right device in the BleDevice list using an index. 
"WriteCharacteristic" or messages received in the FIFO are managed 
directly in the BleDevice class of the device.


My experience with BLE on Windows is, that everything is really 
sensitive when it comes to devices/BLE dongles and drivers. Can you give 
more information on the hardware you are using?


Windows API does not have the concept of connecting to a BLE device, so 
what we do behind the scenes is reading a characteristic if the device 
is not connected. This will trigger a connect that is initiated by the 
operating system. So the influence we have on the connection behavior 
itself is quite limited. Perhaps the hardware you are using at least 
gives some input.


Cheers, Olli



I don't know if this information can help you, thank you !

Best regards,

Simon Feutrier


Le lun. 14 déc. 2020 à 16:05, Andreas Buhr > a écrit :


Hi Simon,

On 14.12.20 15:25, Simon FEUTRIER wrote:
 > But when I write in the characteristic of the second remote
device, the
 > connection with this device is immediately lost (Invalid service
: loss
 > of connection with the underlying device)

Would you be able to share more information? Could you share your code?

best,
Andreas
___
Interest mailing list
Interest@qt-project.org 
https://lists.qt-project.org/listinfo/interest



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Bluetooth LE Peripheral on Windows UWP

[Oliver Wolff]

Hi Roberto,

As far as I know there is no blocking issue, it is just a question of 
resources.


Having said that, please be aware, that UWP support will be dropped for 
Qt6. As peripheral support is a new feature, development has to happen 
on the dev branch. The "UWP" code is still available for Qt6 though and 
will be used on desktop Windows if that backend is chosen.


If you want to have a look at the feature 
https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/gatt-server 
might be a good starting point. If there are any questions, drop a mail 
or ask on freenode IRC.


Best regards,
Olli

On 29/10/2020 08:21, cagnulein wrote:
Hi, i saw that Peripheral feature it's not available yet on Qt. Will be 
added in the future? Is there any blocking issue about it? How could i 
help you in the development?

Thanks

Roberto Viola
Software engineer and open source enthusiast
http://robertoviola.cloud 


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Bluetooth LE Peripheral on Windows UWP

[Oliver Wolff]

On 02/11/2020 09:55, cagnulein wrote:
Thank you Oliver for your response, you said that UWP support will be 
dropped, so you mean that only windows desktop (mingw and msvc) will 
continue to be developed, isn't it?


Yes that's true.

I will have a loc in the doc and i will start a dev branch. I will 
keep you updated.


Awesome. Thank you :)

Olli




Roberto Viola
Software engineer and open source enthusiast
http://robertoviola.cloud <http://robertoviola.cloud>



Il giorno lun 2 nov 2020 alle ore 09:38 Oliver Wolff <mailto:oliver.wo...@qt.io>> ha scritto:


Hi Roberto,

As far as I know there is no blocking issue, it is just a question of
resources.

Having said that, please be aware, that UWP support will be dropped for
Qt6. As peripheral support is a new feature, development has to happen
on the dev branch. The "UWP" code is still available for Qt6 though and
will be used on desktop Windows if that backend is chosen.

If you want to have a look at the feature
https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/gatt-server
<https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/gatt-server>

might be a good starting point. If there are any questions, drop a mail
or ask on freenode IRC.

Best regards,
Olli

On 29/10/2020 08:21, cagnulein wrote:
 > Hi, i saw that Peripheral feature it's not available yet on Qt.
Will be
 > added in the future? Is there any blocking issue about it? How
could i
 > help you in the development?
 > Thanks
 >
 > Roberto Viola
 > Software engineer and open source enthusiast
 > http://robertoviola.cloud <http://robertoviola.cloud>
<http://robertoviola.cloud <http://robertoviola.cloud>>
 >
 >
 > ___
 > Interest mailing list
 > Interest@qt-project.org <mailto:Interest@qt-project.org>
 > https://lists.qt-project.org/listinfo/interest
<https://lists.qt-project.org/listinfo/interest>
 >
___
Interest mailing list
Interest@qt-project.org <mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
<https://lists.qt-project.org/listinfo/interest>



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest