FinalBlocker +1

FinalBlocker +1

Just a question: can anyone use the OSK at anaconda or gnome first run (the setup steps)?

Just a question: can anyone use the OSK at anaconda or gnome first run (the setup steps)?

I can verify the beta-1.5 ISO (GNOME 43.beta) has the OSK keyboard working in VM. But my install on my tablet pc is GNOME 43.0

FinalBlocker +1

FinalBlocker +1

FinalBlocker +1

FinalBlocker +1

FinalBlocker +1
With gnomeOS nightly this doesn't happens.

I'd like to see a vote from someone from the Workstation team here. @chrismurphy @aday @catanzaro or @bcotton

FinalBlocker +1

FinalBlocker +1

AGREED AcceptedFinalBlocker

The following votes have been closed:

• Accepted FinalBlocker (+9, 0, -0)
  • +1 by doomsdayrs, fruit, theevilskeleton, lruzicka, kparal, bittin, geraldosimiao, catanzaro, bcotton

FinalBlocker +1

https://bodhi.fedoraproject.org/updates/FEDORA-2022-b492fc2b7d seems to fix the issue

@mclasen @mfabian following on a bit from the still-open upstream issue, I just want to make sure we're on the same page regarding blockeriness here. The downstream bug is now closed, because the update with a backport of https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2508 got pushed stable. So as things stand we're not blocking on the remaining problems here.

As best as I understand it, this seems okay, since I think the remaining problems are all in the field of using the OSK to drive input methods, which seems really pretty niche and not worth blocking the release on. Do you both agree on that? If so, we don't need to do anything. If not, we'll need to propose a new bug as a blocker probably.

Thanks!

I would have to disagree.

There are still issues with OSK and inputting spaces, check the bug upstream as there is still ongoing discussion in regards to the OSK issue.

We know there are still issues, the question is whether the remaining issues are important enough to block the release.

I tested with my partner who has ADHD, and they stated "the keyboard is stupid".

We shouldn't be releasing with an accessibility feature in a broken state, as the OSK is useful for not just those without a keyboard, but those who can't use a keyboard and are reliant on pointer input.

Currently we are limited by how many are working on accessibility. It is know though that Fedora has become interested in supporting accessibility features, and I feel like shipping with these issues is a step back from that goal. Circa https://fedoramagazine.org/accessibility-in-fedora-workstation/

Adam Williamson pagure@pagure.io さんはかきました:

adamwill added a new comment to an issue you are following:
``
@mclasen @mfabian following on a bit from the still-open upstream
issue, I just want to make sure we're on the same page regarding
blockeriness here. The downstream bug is now closed, because the
update with a backport of
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2508 got
pushed stable. So as things stand we're not blocking on the remaining
problems here.

As best as I understand it, this seems okay, since I think the
remaining problems are all in the field of using the OSK to drive
input methods, which seems really pretty niche and not worth blocking
the release on. Do you both agree on that? If so, we don't need to do
anything. If not, we'll need to propose a new bug as a blocker
probably.

You still have to click the space bar twice after each word in OSK
(unless you click one of the buttons with suggestions). The first
space commits the current preedit, the second inserts a space.
The committing with space should already add the space.

But I would not consider that a blocker.

--
Mike FABIAN mfabian@redhat.com
睡眠不足はいい仕事の敵だ。

Release F37 is no longer tracked by BlockerBugs, closing this ticket.