Match the 'emergency' bar to the new greeter design

[Fuseteam]

The bottombar used to the same color as the inputbox, let's keep that consistency~

[cibersheep]

Do you have a screenshot with the changes ^_^?

*by the way, the bar used to match the OSK background color, not the input ;)

** raised palette is used for «floating» elements like handles for sliders and switches

[Fuseteam]

I do have screenshot or two yeah here:
Essentially the white bar is now gone
With passphrase

With pin

[Danfro]

The labels now are white text. So we need to make sure we have them readable on bright screens.

I just tested with a screenshot of system settings (quick and bright).
So there is an overlay that darkens the whole screen. Which is nice.
Question is, is that sufficient? Or should we maybe reduce the transparency slightly more?
This CAN be part of this PR, but it also can be another PR.

[Danfro]

Saying that, I need to add that I like this new design introduced here. 👍

[mateosalta]

The labels now are white text. So we need to make sure we have them readable on bright screens.

I just tested with a screenshot of system settings (quick and bright). So there is an overlay that darkens the whole screen. Which is nice. Question is, is that sufficient? Or should we maybe reduce the transparency slightly more? This CAN be part of this PR, but it also can be another PR.

should be enough, if not we can revisit

[Danfro]

should be enough, if not we can revisit

True, agreed.

[cibersheep]

I do have screenshot or two yeah here: Essentially the white bar is now gone

Thanks!

I thought the idea was to match the additional bar with the OSK background color

[Fuseteam]

I do have screenshot or two yeah here: Essentially the white bar is now gone

Thanks!

I thought the idea was to match the additional bar with the OSK background color

yes that was the original intention but since the osk color is now configurable it is much more involved to read that background color now. additionally if we want to enable keyboard transparency in the future i think it will make it more complicated to match that as well.
With this we'll have a consistent design that goes along with the greeter redesign, instead of a white bar that feels out of place in all keyboard themes except ambiance

[cibersheep]

[...] instead of a white bar that feels out of place in all keyboard themes except ambiance

Well, the idea would be match the OSK background, not only ambiance, but the current OSK background color so the bar fits as part as the keyboard as originally intended :)

[Fuseteam]

guess that's a "no" then :(

[cibersheep]

guess that's a "no" then :(

What about make then «proper» buttons? Would that be too bulky?

[Fuseteam]

Not sure you have in mind for "proper" buttons

Honestly if you insist those buttons should look like a part of the osk then we'll need to figure out how to read the actual background color of the osk

The most i've found is that this is how the keyboard loads its theme: https://gitlab.com/ubports/core/lomiri-keyboard/-/blob/main/qml/theme_loader.js

[mateosalta]

[...] instead of a white bar that feels out of place in all keyboard themes except ambiance

Well, the idea would be match the OSK background, not only ambiance, but the current OSK background color so the bar fits as part as the keyboard as originally intended :)

with all the customization of the keyboard by user - it quickly gets very different from any user keybard. if we treat this as part of the greeter and not the keyboard it gets way simpler and will always match

[cibersheep]

Mhm, I see.

[capsia37]

Wow, I'm glad that you like the new design! Here are some ideas from my full design. I think that the keyboard background should be allowed to be transparent and it might be good to allow this before release. Originally I planned to move the emergency button on the cover and add an emergency information screen where you can see medical information or choose a phone number to call, but making the bar on the bottom transparent would be a good temporary solution while we get there.

[Danfro]

I do quite like that transparent keyboard background.

If the two-button-bar and the keyboard both are transparent, the button-bar does match the keyboard color, doesn't it? ;-)

The swipe to show the emergency details will almost never work since you need the keyboard to input the password/pin. I would keep the keyboard raised as default, because that is the most common action. We don't want to have to tap into the field first, wait for the keyboard animation to finish before we can input our password/pin.

But maybe the button-bar can have three sections/buttons?

cancel | emergency details | emergency call

Or do we need the cancel? We can just press power again, right?
Another idea for cancel: we do swipe on the lockscreen to get to the greeter. So have another swipe as cancel. Then the bar would only hold emergency actions.

[Flohack74]

Oh, is that not ready to be merged?

[capsia37]

The swipe to show the emergency details will almost never work since you need the keyboard to input the password/pin. I would keep the keyboard raised as default, because that is the most common action. We don't want to have to tap into the field first, wait for the keyboard animation to finish before we can input our password/pin.

I was actually suggesting to put it before the user swipes the cover away on the initial screen

But maybe the button-bar can have three sections/buttons?

cancel | emergency details | emergency call

Putting emergency call behind emergency details will help to prevent pocket calling, that was the main reason to not to put it directly there.

Or do we need the cancel? We can just press power again, right? Another idea for cancel: we do swipe on the lockscreen to get to the greeter. So have another swipe as cancel. Then the bar would only hold emergency actions.

Totally agree, swipe to get back would be very intuitive. Also power off the screen is good, I've never used the cancel button.

[capsia37]

Oh, is that not ready to be merged?

@Flohack74 I think this will conflict with the greeter rotation MR because this file will be deleted and contents moved to GreeterView instead of NarrowView and WideView. I can add these changes to that MR too.

[Danfro]

I was actually suggesting to put it before the user swipes the cover away on the initial screen

Oh, now I understand your screenshots. Thanks. I wonder why I missed that detail.

Putting emergency call behind emergency details will help to prevent pocket calling, that was the main reason to not to put it directly there.

Does make sense. Although the other way would be "one swipe away", so at least no too high a risk for pocket calling. But possible it is. One swipe is easily done.

[Flohack74]

@capsia37 would prefer to have 2 PRs on 2 different topics. But you create 1 issue where we can attribute both PRs to, and make it "Greeter optimization" or so as topic, and then list both issues.
BTW any PR or MR should also have a companion issue in the issues section, as we should only put "Issues" on the Kanban boards and project trackers. Since one issue can require multiple PRs across multiple repos, or needs consecutive PRs to fix it fully, and then tracking gets very messy. Single source of truth ;)

[Fuseteam]

Oh, is that not ready to be merged?

@Flohack74 I think this will conflict with the greeter rotation MR because this file will be deleted and contents moved to GreeterView instead of NarrowView and WideView. I can add these changes to that MR too.

oh narrowview and wideview will be merged into greeterview? would a rebase resolve the conflict?

for osk transparency we just need to remove this part:

unity8/qml/Greeter/NarrowView.qml

Lines 260 to 271 in 7346147

	// FIXME: It's difficult to keep something tied closely to the OSK (bug
	// 1616163). But as a hack to avoid the background peeking out,
	// we add an extra Rectangle that just serves to hide the background
	// during OSK animations.
	Rectangle {
	visible: bottomBar.visible
	height: inputMethodRect.height
	anchors.bottom: parent.bottom
	anchors.left: parent.left
	anchors.right: parent.right
	color: UbuntuColors.porcelain
	}

i think that should a separate pr as well as soon we can agree what we do with the bar transparency/color.
guess we need a new companion issue now.....

[mateosalta]

oh if caspia is adding it that would be great.

so to summerize:

• caspia fix bar in greeter rotation
• no cancel, swipe back
• emergency added to bottom of cover page
• rectangle behind keyboard removed to show user transparancy

[Fuseteam]

uhhh now i'm not sure how to proceed with this

[Flohack74]

related to #419

[capsia37]

Hello! I've rebased the greeter orientation on top of this, I think it can be merged.

[Fuseteam]

No complaints so far 😋

[SevralT]

I can confirm that. All works good and no issues

[Danfro]

Actually I wonder if the top margin above the last row of keys should be a bit higher. On the second screenshot here the top and bottom margins seem to be equal. Our current design has bottom bigger, and left/right/top equal.
But otherwise working good and looking good.

[Flohack74]

@Danfro if you feel that this is worth fixing then plz create a new issue, I will leave this closed and approved for OTA-22 - no blocker.