12/05/14 17:41, intrigeri wrote:
> anonym wrote (12 May 2014 15:02:45 GMT) :
>> That makes a lot of sense in t-p-s since we *force* the persistent
>> container to be encrypted with a password. But for the Greeter's
>> *optional* admin password I'm note sure it makes sense.
>
> I don't think it makes any sense. Sorry, I'm probably the one who
> wrote a misleading (not to say: stupid) description on this ticket.
>
>> IMHO this change is a severe loss of functionality, and either:
>
>> 1. we have to admit that requesting this was a mistake, and keep the
>> current behaviour.
>
> As far as "can't be empty" is concerned, right, we should keep the1
> current behaviour.
Ok. Since Andres' patch doesn't add anything else, we'll have to
completely drop it. Again, I'm really sorry for having wasted your time,
Andres!
>> 3. I've completely misunderstand what the ticket asks for. I believe it
>> was you, intrigeri, who filed the ticket (before it was imported to
>> redmine). Could you please elaborate on the purpose and arguments
>> for this change, if this is what you actually intended?
>
> The rest of the suggested changes make sense to me. The t-p-s UI is
> way nicer, with a nice little warning dynamically updated as long as
> entered password confirmation does not match. And I stole it from
> GNOME Disks, iirc, which makes the UX more consistent.
Note that we have some form of "dynamic behaviour" for the error (from
commit c96200f [1]) but that it's not exactly the same as in t-p-s; the
mis-match error is only shown after trying to login when the fields
differ, and the error is immediately removed when one of the fields
change. IMHO this is a better behaviour than always showing it, at least
in the Greeter's context where we do not have a default error to show
(like "passphrase can't be empty" in t-p-s).
Given that the semantics of the fields are pretty different in the
Greeter compared to in t-p-s, please provide a detailed description of
how you think the Greeter should be changed in case you still think it's
desirable.
Cheers!
[1] Its commit message refers to "consitent [sic] behaviour when
compared to the warning shown for MAC spoofing while inside a VM", a
warning which eventually was removed since it was based on a wrong
interpretation of a bug. That's why it was implemented in a seemingly
unrelated branch (feature/mac-spoof).
