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
[email protected]                              Intel Corporation

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
desktop-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to