Good question, I was a little vague sorry.
So targetHeight here is whatever row height we are hoping for. Eg in my examples for this post we were aiming to have each row be 180 pixels tall. You’d match this with the height used in the layout algorithm.
I don’t know sorry, it’s been a little while since I was on the team. I’d suggest either leaving feedback within the app (they do read it), or messaging the official twitter account and hope they pass it on to the design team.
Interesting. I haven’t seen this issue before and unfortunately don’t have any better answer than the support post. I’d encourage filing the feedback to help the team debug it — I’m actually no longer working on Photos so can’t dig in.
We did do user testing (lots of it) and while this tested well, I can see the case for other layouts. The mobile clients does let you view as square cropped (you can pinch-zoom between layout modes) so maybe the web team could add that in future.
Oh the good news is you can :) If you select multiple photos (either checking them, or you can shift-select by holding shift when you check the first and last photo) you can then edit the date & time for the entire selection at once by clicking the three dot menu.
Photos uses an internal Google framework, Wiz. It’s been publicly described (by one of the creators) as almost identical to Stimulus, but I’m unfamiliar with Stimulus so can only trust that it’s so. Wiz handles the controllers/models/views, and Photos leverages Closure for the templates, and JsAction for the event delegation (both Closure and…
Basically, instead of immediately creating IMG tags (which would trigger loading), we create an array of photos to load, and specify batch size of how many to try load at once. Then we grab the first X (eg 10) photos from that list, create a new image and listen to the load event to know when it finished. Each time a photo finishes loading, if there…