idiomorph VS osxphotos

in plain htmx, you can target an area that doesn't disrupt a playing video (e.g. the comments box appending to the comments) or you can use a morphing algorithm that disrupts the DOM less.

i have my own morphing algorithm (and a corresponding htmx plugin that allows you to use it) called idiomorph:

https://github.com/bigskysoftware/idiomorph/

i've also been working with the chrome team to get a feature added they are calling "atomic moves":

https://github.com/whatwg/dom/issues/1255

this would allow us to move elements around in the DOM without losing things like play state or focus or whatever

very excited for this last idea, I think it will be a huge boon for the web in general, not just for htmx

for htmx 2.0 i'm integrating this functionality into the core

it's based on the head morphing algorithm of idiomorph:

https://github.com/bigskysoftware/idiomorph/

which 37Signals is going to integrate into Turbo for v8:

https://twitter.com/ben_pylo/status/1717975035669876790

[1] - https://htmx.org/essays/locality-of-behaviour/

i certainly hope not

the 2.0 would drop IE support, remove the older SSE and WebSocket support, and switch a couple of defaults (e.g, using template wrapping for parsing partial content, which handles troublesome elements like table rows better, but isn't available in IE) so it would be a breaking change (not for most folks, but still, breaking for some) which I only like to do w/ major versions.

we may have one major addition: a morph swap based on idiomorph:

https://github.com/bigskysoftware/idiomorph/

i'm on the fence on that one: it is currently available as an extension and maybe doesn't belong in the core, still thinking about it

so, in comparison with most libraries, 2.0 is going to be very minor

maybe I'm too close to it, but htmx feels like a hack to address things that really should be part of the HTML spec

if browsers got into the game I would assume they could do things much faster and integrate things like preload (https://htmx.org/extensions/preload/) and idiomorph (https://github.com/bigskysoftware/idiomorph/) much more cleanly w/ the rest of the browser infrastructure

idiomorph:

https://github.com/bigskysoftware/idiomorph

it's an updated take on the DOM morphing algorithm of morphdom, and it uses what i call "ID sets" to allow the morphing algorithm to "see" children in the DOM when making morphing decisions in the parents, which means you don't need to annotate the DOM with as many ids

here is a demo showing how it outperforms morphdom when ids are sparse/deep:

https://github.com/bigskysoftware/idiomorph#demo

my trick for making the `htmx:confirm` event act like it is blocking:

https://github.com/bigskysoftware/htmx/blob/a3c414dcee94fd03...

basically, redesign the arguments for a function such that I can call it again at a given spot with one parameter changed and, to a first order approximation, it acts as if the function is resumable.

I've used this hack in many places now, just recently in idiomorph to allow head elements to load before the rest of the content is morphed:

https://github.com/bigskysoftware/idiomorph/blob/e6dfc189fa3...

That being said, htmx is about 3000 lines of mostly-understandable JavaScript. Really, the only two somewhat ugly parts of the code are history support and the somewhat fancy swapping model that enables CSS transitions. And it's basically baked at this point. I plan on adding a merge-style swap (https://github.com/bigskysoftware/idiomorph), better head merging and cleaning up some rough edges in htmx 2.0, but the core API shouldn't change at all and for most people 2.0 will be the same as a point release. At that point, htmx will be done done, and just another tool to use when building websites.

> Any method that I've found to clean them up (exporting the originals, deleting them from the library, and then re-importing the JPEGs only seems easiest) will lose all of the years of metadata that I've built up in the library.

The open source tool osxphotos (https://github.com/RhetTbull/osxphotos) can help with this. You can export the JPEG images while preserving metadata using the thrid-party exiftool utility:

`osxphotos export /path/to/export --has-raw --skip-raw --exiftool`

This exports all images that have a raw pair but skips the raw component then uses exiftool (https://exiftool.org/) to write the metadata (keywords, etc.) to the exported JPEG files. You can then re-import these into photos either by dragging them or by running `osxphotos import /path/to/export/*`

Both the export and import commands have many other options for controlling export directory, etc. `osxphotos help export` or `osxphotos docs` to open docs in browser. (Disclaimer: I'm the author of osxphotos)

See the issue tracker if you want to follow along. Hopefully this is an easy fix and I can push a patch today.

In response to a question on the osxphotos GitHub Discussions page, I wrote a quick script to do prune empty albums and folders from Photos that can be run with osxphotos (version 0.65.0 and later). You can run the script directly from GitHub without downloading it first via:

You could try opening the library with PowerPhotos, a commercial app that can manage multiple Photos libraries, to see if it can read it. You could also try my free open source command line tool, osxphotos. Install it then run this command in the Terminal: osxphotos info --library /path/to/the/library This should print out a list of information about the library: number of photos, number of albums, keywords in the library, etc. If that works, then osxphotos can read the library and can likely export the photos for you so you could re-import into a new library.

I'm the author of the osxphotos[0] tool mentioned in the article. For photos in an Apple Photos library, osxphotos gives you access to a rich set of metadata beyond what's in the actual EXIF/IPTC/XMP of the image. Apple performs object classification and other AI techniques on your images but generally doesn't expose this to the user. For example, photos are categorized as to object in them (dog, cat, breed of dog, etc.), rich reverse geolocation info (neighborhood, landmarks, etc.) and an interesting set of scores such as "overall aesthetic", "pleasant camera tilt", "harmonious colors", etc. These can be queried using osxphotos, either from the command line, or in your own python code. (Ref API docs[1])

For example, to find your "best" photos based on overall aesthetic score and add them to the album "Best Photos" you could run:

osxphotos query --query-eval "photo.score.overall > 0.8" --add-to-album "Best Photos"

To find good photos with trees in them you could try something like:

osxphotos query --query-eval "photo.score.overall > 0.5" --label Tree --add-to-album "Good Tree Photos"

There's quite a bit of other interesting data in Photos that you can explore with osxphotos. Run `osxphotos inspect` and it will show you all the metadata for whichever photo is currently selected in the Photos app.

[0] https://github.com/RhetTbull/osxphotos

osxphotos is my own tool for power users to interact with Photos from the command line: export, batch edit, sync metadata, import, etc.

osxphotos v0.60.8 adds initial alpha support for macOS Sonoma (macOS 14.0.0 / Photos 9.0). Everything seems to be working but if you are beta testing Sonoma and use osxphotos I'd welcome any feedback you have!

I'm the author of the free/open source tool osxphotos which provides several utilities fo working with Photos and exporting your photos. You can use the batch-edit feature to automatically add the album name as a keyword and I believe keywords are shared across users. (I don't use shared libraries so can't confirm this). I am working on a feature to then automatically re-create the albums from the keywords on the target library. For now the keywords is a partial work around.

If you want to edit batch metadata of photos that are in the Apple Photos app on a Mac, I'm the author of a free tool, osxphotos that includes a batch-edit command that will edit the metadata in the Photos library.