17:17 Hey, desrt 17:17 I was hoping to talk to you about https://bugzilla.gnome.org/show_bug.cgi?id=686895#c20 17:17 Bug 686895: normal, Normal, ---, gtkdev, NEW , file-info: catch thumbnail files in large directory as well 17:17 thumbnails! 17:17 did we get anywhere on the last round wrt that? 17:18 desrt: I am supposed to write the patches, but I didn't get around to doing that. Meanwhile ... 17:18 ... I find myself in a situation where I am thinking of writing my own thumbnailer instead of gnome-desktop/GIO. I am hoping you can talk me out of that. 17:19 i hope so too =) 17:19 well, in fact, i don't care too much about who does the thumbnailing in the end... i have no specific attachments to gnome-desktop 17:19 Here is the situation ... 17:19 but my comments remain: it should be possible to trigger thumbnailing (perhaps even implicitly) via GIO API 17:21 desrt: We added editing to gnome-photos (which was the app for which I reopened that bug). It is non-destructive, so we never touch the original and keep the stack of operations in memory or serialize to XML. 17:21 uhoh 17:21 Now, the question: is how do I make the thumbnails in the app reflect this state? 17:22 I could have taken the image from the thumbnail cache and applied the stack of operations on it. 17:22 Except, it won't work if someone cropped the image. 17:22 yuck 17:22 do you cache the finished product? 17:22 desrt: Now, you get to convince me to not implement my own thumbnail generation and lookup code. :) 17:22 presumably some operations could be kinda slow... 17:22 desrt: No. 17:23 It is always source + stack of operations. 17:23 weird 17:23 and the user can export the photos, or what? 17:23 Well, once we run the stack of operations, it internally caches things, so its not that slow. 17:23 presumably you don't upload source+stack to flickr... 17:23 desrt: Yes they can export. 17:24 desrt, OK. 17:24 desrt: This is GEGL, by the way, so not that *weird*. :) 17:25 rishi: i don't like your app 17:25 rishi: i love its desire to preserve my originals. that's really important, and i'm glad it does that. 17:25 i don't like how it's opaque to anything but itself when it comes to viewing the photos as i believe them to be (ie: with my edits) from any other app in the universe 17:26 desrt: It isn't. 17:26 so where do i point nautilus to view the photos? 17:26 desrt: Yes they can export. 17:26 export isn't very nice because it's once and done 17:26 desrt: You click export, go to ~/Pictures/Exports. 17:27 i can't really explore my library this way 17:27 desrt: Please take up UX issues with aday and jimmac. 17:27 rishi: i'm getting to a point here: 17:28 imho you should have somewhere where the users files are kept, in edited form, as jpegs 17:28 and then you just thumbnail that 17:28 originals would be safely kept elsewhere 17:28 in the case of no changes, symlink or hardlink 17:28 in the case of changes, i guess there are a few options for recording the nature of those changes as well as the location of the original 17:29 Thats a pretty large change in how gnome-photos works 17:29 I'm not sure i agree. 17:29 but ya... i guess we will probably never have a way to geglify a file in the middle of gio's thumbnail api... 17:29 I much prefer desrt's workflow. 17:29 You're unnecessarily duplicating on-disk storage, for a usecase that is not really in the core design. 17:30 I think the question is whether the photos are "in Photos", or if they're simply managed by Photos 17:30 One of the more core questions to the UX difference, I think. 17:30 ya... and this informs where the photos are kept 17:30 alex, everything I want to do with a Photo currently revolves around using them as files. 17:30 where the 'official' copy is and if the modified one is in ~/.cache/ or so 17:30 Uploading them to Facebook or sending them to a friend. 17:31 Hitting Export seems bizarre and backwards to me. 17:31 or if the modified ones are in ~/Pictures/ and the originals are hidden away somewhere that only gnome-photos knows about 17:31 Jasper: Not clear why uploading or sending to a friend necessarily needs the "file". 17:31 rishi, because there's but no 17:32 There's GtkFileChooser but no GtkGnomePhotosChooser 17:32 Jasper: I don't understand, but ok. 17:32 Jasper: in the post-portals world this distinction somewhat disappears 17:32 of course, we're not there yet 17:32 rishi, OK. I want to upload a photo from GNOME Photos to imgur.com. Go. 17:32 Tell me what to do right now without using files. 17:33 I like the idea of the Android way of hitting the share button, but there's a problem. *It never works* 17:33 but more to the point: rishi, you're asking for an API that thumbnails *files* to thumbnail something that doesn't exist as a file... 17:33 Jasper: Are you trolling? 17:33 Every app I've ever used, when I hit the share button, crashes or blows up in some spectacular function. 17:33 rishi, nope. 17:33 * desrt finds sharing to work quite well on android.... but we're not android 17:33 desrt, haha, really? 17:33 I swear 90% of my share buttons uses end up crashing somehow. 17:34 my usecases involve the equivalent of sending selfies to telegram contacts 17:34 but ya... 17:34 :) 17:34 it more or less works, and works well 17:34 and GNOME is still miles from having that experience in any way.... least of all as a uri scheme in GIO 17:35 desrt: Yes, I agree about that: "API that thumbnails files to thumbnail ...". 17:35 rishi, I'm disappointed you think I'm trolling. 17:35 Jasper: I wasn't sure how to interpret the text. 17:36 rishi: call me crazy or a neurotic nerd or any number of things that are probably true, but i sort of like the idea that i can go and view my files in nautilus and feel safe that they are there, even if gnome-photos stops existing tomorrow 17:36 I also don't understand why it is so important what is possible right now, right here. 17:36 Jasper: ^^ 17:36 but i think a lot of people who end up running gnome are probably a lot like me... 17:37 desrt: Do you also do that on your phone? 17:37 yes 17:37 the photos on my phone are indeed stored as regular files and i periodically copy them over to my computer by usb 17:38 i don't do a lot of photo editing on my phone... 17:38 rishi, you said: Jasper: Not clear why uploading or sending to a friend necessarily needs the "file". 17:38 rishi, I'm saying those use cases *do* need the file, right now. 17:38 And I'm unsure what else HTML5 will end up doing. 17:38 Jasper: I also don't understand why it is so important what is possible right now, right here. 17:39 rishi, I don't think it's right to design UX workflows that assume the future. 17:39 rishi: because we're releasing software for gnome in 2016... 17:39 I would rather have a UX workflow that's for right now. 17:39 desrt: And? 17:39 Ok, I guess, I will write my own thumbnailer. 17:39 people want to be able to use their photos for the things they do in 2016 17:39 not have to wait until 2020 17:39 This discussion is not going anywhere. 17:40 Thanks for the chat! 17:40 rishi: did you honestly expect that i would add API to GIO to thumbnail a file with a set of gegl operations in the middle? 17:40 desrt: I am not going to use GIO/gnome-desktop if I go down this path. 17:40 the -only- way you'd be able to use GIO to do what you want is if there was some uri that contained the file, as a jpeg, in modified form 17:41 i merely suggested that it might be a good idea to do that anyway 17:41 rishi, you can put a file in ~/.cache/ and then thumbnail that. I think that's a better idea. 17:43 Jasper: Isn't that going to waste more disk space than if I were to have my separate cache? Because, I can potentially end up with (a) original (b)exported copy (c) ~/.cache 17:44 Unless I hard link (b) and (c). 17:44 rishi: you could avoid exported copies entirely if you help the user find the cached version 17:45 whether you keep that in ~/.cache/ or not then becomes strictly a question of ui design 17:45 on one side it's a bit ugly to have two copies around "visible" homedir 17:45 on the other, it's a bit ugly to open nautilus to some subdir of ~/.cache/ for the user 17:45 The hardlink-on-export approach sound nice to me.\ 17:46 or store the exported on the side of the original, hardlinked in the regular case 17:46 imho the thing that should be moved out of the way is the original 17:47 the user presumably made a change because they prefer the photo that way 17:47 That's getting into UI bikeshed territory. I agree with desrt, but I don't think it's right for rishi to make this call without input from the design team. 17:47 and yes, it's absolutely awesome that they can get the original back, losslessly... but in their mind they probably consider this to be more like an 'undo' 17:48 right... as i said, we're firmly in UI territory at this point 17:48 but even from a purely efficiency standpoint i'd assume you want cached versions of the modified photos 17:48 I think my biggest issue with the current UI is the implication that if gnome-photos ever dies or you can't start it for whatever reason, you only have your originals. 17:48 You can't open it up to export your photos out. 17:49 more likely: you find an old disk with those photos on it that won't boot on modern hardware and gnome-photos was unmaintained since 5 years and isn't in any of the modern distros 17:50 (or 100 other possible variations on the theme) 17:50 desrt: Jasper: That's not different from shotwell. Atleast you get the operations as XML. 17:50 And you could in theory use it in GIMP too. 17:50 And Shotwell is dead and doesn't compile. 17:50 So? 17:50 Darktable, then? 17:51 that's sort of the point that i was just trying to make :p 17:51 I'm saying that any modifications I made in Shotwell, well, I can't access them anymore? 17:51 Seems like a pretty major flaw and not something I'm not eager to see copied in Photos. 17:51 desrt: Jasper: And I am saying that unlike shotwell, darktable or whatever, you can in theory open the series of edits in *both* Photos and GIMP. 17:52 rishi, how can you open them in GIMP? 17:52 Or you can write your own program and open it there. 17:52 Does it also support the XML format? 17:52 Jasper: you are looking for something like Picasa where the edits are applied in place of the original, and the original stashed away? 17:52 owen, that's the UI model I would have expected of Photos, to be honest. 17:52 It's also the model of our own Photos app. 17:52 Jasper: It is a GEGL graph, serialized by public GEGL API ... 17:52 ... and GEGL is primarily meant for ... GIMP! 17:53 rishi, how do I find this GEGL graph given a path to a .jpeg 17:53 Where is it stored? 17:53 In ~/.local/share/gnome-photos/... 17:53 If I move my photos around and put them in a different folder, does this "break"? (read: undo the modifications) 17:55 Jasper: It will break, yes. Although the XML could live beside the original file too, in which case it won't probably break. 17:55 But that is a minor detail. 17:55 Jasper: I don't think you can get away with the fact that there is going to be some weirdness. 17:55 Darktable keeps it beside the original. 17:55 owen, Picasa dealt with the weirdness. 17:55 It worked if I opened files in Windows Explorer and moved them around. 17:55 Why are we not keeping it in the jpg file as metadata 17:56 alex, that barely works for rotation metadata. 17:56 well, nothing else would handle it 17:56 alex: Could do that too. That is what the toy editor in gegl does. 17:56 but it would not get lost if you move the file 17:57 Jasper: so it had some sort of recovery "identify this new file by hashing it" that allowed it to recover? 17:58 Jasper: BUt if you stopped using Picasa, dragged all your files to some other folder, deleted the old folder, then later want your originals back, you still have weirdness 17:58 alex: Although I am always scared to edit the original - bugs and what not can nuke the user's data. 17:59 owen, that's fair, I guess. 17:59 Jasper: I suppose the least "weird to the user" way is you put the edited file right next to the original as "foo.edited.jpg" and then just hide the originals in the photos app and show them in nautilus 18:00 Jasper: That's saying "both the original and the edited version are important user data and shouldn't be hidden away" 18:00 Note that currently the exported file can be of a lower resolution than the original because you can downscale it during export. 18:02 Its sort of catering to programmers/obsessive people though :-) I suspect a lot of people just don't care much 18:04 (My uncle told me that the way he dealt with not needing a ton of storage for his photos was to reduce the resolution in the camera settings, because the resolution was ridiculously large and not useful. I thought "....but!... those original bits!") 18:04 owen: The downscaling is meant to accommodate things like attaching to email where file size can be an issue. 18:06 owen, meh, the megapixel war made most of those original bits useless anyway 18:06 Jasper: Oh, I agree at one level, but commenting on my obsessiveness :-) [I don't use raw... not that obsessive] 18:08 owen, next let me tell you how most cameras default to 4:2:0 subsampling! 18:08 You only have a quarter of the chroma resolution you think you have! 18:09 rishi: yeah, export != editing, so basically the question here is twofold - a) if the user goes in nautilus/command line, is it weird if all they see is the unedited version b) if we dont' think that's weird, then is there a "data safety" issue if the user stops using Photos 18:09 owen, the original question, fwiw, was "how can I thumbnail these GEGL XML files"? To which the answer is -- write a thumbnailer. 18:09 Jasper: the pixels are interpolated anyways... 18:09 Preferably, actually, the thumbnailer is shipped in GEGL. 18:10 rishi, ^ -- why can't we have a GEGL graph thumbnailer? 18:10 Jasper: What's the point? I dont' think the GEGL XML file is a first-class citizen 18:11 owen, it's a first-class citizen in GIMP, apparently 18:11 Jasper: are you saying if you are poking around in ~/.local/share you want to see the XML files as images? 18:11 owen, I don't see why not 18:11 Eek. 18:11 Jasper: uh :-) 18:11 It makes sense to me if GIMP can open them. 18:11 owen, I would think it would be .gegl-graph, not .xml 18:11 Maybe I'm wrong though? 18:12 Jasper: But OI can see wher eyou want that for the gimp - you might have multiple images from a set of source artwork that are entirely different from the source artwork 18:12 Jasper: Have you seen Darktable's XML files? I have never heard anyone wanting to have them thumbnailed. 18:12 owen, being a native first-class citizen for GIMP makes it different, I think. 18:13 We have a thumbnailer for SVG, I don't see how it's any different. 18:13 Users would probably want a thumbnailer for .psd, which is an equivalent. 18:13 Jasper: Note that it isn't a first-class native citizen for GIMP today. This is GIMP we are talking about. New stable releases happen after half a decade. 18:14 " 18:14 The current stable release of GIMP is 2.8.16 (2015-11-21)." 18:14 Three months is a short decade. 18:14 Jasper: No. 18:14 I mean 2.8.0, 2.10.0, 3.0.0, etc.. 18:14 Uh. 18:15 I guess I'm not aware of GIMP's release schedule then. 18:15 Also, GIMP uses XCF, which is base image + gegl tree of operations in the same file 18:15 Anyway, I don't see how it is different in theory from a .psd or an .svg thumbnailer. 18:16 ebassi, I didn't mention XCF since I didn't think GIMP had non-destructive editing yet. 18:16 That's what Gegl is for :-) 18:16 But sure, .xcf thumbnailer too. 18:16 I thought it was for performing the destructive editing 18:16 ebassi: XCF isn't exactly a GEGL graph, but yes they serve the same purpose. 18:17 I thought it was for performing the destructive editing 18:17 Ask mitch or pippin about the whole story. :) 18:17 I have only understood bits of it after reading the code and talking to them. 18:18 I don't care that much -- I just know I'm going to keep using Photoshop until GIMP can do what I want. 18:18 That's fair.