-
-
Notifications
You must be signed in to change notification settings - Fork 639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows Store apps: use app title as product name instead of wwahost #4259
Comments
Comment 1 by jteh on 2014-07-08 04:19 |
Comment 2 by nvdakor on 2014-07-08 06:01 |
Comment 3 by jteh on 2014-07-08 06:33 |
Comment 4 by nvdakor on 2014-07-08 06:38 |
Comment 5 by jteh on 2014-10-23 07:41 |
cc @josephsl |
Hi, hopefully we should do something about it, as there are folks still using Windows 8.x and they might encounter hoste3d apps. Thanks.
From: Leonard de Ruijter [mailto:notifications@github.com]
Sent: Friday, February 9, 2018 10:41 AM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] Windows Store apps: use app title as product name instead of wwahost (#4259)
cc @josephsl <https://github.com/josephsl>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#4259 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkAuEb6RyKnk66ENfr10VE8asH0Dmks5tTJFDgaJpZM4SAW78> .
|
@josephsl, @michaelDCurran, @jcsteh any update on this issue? I think the priority for Windows 8 store apps is quite low. in favour o0f Windows 10. Right? |
Is this issue occuring also on Windows 10? |
Hi, Not by much, as most apps do come with their own executables (including converted desktop apps). I'm leaving this open in case we can find a solution for wwahost issue. Thanks. |
Hi, And I found one: kernel32::GetPackageFullName. This function returns a serialized representation of an app package info, including name, version, architecture, and family. Each part is separated by an underscore, which makes it easy to parse this (index 0 is publisher.name, index 1 is version). I'll come up with a pull request in the next few hours. Thanks. |
…on. Re nvaccess#4259. AppModule.productName/productVersion looks at product name/version fields for the executable itself. For WWAHost, this means a generic product name (Microsoft Windows operating system) and version (Windows major.minor.build.revision) will be returned, thus not giving an accurate picture as to which app is being hosted and the guest app version. Thankfully, there is a function (kernel32.dll::GetPackageFullName) that will return a serialized package info text, which does return the actual product name and version of the hosted app. The package info structure consits of name, version, publisher, architecture and other relevant information for a package given the process ID for the app container, and is joined via an underscore character (_), with the first two indecies being publisher.name and version, respectively. Thus modified AppModule._setProductInfo for wwahost to fetch the app info via the function described above. This then allows the correct name and version of the hosted app to be returned. Note that in some cases, product version is 1.0.0.0 (especially Store app in Windows 8 and 8.1), but this can be ignored.
…via length.value. Re nvaccess#4259. Comment from James Teh (Mozilla): try using length.value instead of a dedicated buffer variable, as the function used returns nonimportant error codes instead of actual length.
Hi, Update: #10114 will resolve this through a more generic version as part of base app module, as this issue also extends to universal aps and converted desktop apps, too. Thanks. |
A more generic way of setting product name and version for hosted apps, including those hosted within WWAHost, will be used from base app module, thus this setter method is no longer needed.
… info for Microsoft Store apps. Re nvaccess#7894. User32.dll::IsImmersiveProcess won't quite cut it for Store apps: * File Explorer is seen as an immersive app but it is not really a Store application. * Converted desktop apps are seen as not immersive but they are Store apps. The more accurate way to determine this information is looking for app package info, which can be done by calling kernel32.dll::GetPackageFullName. This returns a string representation of app name, version, architecture, language, and app ID (the first two are used in nvaccess#4259). Every Store app comes with app model XML file that provides data for this structure (Store version of NVDA is no exception). Thus use this method, which is now part of a private function in the base app module so not only product name and version setter can use it, but also Store app property can call this method.
… info for Microsoft Store apps. Re nvaccess#7894. User32.dll::IsImmersiveProcess won't quite cut it for Store apps: * File Explorer is seen as an immersive app but it is not really a Store application. * Converted desktop apps are seen as not immersive but they are Store apps. The more accurate way to determine this information is looking for app package info, which can be done by calling kernel32.dll::GetPackageFullName. This returns a string representation of app name, version, architecture, language, and app ID (the first two are used in nvaccess#4259). Every Store app comes with app model XML file that provides data for this structure (Store version of NVDA is no exception). Thus use this method, which is now part of a private function in the base app module so not only product name and version setter can use it, but also Store app property can call this method.
…e process, and app architecture (#8644) * App modules: add appPath property, clarify that app module packages are also supported. Re #7894. Add appModuleHandler.AppModule.appPath property used to obtain the full path for the executable (e.g. C:\Windows\explorer.exe). Also, in app module docstring, clarify that app module packages (appmodname/__init__.py) are also supported. * App modules: add isWindowsStoreApp property. Re #7894. AppModule.isWindowsStoreApp will call user32.dll::IsImmersiveProcess to determine if the app is hosted inside a Windows RT container. This is useful for dealing with universla apps on Windows 10. * App modules: add appArchitecture property. Re #7894. appModule.appArchitecture will return the architecture for which the app is written. It can be x86 (32-bit app on 32-bit Windows), AMD64 (x64 app), or ARM64 (64-bit ARM app). This is accomplished by use of kernel32.dll's IsWow64Process2 (available on Windows 10 build 10586 and later). * App module properties: address review comments. Re #7894. appModule.isWindowsStoreApp: check if it is below Windows 8, also fixed tuple syntax. appModule.appArchitecture: variable renames to make it clear. * App modules/app architecture: use much improved is64bitProcess method. re #7894. Thanks to work on ARM64 detection in appModule.is64BitProcess: use kernel32::isWow64Process2 directly and obtain either AMD64 or ARM64, falling back to AMD64 if that Windows API function isn't present (the function is present in Windows 10 Version 1511 (build 10586) and later). * App architecture: rewrite the whole thing in order to support detection of 32-bit ARM apps. Re #7894. Windows 10 Version 1903 includes foundatoins to support 32-bit ARM apps. Because this means two 32-bit architectures must be handled, rewrite app architecture method to: 1. Record architecture to arch names inside a map. 2. Call kernel32::IsWow64Process2 first and obtain arch name fromthe arch values map. 3. If IsWow64process2 fails for some reason (Windows 7 through 10 Version 1507), return appropriate architecture name based on 64-bit process status. * App architecture: mention ARM32. re #7894. * Lint fixes. Fixes include inline comments and spaces around dictionary operator. * App properties: use a dedicated (private) method for fetching package info for Microsoft Store apps. Re #7894. User32.dll::IsImmersiveProcess won't quite cut it for Store apps: * File Explorer is seen as an immersive app but it is not really a Store application. * Converted desktop apps are seen as not immersive but they are Store apps. The more accurate way to determine this information is looking for app package info, which can be done by calling kernel32.dll::GetPackageFullName. This returns a string representation of app name, version, architecture, language, and app ID (the first two are used in #4259). Every Store app comes with app model XML file that provides data for this structure (Store version of NVDA is no exception). Thus use this method, which is now part of a private function in the base app module so not only product name and version setter can use it, but also Store app property can call this method. * Product name and version for Store apps: use the dedicated package info function. Re #7894. Use the dedicated package info function for obtaining product name and version: * If the package info is a string, info will be parsed. * If it is None, executable file info will be fetched. * Windows Store property: use package info method to determine if the underlying process is a Windows Store app. Re #7894. User32.dll::IsImmersiveProcess won't work all the way, but package info fetching will (on Windows 8 and later). Therefore use the package info method to determine if a given process is a Windows Store app. * Windows Store app property: use platform version tuple from sys.getwindowsversion(). Re #7894. * App modules/immersive package info: use length instead of unused buffer to obtain actual package info length (addressing review action). Re #7894.
…version and which app module to load (#9119) * App modules/WWAHost: update copyright header. * WWAHost: fetch product name and version via GetPackageFullName function. Re #4259. AppModule.productName/productVersion looks at product name/version fields for the executable itself. For WWAHost, this means a generic product name (Microsoft Windows operating system) and version (Windows major.minor.build.revision) will be returned, thus not giving an accurate picture as to which app is being hosted and the guest app version. Thankfully, there is a function (kernel32.dll::GetPackageFullName) that will return a serialized package info text, which does return the actual product name and version of the hosted app. The package info structure consits of name, version, publisher, architecture and other relevant information for a package given the process ID for the app container, and is joined via an underscore character (_), with the first two indecies being publisher.name and version, respectively. Thus modified AppModule._setProductInfo for wwahost to fetch the app info via the function described above. This then allows the correct name and version of the hosted app to be returned. Note that in some cases, product version is 1.0.0.0 (especially Store app in Windows 8 and 8.1), but this can be ignored. * WWAHost: load appropriate app module for the hosted app. Re #4569. Just like Javaw (hosted Java apps): different app modules for apps hosted by WWAHost are desirable for handling individual apps. Thus fetch which app module to load via a call to kernel32.dll::GetApplicationUserModelId. The app model text consists of app family name, an exclamation point, and the app name. Because Python can't import files with exclamation marks in the middle of their name, just return the lowercase version of app name (latter half of the app model text). Note that app modules for WWAHost apps must import contents of wwahost app module in order to take advantage of package-specific product name/version field, as well as other potential services in the future. * appModules/WWAHost: docstring updates. Re #4569. Reviewed by Leonard de Ruijter (Babbage): clarify docstring, and give an explanation as to how app model text is constructed and reasoning behind returning only a portion of it. * Dev guide: add sections and an example on hosted apps. Re #4569. * appModules/wwahost: obtain length of the app module/full name string via length.value. Re #4259. Comment from James Teh (Mozilla): try using length.value instead of a dedicated buffer variable, as the function used returns nonimportant error codes instead of actual length. * Dev guide: remove confusing paragraph on wwahost notess. * WWAHost: app content should not become a browse mode document by default. Although content appears to be a webpage, it is actually part of an app hosted inside WWAHost. This includes apps from Windows 8.x days, as well as progressive web apps (PWA's) that are not really browse mode documents. Apps requiring browse mode may override 'disable browse mode by default' flag to suit their needs. * WWAHost: lint fixes. Lint fixes include splitting long lines and comment style. * WWAHost: remove product name and version setter. Re #4259. A more generic way of setting product name and version for hosted apps, including those hosted within WWAHost, will be used from base app module, thus this setter method is no longer needed. * appModules/wwahost: update copyright header * appModules/WWAHost: remove bulk of app module class apart from browse mode off flag. Comment from Mick Curran (NV Access): in 2012, WWA Host app module was reponsible for turning what was essentially a web application into a proper 'application'. This was needed prior to introduction of browse mode flag for app modules. Now that this flag is present, there is no need for role coercion anymore (users can toggle browse mode instead).
Reported by nvdakor on 2014-07-07 13:10
Hi,
Currently, when invoking appModule.productName for a Windows Store app, NVDA says "Windows operating system". Although this is fine for built-in apps such as Bing Weather and Windows Store, this may confuse users and developers when they are testing accessibility of Store apps (both existing ones and apps to be created in the future). As a way of providing actual product name for debugging purposes and for people to tell us which app they are having issues with, I propose using app title for productName.
Before:
After:
Implementation:
Thanks.
Blocked by #4569
The text was updated successfully, but these errors were encountered: