Skip to content
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

refactor(web): inactive banner management 🎏 #9988

Merged
merged 6 commits into from
Nov 16, 2023

Conversation

jahorton
Copy link
Contributor

@jahorton jahorton commented Nov 13, 2023

Accomplishes two goals:

  1. Adds support for a new HTMLBanner type, which allows specifying banner contents to be injected via innerHTML property. For devices that support it, this will take place within an attached "shadow" for the banner in order to facilitate styling isolation.
  2. Given the new banner type, I dropped the old 'select type of banner' approach in favor of 'set a Banner for use when inactive' approach.
    • This allows direct calls to banner constructors, and thus to use of constructor parameters instead of messy, semi-dissociated "banner options". Thus, it becomes clear that only data for the requested 'inactive banner' type needs to be specified.

To set the new banner type in motion...

Once KeymanWeb has initialized, make a call like this:

keyman.osk.bannerController.inactiveBanner = new keyman.osk.bannerController.HTMLBanner(`
<img style="display:inline-block; height: 100%" src="../../../../../build/publish/debug/ui/button/kmw_button.gif"></div>
<div style="display:inline-block; color: white; text-align: center">Hello World</div>
`)

(I used that in the Developer console of the "Predictive Text: robust testing" test page.)

Results:

image

The same banner will be continuously reused for the lifetime of the page unless replaced with a different assignment to keyman.osk.bannerController.inactiveBanner. (Except when predictive-text is active, of course.)

User Testing

TEST_IOS_ALWAYS_SHOW: Using the iOS-based Keyman app, verify that the image banner still works as expected.

  1. Install the iOS test artifact through TestFlight.
  2. Follow the "Get Started" instructions fully.
    • Be sure to install a keyboard without an associated predictive-text model... such as the IPA keyboard.
    • Search: IPA
    • Shows up as IPA (SIL) in the keyboard search.
  3. In the Settings menu, toggle "Show Banner" on - the toggle should gain a green background.
  4. Exit the Keyman app and open Safari.
  5. Go to google.com.
  6. Click within the main search field. When the system keyboard shows up, swap keyboards to reach the Keyman system keyboard.
  7. Swap to the default "EuroLatin (SIL)" keyboard if it is not already active.
  8. Swap to the keyboard without an associated predictive-text model.
  9. Verify that the image banner is displayed.

Note that step 7, then 8 is necessary due to #9990. That bug is not addressed by this PR; I just happened to discover it when writing this user test.

@keymanapp-test-bot keymanapp-test-bot bot added the user-test-missing User tests have not yet been defined for the PR label Nov 13, 2023
@keymanapp-test-bot
Copy link

keymanapp-test-bot bot commented Nov 13, 2023

User Test Results

Test specification and instructions

  • TEST_IOS_ALWAYS_SHOW (PASSED): 1. Installed the iOS test artifact through TestFlight. 2. Opened the Keyman app. 3. Installed the IPA (SIL) keyboard using the Get Started menu. 4. Enabled "Show Banner" from the Settings menu. 5. Enabled Keyman as the System-wide keyboard. Closed the Keyman app. 6. In the Safari browser, opened the google.com page. Clicked the main search field. 7. Swapped Keyboards to Keyman System keyboard. 8. Swapped to the "IPA (SIL)" keyboard. Verified that the image banner is displayed on the top of the keyboard. (notes)

Test Artifacts

@keymanapp-test-bot keymanapp-test-bot bot added this to the A17S26 milestone Nov 13, 2023
@keymanapp-test-bot keymanapp-test-bot bot added has-user-test user-test-required User tests have not been completed and removed user-test-missing User tests have not yet been defined for the PR labels Nov 13, 2023
@jahorton jahorton marked this pull request as ready for review November 13, 2023 08:39
web/src/engine/osk/src/banner/imageBanner.ts Show resolved Hide resolved
web/src/engine/osk/src/banner/banner.ts Outdated Show resolved Hide resolved
alwaysShow: false,
imagePath: ""
}
private _inactiveBanner: Banner;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the opposite of activeBanner? The terms active and inactive here seem really ambiguous

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... yeah, I bumped up against that for a bit. Kind of makes me want to change the .activeBanner to .currentBanner.

It might be clearer if I also split BannerView and BannerController into separate files in the predecessor PR; .activeBanner is only in the former, while .inactiveBanner is only in the latter.

Of course, there's also the timeless classic question of "... why not both?"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As of the newly-pushed commits, I've implemented both thoughts from my comment above.

web/src/engine/osk/src/banner/bannerView.ts Outdated Show resolved Hide resolved
* Builds a banner for use when predictions are not active, supporting a more generalized
* content pattern than ImageBanner via `innerHTML` specifications.
*/
public readonly HTMLBanner = HTMLBanner;

constructor(bannerView: BannerView, hostDevice: DeviceSpec, predictionContext?: PredictionContext) {
// Step 1 - establish the container element. Must come before this.setOptions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.setOptions is now gone?

Copy link
Contributor Author

@jahorton jahorton Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. That paradigm started to feel really messy once I started adding in the HTML banner, especially since it obfuscates what properties are needed for which banner. Direct use of banner constructors is far, far clearer in that regard.

@jahorton
Copy link
Contributor Author

Note: once the Android "image banner" work is done, we should absolutely test it against Android 5.0 just to be sure everything does work as intended. That work isn't available here, hence the lack of test for it.

@bharanidharanj
Copy link

Test Results

  • TEST_IOS_ALWAYS_SHOW (PASSED): 1. Installed the iOS test artifact through TestFlight. 2. Opened the Keyman app. 3. Installed the IPA (SIL) keyboard using the Get Started menu. 4. Enabled "Show Banner" from the Settings menu. 5. Enabled Keyman as the System-wide keyboard. Closed the Keyman app. 6. In the Safari browser, opened the google.com page. Clicked the main search field. 7. Swapped Keyboards to Keyman System keyboard. 8. Swapped to the "IPA (SIL)" keyboard. Verified that the image banner is displayed on the top of the keyboard.

@keymanapp-test-bot keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Nov 15, 2023
Base automatically changed from chore/web/separate-banner-source-files to master November 16, 2023 01:06
@jahorton jahorton merged commit 8ebb725 into master Nov 16, 2023
15 checks passed
@jahorton jahorton deleted the refactor/web/inactive-banner-management branch November 16, 2023 01:06
@keyman-server
Copy link
Collaborator

Changes in this pull request will be available for download in Keyman version 17.0.212-alpha

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants