On Mon, 2016-06-06 at 13:43 +0200, Bastien Nocera wrote:
As nobody has replied, and you asked me to look at the mail, here it is. Given the long mail and the incredibly specific application of it, it's unsurprising that there were no answers, and I'll try to explain why.
Thanks, Bastien. I've created a page at https://wiki.gnome.org/Design/OS/CertSelection for this. To keep things simple I've reduced the scope — from the overall "cert + key chooser wizard" flow (which is fairly uncontentious) to just the internal widget which gets used twice to choose *an* object. That's the part we really need help with. The design used in the Red Hat user study was based on a file chooser, with additional 'shortcuts' in the places_sidebar for the PKCS#11 tokens. It seems quite intuitive for the user, and could be made to work well: https://bug679860.bugzilla-attachments.gnome.org/attachment.cgi?id=322663 The problem is that this is non-trivial to implement without access to internals of the GtkFileChooser widget, and there is understandable resistance to providing that. (As a straw man proposal, we can *already* add shortcuts with 'pkcs11:' URIs, so one way we could implement this is by just adding a way to register an widget to live in the browse_files_stack for a specific URI protocol. So 'file:' is built-in, and you can add others. You might even pretend this is a cleanup and handle things like 'Other Locations' that way instead of with special cases in the main code). I've even considered a hack where I register the additional shortcuts for the PKCS#11 tokens, but when they're selected I flip *away* from the GtkFileChooser (which can't handle them) to something else which looks identical to it — with a shadow of the same places_sidebar, but with the Seahorse-like PKCS#11 object browser in the middle. And when the user selects a file shortcut again, we flip back to the real GtkFileChooser. But... ick :) So for now we've side-stepped the issue by having explicit buttons for the user to press for 'Choose from file' vs. 'Choose from PKCS#11'. Once we've finished the cosmetics, we end up with something which is basically the same as our "ideal" idea above — it's just that the location pane can only show file locations *or* PKCS#11 locations at any one time, and you have to "change modes" to flip between them. It seems hard to justify that from the design/UX point of view; only from the "oh, it's too hard to do it nicely" point of view. It's that conflict I'd appreciate help resolving. If anyone can come up with a design idea that *doesn't* involve "nasty hacks" to the file chooser, that would be great. I'd also settle for a consensus from the design side that "we're in this to make it work nicely for the users, not to make life easy for the implementers. Just get on with it" :) Perhaps a slightly less intrusive request for GtkFileChooser is "let us hide this places_sidebar". Then I can put my *own* places_sidebar next to it and I *can* flip to a more appropriate object chooser when it's not a file shortcut that's selected? Thanks! -- David Woodhouse Open Source Technology Centre David Woodhouse intel com Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature