Replacing Eye of GNOME and Nautilus

…and other famous last words. I’m familiar with the stack, having done some custom theming and programming for it, starting with its second major version, but I’m becoming progressively less and less happy about it.

WIP: See what my things do under Sway at all https://gitlab.gnome.org/GNOME/mutter/-/issues/217 (remove reference, part of:) https://news.ycombinator.com/item?id=23795901 also https://news.ycombinator.com/item?id=25719796

GTK+ 3, at its core, is still a decent abstraction over X11 and Wayland (not that I care about the latter, XWayland forever), and I can draw my own widgets using ‘raw’ Cairo and Pango, similarly to the way I used to in my Win32 days.^[1] Also, before I finally implemented that staggered-view file browser, I could reuse the file open dialog.

WIP: https://release.gnome.org/44/ thumbnails

WIP: Talk about, add a screenshot.

…​isn’t all that magical.

WIP: Add a section about the glow, how it’s not using the usual hack with a blurred mask as it’s actually harder to implement. Can add <canvas> with a script to show it, since it’s annoying to handle. The stupid method is CSS box-shadow, supported by GTK+.

WIP: Maybe CSS isn’t that awful after all, used a hack to do checkerboards.

Because I hate myself, and since bi-cubic filtering turns out to be quite slow in software, I decided to spend countless hours on HW-accelerated scaling. OpenGL is definitely not easy to get into. Luckily, the GDK integration is almost sane, and quite appropriate for this usecase.

WIP: Pull in notes from below.

To affirm its existence, my project needed a name and a logo. I went for describing the intent: I’m making a fast image viewer, the baseline being Eye of GNOME’s gdk-pixbuf, hence _fiv.

For the logo, or rather icon, I sketched something with lots of gradients in Inkscape, hated the experience, as well as the resulting bloated file, and remade it in clean, hand-written SVG, which wasn’t nearly as painful as I feared it would be. One day I might automatically generate a bunch of PNGs from it for installation, e.g., using ImageMagic's convert, or binaries this in turn may delegate to: rsvg-convert and Inkscape.

WIP: Link them.

Finally, I’ve made an AUR package, and a Nix derivation.

WIP: Lossless JPEG cropper.

During the time it took me to finish this article, I found out there was no decent lossless JPEG cropping GUI application for Linux. Considering this is part of libjpeg-turbo’s high-level API, I decided to make one, and fiv seemed liked the best place to put it. The reason it’s not a direct part of its UI is that I had a need for batch processing.

The primary target for the image viewer is Linux, but GTK+ is supposed to be portable.

WIP: Add some thoughts about loader servers. https://tecnocode.co.uk/2013/10/21/writing-a-gnome-thumbnailer/ is interesting (they’re https://wiki.gnome.org/DraftSpecs/ThumbnailerSpec already trying to screw it up). Note that I’ll probably want a gdk-pixbuf-alike superserver for the common formats, so that starting the program doesn’t cause a ton of fork-execs. Overrides deserve setting priorities.

WIP: Make it colour-accurate, use the full range of the visual or dithering, proper gamma handling. Displays with different profiles set might be a problem. To curb performance, it should perhaps be a special colour-correct mode, but do it wrong normally.

WIP: Unlike EoG or all GIMP version so far, fiv already supports 30-bit visuals for a subset of images, even though they do actually keep and use that visual on their windows under GTK+ 3. Dithering could theoretically be used through pixman—​Cairo doesn't expose this functionality.

WIP: Cairo can’t do RGB30_A2, so we need to avoid it for serious operation.

WIP: GIO has a lot of things that are necessary for a full-fledged file manager, so replacing Nautilus as a whole is possible.

WIP: Consider using OpenGL for scaling https://www.phoronix.com/forums/forum/software/desktop-linux/921042-gnome-s-gtk-vulkan-renderer-faster-than-opengl-now-working-on-windows?p=921725#post921725 It has great potential of making the software much faster. In theory, Cairo has a GL backend, but it’s marked as experimental, so Arch doesn't include it. Using GTK’s CSS requires going through Cairo, so OpenGL cannot otherwise be used as a rendering target for widgets. I feel like I’m doing archeology with this project. It’s a bit of a shame that Cairo has lost most of its potential, in addition to GUI rendering, I successfully employed it in the past to render PDFs.

There’s a lingering sense of sadness. Somehow, I repeatedly expect things to just be there, work well, and make sense, yet that’s rarely the case. ‘If you want something done right, do it yourself’, the saying goes. Which makes this frustrating, because the necessary time investment in software development tends to be extreme, no matter the approach. I’m an expert with deep domain knowledge (due to necessity, curiosity, and as a symptom of a pathological need to remake things how they should be). Nonetheless, I struggle.

WIP: I’ve done it. I’ve delivered value. To myself […​]

I’ve ended up with an advanced prototype, and I might or might not continue working on it later. The codebase and all the related experience may certainly come handy, if only to experiment with some ideas, but I have other things to do with my life. The best case would be to get noticed by a few senpais with too much time on their hands—​a slightly silly hope, but who knows…​ I use one of the freeëst possible licences^[2], so steal whatever you like, and shape it to your liking. I might even want to merge it!

WIP: I guess it’s not "in the meantime" anymore.

In the meantime, the most efficient course of action is probably patching up gThumb to the greatest extent upstream will let me. Or maybe restart from the (n)sxiv codebase, which builds on top of a very stable stack, and forget about the horrors of GNOME altogether—​let it go. The relationship is clearly abusive, what with the project’s heaps of chaotically destructive asshats and evergrowing complexity. Outsiders don’t really have the know-how nor resources, much less rigour, to maintain forks of it all.

Right now, having spent around a month of my life battling with perfectionism, I need a rest.

WIP: Consider adding a poll to ask whether anyone would be willing to sponsor certain features.

WIP: Seemingly possible to create a GVfs that browses imageboards.

WIP: I can’t wait for entitled users to demand features, as is usual.

WIP: https://github.com/thestinger/termite README https://linuxreviews.org/Termite_Is_Dead._Dev_Lashes_Out_At_GNOME#comment-2265 (mildly confused: libadwaita is GTK+ 4, G_DECLARE_FINAL_TYPE is only scarcely used in GTK+ 3, more points sound off)

WIP: https://github.com/eXeC64/imv might also be eligible for restarting the programming effort, though it’s remarkably low-level.

WIP: Use https://github.com/phw/peek to make a screen capture, prolly. Make it play on click.

WIP: libheif is an extremely sad thing, yet there are no alternatives for HEIC. The good news is that the library doesn’t look particularly involved.

WIP: Samsung is a joke, and a copy-cat, but they do everything badly. Proprietary segment, and panoramas/portraits only work with JPEG. HEIFs use a custom box with the same proprietary data. Add a table comparing approaches for different features. Apple Live Photo, Samsung Motion Photos. Disparity map. Samsung’s panoramatic JPEGs have no EOI marker.

WIP: Mention WWDC talks https://developer.apple.com/videos/play/wwdc2017/507 Apple’s depth map is distorted for the lens. Depth map info is in XMP. The map can be 16-bit lossless JPEG. The XMP is attached to that. The HDRGainMap (kCGImageAuxiliaryDataTypeHDRGainMap, kCGImageDestinationPreserveGainMap) is nearly unsearchable—​it’s not Dolby Vision, because that is for video, and JPEG-XT/Dolby JPEG-HDRs is a different thing which has a BSD implementation out there. "Smart HDR" sounds like a close term. But because Apple is so incredibly secretive about it, it might be proprietary. I think this form of HDR is a fairly stupid idea, but I’d still like to know what it is and how exactly to apply it.

WIP: https://invisibleup.com/articles/34/

WIP: https://gitlab.gnome.org/GNOME/gtk/-/issues/402

WIP: Only good C alternative would be Hare, once someone creates a second compiler for it, preferrably on top of LLVM. Go creates bloated libraries, and should not be mixed with C. (NOTE, replicating project/fiv notes here.) Pascal has one compiler under GPL and the last standard is from 1990/91. Ada feels like an option, but creates bloated binaries. Zig is unstable. Both Zig and Nim are a mess. Myrddin is awkward but desired but it looks dead.

WIP: Started with the intention of being fast, ended up with a better way of browsing—​thumbnails load fast.

WIP: A "thanks to" section. And a people to fund section with libjpeg-turbo author and me in it (favoured targets: speed, colour accuracy, format support), let’s see if I can find more. Make a note that sponsoring does not seem to be particularly popular.

WIP: Enlightenment https://lobste.rs/s/qfyebv/enlightened

WIP: C https://danluu.com/boring-languages/ Disclaimer: I’ll annoy you and link you to weird places?

WIP: Thanks to Bjorne Stahl (fix diacritics) for being a beacon.

WIP: https://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/ https://zpl.fi/exif-orientation-in-different-formats/

WIP: I’m a shiny light bugs are attracted to.

WIP: Qt/KDE https://www.kdab.com/fun-and-scary-code-from-qt-and-kde/

WIP: A future plan could be making something akin to Preview from macOS.

WIP: Note that I found ISO BMFF on IPFS.