From ernesta at tiscali.cz Mon Dec 5 15:54:59 2016 From: ernesta at tiscali.cz (Mgr. Janusz Chmiel) Date: Mon, 5 Dec 2016 15:54:59 +0100 Subject: [Accessibility] is qt-opensource-windows-x86-android-5.7.0.exe compatible with Windows 10 X64 bit edition In-Reply-To: <11484460.qfNELK3zXz@frederik-thinkcentre-m93p> References: <11484460.qfNELK3zXz@frederik-thinkcentre-m93p> Message-ID: <58457FC3.1060704@tiscali.cz> Dear developers, Would you tell me, if qt-opensource-windows-x86-android-5.7.0.exe package is compatible with Windows 10 home edition? I have tried to build some sample applications, but even though I have set some environment variables, even though I have set right paths inside settings menu, build process only create series of .so files, but no .dex files and ANT Apache tomcat is not being executed to create apk package. Gradle did not worked for me. So is it possible to use this amazing package with 64 bit operating system? I have also last but not trivial plea to you. This will not be easy to solve. QT apps are very complex after build. It is using .so library, where ARM compatible machine code is presented. But QT applications are also using .dex package, which is bridge. This bridge communicates with .so library and this bridge is responsible for GUI creation. And, and it is very important for accessibility, it provides usable accessible information for screen readers. Please, try to do yours best, so this Java bridge will be reliable and enough fast. When user will swipe with his finger while using QT Android apps with active Android screen reader. I Am aware, that Java code will be always much more slower than C++ compiled machine code. But reliability of this specific Java code, which is The part of every compiled Android QT app is very important for visually impaired users. The responsiveness of process, which screen reader is communicating with it is very important. Unfortunately, many IDES, which are based on C++, compiled C++ code is The part of The compiled code are inaccessible with screen readers. Because some projects are using non standard libraries, which are being detected by screen readers as bitmap, because it behaves by this way. Android NDK apps, which are using native Android activity are inaccessible at all. Apps, which are being created by using Codeworx for Android from Nvidia corporation are also inaccessible. So for now, only QT apps or apps, which have been created by using Mosync IDE are 100 % accessible. Thank you very much for yours understanding. From frederik.gladhorn at qt.io Mon Dec 5 18:26:57 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 05 Dec 2016 18:26:57 +0100 Subject: [Accessibility] is qt-opensource-windows-x86-android-5.7.0.exe compatible with Windows 10 X64 bit edition In-Reply-To: <58457FC3.1060704@tiscali.cz> References: <11484460.qfNELK3zXz@frederik-thinkcentre-m93p> <58457FC3.1060704@tiscali.cz> Message-ID: <2173364.mztQSyCtBp@frederik-thinkcentre-m93p> On mandag 5. desember 2016 15.54.59 CET Mgr. Janusz Chmiel wrote: > Dear developers, > Would you tell me, if qt-opensource-windows-x86-android-5.7.0.exe > package is compatible with Windows 10 home edition? It should work, I don't know if the home edition brings more restrictions compared to other windows versions, but 64 bit windows should work just fine. > I have tried to build some sample applications, but even though I have > set some environment variables, even though I have set right paths > inside settings menu, build process only create series of .so files, but > no .dex files and ANT Apache tomcat is not being executed to create apk > package. > Gradle did not worked for me. > So is it possible to use this amazing package with 64 bit operating system? Yes, it generally works and we test it regularly. Please use interest at qt- project.org to ask about how to build/run examples. > > > I have also last but not trivial plea to you. > This will not be easy to solve. > QT apps are very complex after build. It is using .so library, where ARM > compatible machine code is presented. But QT applications are also using > .dex package, which is bridge. This bridge communicates with .so library > and this bridge is responsible for GUI creation. And, and it is very > important for accessibility, it provides usable accessible information > for screen readers. > Please, try to do yours best, so this Java bridge will be reliable and > enough fast. When user will swipe with his finger while using QT Android > apps with active Android screen reader. > I Am aware, that Java code will be always much more slower than C++ > compiled machine code. But reliability of this specific Java code, which > is The part of every compiled Android QT app is very important for > visually impaired users. The responsiveness of process, which screen > reader is communicating with it is very important. > Unfortunately, many IDES, which are based on C++, compiled C++ code is > The part of The compiled code are inaccessible with screen readers. > Because some projects are using non standard libraries, which are being > detected by screen readers as bitmap, because it behaves by this way. > Android NDK apps, which are using native Android activity are > inaccessible at all. > Apps, which are being created by using Codeworx for Android from Nvidia > corporation are also inaccessible. > So for now, only QT apps or apps, which have been created by using > Mosync IDE are 100 % accessible. > Thank you very much for yours understanding. The basic idea behind Qt is that it's a C++ framework. Of course it should be as responsive as possible. We specifically publish information about what we draw on screen to the java world, so that applications are accessible. Native applications on Android can be made accessible by doing some extra work which has been done for Qt. Actually all Qt apps are using the NDK and are still accessible. I know of several apps using this, so it will continue to work as long as we support Android. It may not always be at the same level as native apps, but we're trying to be as good as possible on this front. Cheers, Frederik > > _______________________________________________ > Accessibility mailing list > Accessibility at qt-project.org > http://lists.qt-project.org/mailman/listinfo/accessibility From frederik.gladhorn at qt.io Fri Dec 9 14:26:23 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Fri, 09 Dec 2016 14:26:23 +0100 Subject: [Accessibility] Please include QT accessibility as separate downloads In-Reply-To: <1969460578.20161209025506@oire.org> References: <6991128.veO3AInPxd@frederik-thinkcentre-m93p> <1969460578.20161209025506@oire.org> Message-ID: <2575446.Mf7NVX2DTW@frederik-thinkcentre-m93p> On fredag 9. desember 2016 02.55.06 CET you wrote: > Hello Frederik, > > Sorry, and what about QML apps? These still seem to be inaccessible. > Thanks! The abstraction level of QML is not the level where the accessibility information can be added in a meaningful way. You don't want every rectangle announcing itself as a rectangle, we played with the tought, did some experiments and concluded it's the wrong level of abstraction. Qt Quick Controls and other UI elements built with Qt Quick are accessible. For custom controls, the author usually only has to add Accessible.name: "some name" and ideally also Acessible.role. Cheers, Frederik