we currently do 16ms for each letter.  So if the message 64 characters long, the user is going to get a second to read it.  We could potentially make the timeout longer, but of course, the message shouldn't be shown at all (see bug 720887 comment 1 )

Well since the messages are gone, this could arguably be closed, but I guess 32ms or maybe even 48ms would be a more appropriate timeout.

@MichaelCatanzaro

So now what exactly has to be done, is it to increase timeout or the message shouldn`t be displayed at all ?

@MichaelCatanzaro

I have built jhbuild, now could you pleases tell where to get the code related to this bug from ?

I would just increase the timeout. It will be a constant in one of the javascript files; I think tripling it would be a good.

All the code is in https://git.gnome.org/browse/gnome-shell/tree/js/gdm

Created attachment 299932 [details] [review]
user read time per charcher has been incresed from 16ms to 48ms

Yes, that's exactly what I was expecting. You'll want to follow the commit message guidelines, though: https://wiki.gnome.org/Git/CommitMessages

Created attachment 299979 [details] [review]
user read time per charcher has been incresed from 16ms to 48ms

Review of attachment 299979 [details] [review]:

probably okay!

I figure the only thing that can go wrong here is the message stays long enough to be annoying, but IMO distros should just not spam the user with login messages if they don't want users to read them....

Ugh ... other then the message shouldn't exist in the fist place (it shows up for a longer time then the whole login process) this patch makes it even worse.

Created attachment 300442 [details] [review]
Revert "windowManager: Block dynamic workspace updates while showing the popup"

This reverts commit aeb971c33a78308d793195127489b355bba4233a.


Seriously there has to be a better way to deal with this then slowing down 
login for messages that hardly anyone cares about.

Review of attachment 300442 [details] [review]:

Wrong commit id.

I think we all agree the last login message is a bad idea. but if it displays it should be readable. you can disable the last login message in authconfig now, and it'll be disabled by default in f22.

Created attachment 300445 [details] [review]
Revert "Give user 48ms to read each character of a PAM message, earlier it was 16ms"

Seriously there has to be a better way to deal with this then slowing down
login for messages that hardly anyone cares about.

https://bugzilla.gnome.org/show_bug.cgi?id=720885

This reverts commit 88973857146f91acd3b633234afa2c2bb358392a.

I'm of the opposite opinion: if a message is displayed, it'd be better not to log in at all until the user clicks something again to dismiss the message. Otherwise we can't know if he's read the message or not. 48ms instead of 16ms helps but it's just a hack, really: we shouldn't have disappearing messages at all.

(But I assume the messages are important. Like "4567 failed access attempts since last successful login", that should not disappear after 16ms per character. The silly Fedora authconfig spam is not what we should design for; thanks for getting rid of it, Ray.)

(In reply to Michael Catanzaro from comment #17)
> I'm of the opposite opinion: if a message is displayed, it'd be better not
> to log in at all until the user clicks something again to dismiss the
> message. Otherwise we can't know if he's read the message or not. 48ms
> instead of 16ms helps but it's just a hack, really: we shouldn't have
> disappearing messages at all.
> 
> (But I assume the messages are important. Like "4567 failed access attempts
> since last successful login", that should not disappear after 16ms per
> character. The silly Fedora authconfig spam is not what we should design
> for; thanks for getting rid of it, Ray.)

You missed the part where you explain why it is important enough that it has be read *before* login.

Its not like your computer will blow up if you get informed about the failed login attempts *after* login.

But adding a delay to that takes as long or even longer as the entire boot process on modern machines to show a completely pointless message is the worst possible user experience.

I agree that a notification after login would be better, but I have no clue if that's possible or not with PAM.

(In reply to drago01 from comment #18)
> But adding a delay to that takes as long or even longer as the entire boot
> process on modern machines to show a completely pointless message is the
> worst possible user experience.

We're agreed the messages are pointless, but that's a different bug (which as Ray says has been fixed). If a message is shown, we should assume it's important and make sure the can actually read it. Slowing down login is exactly what we want to do in this case.

* Good alternative: Display a notification after login instead, like you suggest.
* Maybe good alternative: Just don't show messages from PAM at all; replace them with hardcoded messages. (Not sure if that's feasible or desirable).
* Maybe good alternative: 32ms? Easy change....
* Not good alternative: Going back to 16ms; might as well not show it at all in this case. I can barely read it at that speed.

At any rate, I don't care too much as long as Fedora isn't using these anymore. :)

(In reply to Michael Catanzaro from comment #19)
> I agree that a notification after login would be better, but I have no clue
> if that's possible or not with PAM.

PAM just gives us the message ... we could display it in gdm, paint the screen pink; play a sound or display it after login ... pam is only involved in the "give message" part.

But anyways if most users won't see it because authconfig got fixed it should be fine for now so lets just close this bug.