[17:17] gee [17:17] Yeah, bonghits for everyone [17:18] who owns the file dialog? [17:18] <-- foser has quit (Ping timeout: 188 seconds) [17:19] dwmw2: Of what? [17:19] ebassi: hm, I think it doesn't [17:19] --> mclasen (mclasen@nat-pool-bos-u.redhat.com) has joined #gtk+ [17:19] --- ChanServ gives channel operator status to mclasen [17:19] ebassi: of gtk :) https://developer.gnome.org/gtk3/stable/GtkFileChooser.html [17:20] dwmw2: Pretty much whoever decides to commit to it [17:20] I have a GSoC student working on https://bugzilla.gnome.org/show_bug.cgi?id=679860 [17:20] Bug 679860: gcr, normal, gnome-keyring-maint, REOPENED , Need GcrCertificateChooser UI for selecting X.509 certificates+keys from files or PKCS#11 [17:20] federico is the on-and-off maintainer [17:20] better question: Who wants to have opinions about it :) [17:20] for NetworkManager etc. we need a 'Certificate Chooser' dialog [17:20] certs/keys often come from files, and sometimes from PKCS#11 [17:20] ebassi: I think the input event handling is limited to the plugin host [17:21] we have a UI mockup at https://bug679860.bugzilla-attachments.gnome.org/attachment.cgi?id=322663 [17:21] <-- slomo_ has quit (Quit: Leaving) [17:21] the concept is that the PKCS#11 tokens (gnome-keyring, any hardware tokens, etc.) appear as extra 'locations' in something that looks a lot like the existing file dialog [17:21] we're trying to work out how to implement that. [17:21] with minimal (if any) changes to the generic file chooser code, of course. [17:21] heftig: they have smooth scrolling, if they're disabling xi2 gdk, they surely do [17:22] heftig: no wonder that they choked with touch events :) [17:22] --> Wulf4 (Wulf@x4e368741.dyn.telefonica.de) has joined #gtk+ [17:22] garnacho_: smooth scrolling only works when the gdk_disable_multidevice call is disabled [17:23] so they do use scrolling events from gdk [17:23] dwmw2: I have some opinions on the general design, but putting that aside, I think you should look at how the placesview was integrated in the file chooser [17:24] <-- Wulf has quit (Ping timeout: 183 seconds) [17:24] --> tristan (tristanvan@208.113.48.59) has joined #gtk+ [17:27] <-- mcrha has quit (Quit: That wasn't me) [17:27] mceier mclasen [17:27] mclasen: cool, thanks. we'll take a look at that. [17:27] --> marvin_ (marvin@77.118.29.138.wireless.dyn.drei.com) has joined #gtk+ [17:27] opinions more than welcome :) [17:28] dwmw2: I would have expected things to be the other way around, maybe: a certificate chooser that also lets you pick files [17:28] this looks more like a file chooser that happens to offer certificates too [17:29] either way we want to use the core of the normal file chooser when we're choosing files, surely? [17:29] we're trying to avoid a top-level choice of 'file' vs. 'pkcs11' leading to a new dialog for each type [17:29] when they can both just be different locations in the same dialog [17:30] You could have a dialog with a CertificateChooserWidget and a GtkFileChooserWidget inside a GtkStack [17:30] <-- visarion has quit (Client exited) [17:30] With a stack switcher in the header bar to choose between a certificate and a file [17:31] that might be an interesting approach [17:31] or magically switch when a file/pkcs11 Location is chosen in the side panel :) [17:32] I think the UX designer did evaluate the "first choose file vs. pkcs11" option, and didn't rate it. [17:32] I'll dig out the report [17:35] <-- andlabs has quit (Ping timeout: 183 seconds) [17:39] --> andlabs (pietro@198.72.11.1) has joined #gtk+ [17:40] <-- mythos has quit (Ping timeout: 184 seconds) [17:40] <-- hughsie has quit (Quit: Leaving) [17:44] note that the common use case right now *is* files; that's all that's been supported through the UI so far [17:44] to use PKCS#11 you've had to hack the config files manually :) [17:51] <-- jimmac has quit (Quit: jimmac) [17:54] <-- vlad has quit (Client exited) [17:56] <-- givascu has quit (Ping timeout: 182 seconds) [17:59] --> owen (otaylor@nat-pool-bos-t.redhat.com) has joined #gtk+ [18:02] <-- gwidion has quit (Ping timeout: 184 seconds) [18:03] --> gwidion (gwidion@ec2-54-207-29-42.sa-east-1.compute.amazonaws.com) has joined #gtk+ [18:05] ebassi, mclasen: I just forwarded the UX report [18:07] I go tit [18:07] --> mythos (mythos@chello080109225139.4.klafu.surfer.at) has joined #gtk+ [18:08] I will quote that out of context [18:08] :) [18:09] I do very much prefer having the PKCS#11 tokens as 'Locations' in what basically looks like a file chooser, instead of having a higher-level choice of file vs. pkcs#11 [18:10] --> givascu (gabriel@p3.eregie.pub.ro) has joined #gtk+ [18:11] how widely do we expect this chooser to be used ? [18:12] I think shoving a completely different widget inside the file chooser is not going to be nice, from any party involved [18:12] everywhere in NetworkManager+VPN configs that currently uses a file chooser to select certs/keys. [18:12] It's already an impressively complex beast [18:12] --> mcrha (mcrha@46.13.62.8) has joined #gtk+ [18:13] I guess Evolution should end up using it too because it lets you choose a cert for S/MIME signatures. But that's slightly different because it's currently afflicted with NSS :) [18:13] but aybe [18:13] Plus, it would need to live inside GTK forever [18:13] the intent was to put it in GCR [18:14] but now we're looking at just how tightly (if at all) to couple it to the existing file chooser [18:14] the file chooser is not quite extensible like that [18:14] I know :) [18:14] although we do have apis like gtk_file_chooser_add_shortcut_folder [18:14] right [18:15] <-- alex1a has quit (Ping timeout: 182 seconds) [18:15] One option might be to allow the internal widget (the main part of the file dialog, so the right of the locations) to be overridden. MAke it a GtkStack and let me put my own widget in there [18:15] do you need a custom view for this ? [18:15] I could register it as a handler for pkcs11: URIs. [18:16] it would look a bit like Seahorse does when listing the certs/key within a given token [18:16] it isn't filename-based at all. [18:16] So not even representable via gvfs hackery [18:17] maybe it should ? [18:17] maybe it should be filename-based? [18:18] be representable via gvfs hackery, at least ? [18:18] that's at least a somewhat well-defined extension point we already have [18:19] I'm not sure how that could be made to work. [18:19] But we'll take a look [18:19] gvfs is fairly strongly based around *files*, surely? [18:19] and we really need to have a certificate-specific UI for displaying these [18:19] using the GCR widgets [18:20] i'd be loathe to add custom uri scheme hacks that don't go through gvfs [18:20] even if you just farm it out to the caller to provide a widget? [18:20] we may already do that internally, I'm afraid [18:21] but this would make it public api if you want to use it from gcr [18:21] Is it normal that this code refer to a class that is never set to a node? https://git.gnome.org/browse/gtk+/tree/gtk/gtkrender.c#n914 [18:21] extensions are like drugs: you have a really good time at first, but then you're stuck for the rest of your life [18:22] --> Kekun (Kekun@fac34-h03-176-151-16-46.dsl.sta.abo.bbox.fr) has joined #gtk+ [18:22] yeah [18:22] my alternative thought was to put a file chooser inside a gtkstack. the other child would be my own widget that looks the same... left-hand pane of 'Locations' and all [18:23] I'd manually mirror the setting of the locations from one to the other, for cosmetics. And when a PKCS#11 location is chosen, I flip the whole stack so the FileChooser isn't visible; mine is [18:23] but that's horrid [18:24] Celelibi: it's never set inside gtk, but gtk_render_handle is public [18:24] that sounds maybe slightly better, but the file chooser pieces are pretty tightly coupled; not easy to just get a 'naked' file list without the surroundings [18:24] that was a different idea. [18:25] <-- awalton has quit (Ping timeout: 182 seconds) [18:25] The one I was trying to express there was that I just implement the *surroundings* [18:25] emphasis on "just" [18:25] heh [18:26] yeah, as opposed to the naked file list part, by which I assume you meant the main body, *not* the location pane and other surroundings. [18:26] <-- mitch has quit (Ping timeout: 182 seconds) [18:26] baedert: You mean something else could add this class to a node? [18:26] by far the easiest, implementation-wise is the hierarchical approach that ebassi mentioned first [18:26] Celelibi: yes [18:26] yeah. But it's not the best UI-wise. So I'd really like to see if we can do better. [18:26] Like... an extension? [18:26] like whatever uses tgk [18:26] *gtk [18:26] Ok. [18:27] Anyway, how can I get it to render to builtin pane separator on my pane separators? [18:27] -to+the [18:27] dwmw2: you could also do a 2-level thing more like the file chooser button: a combobox that offers you the certificates / tokens that are on the system, with a "Select file..." at the bottom [18:28] a combobox doesn't work well [18:28] <-- mcrha has quit (Quit: That wasn't me) [18:28] you really want the kind of list that Seahorse gives you [18:28] same reason you don't want a combobox of the files on the system :) [18:29] * mclasen launches seahorse [18:29] long list of "(null) Issued by: No names" [18:29] not a very awwesome list [18:29] heh [18:30] <-- achadwick has quit (Quit: Ex-Chat) [18:30] "the list that Seahorse gives you, modulo its stupid bugs and if you actually have any relevant certs" [18:31] http://david.woodhou.se/seahorse.png [18:31] is a slightly better example perhaps [18:31] * grawity never quite understood how those three databases under "Certificates" differ and where they're usable [18:32] what does the application get when the choice is made ? the file chooser returns a path or GFile [18:32] I don't know why we have separate 'Gnome2 Key Storage' vs. 'User Key Storage' [18:32] those are both from gnome-keyring [18:32] mclasen: a PKCS#11 URI [18:33] cf. https://fedoraproject.org/wiki/PackageMaintainers/PKCS11 if you care :) [18:33] or just RFC7512 [18:34] but tl;dr: there's a standard URI format for referencing objects in PKCS#11 tokens. [18:34] --> mcrha (mcrha@46.13.62.8) has joined #gtk+ [18:35] The certificate chooser would allow a cert and key to be chosen, and perhaps demand a passphrase or PIN from the user too. It would return the URI (be it file: or pkcs11: ) for both, and the passphrase or PIN if necessary. [18:35] you can have a mix — cert from one and key from the other. [18:35] the more you describe it, the less I see it fitting in the file chooser, tbh [18:36] and it's possible for both to be in the same location too (in the same file, or referenced by the same pkcs#11 uri) [18:36] that part is outside the file chooser (the cert vs. key etc.) [18:36] that is definitely in the widget that *uses* the chooser. [18:36] --> mitch (mitch@p5DDEB62A.dip0.t-ipconnect.de) has joined #gtk+ [18:37] all we're looking for with the file chooser is the way to cope with pkcs#11 "Locations" nicely, without having to have that separate top-level file vs. pkcs11 choice. When Locations do it so nicely from the UX point of view. [18:38] which we *can* try to address, as I say, by using a gtkstack with one file-chooser child, and one child which is our own thing that *looks* a bit like the outside surroundings of the file chooser (including the locations pane). And magically, hackishly switching between them depending on which location is chosen. [18:38] but ick. I'd rather cooperate with the file chooser to render my own inner pane. All you have to do is let me install the widget and switch to it at the right time :) [18:38] if crypto people could have stuck to the file system, you wouldn't have this problem now [18:38] And people would be able to copy keys from the file system. [18:39] crypto hardware lets you *use* the key, but doesn't let you *have* it [18:39] wouldn't that be nice [18:39] --> jimmac (jimmac@62.209.197.191) has joined #gtk+ [18:39] nice for some :) [18:39] others consider it a bad idea. [18:39] There have been times when I could have been fired for keeping my VPN certificate+key in a *file* on the file system, instead of in secure hardware. [18:40] true [18:40] "I have lost my hardware" is a whole lot different from "Someone may have copied my key from my file system" [18:40] obligatory mention of bad people stealing foxconn's .p12 private keys [18:40] :) [18:40] so yeah, we really do need to support pkcs11: uris as first-class citizens, and come up with a decent UI for selecting pkcs#11 objects instead of just files [18:41] hence tyagi-prashant's GSoC project this year :) [18:41] --> tyagi-prashant (tyagi-pras@14.139.82.6) has joined #gtk+ [18:41] but now you're arguing that tokens/certificates are intentionally different from files: you can't copy them, you have to unlock them with passphrases, and whatnot... those are all arguments against shoehorning these special objects into the file chooser [18:41] hi tyagi-prashant [18:41] since it is a file chooser, not a 'choose anything that people stick a uri on'-chooser [18:41] ahh, i think i am late :) [18:41] hehe. I'll send you a log [18:41] ok [18:42] i mean you could implement a gvfs backend that has all this stuff, and exposes pkcs11 tokens as GMount/GVolume etc