With the recent addition of search_embed iframes on other pages, we
had photo cards appearing but the photo_clipboard module was not
imported thus the checkboxes did nothing. I don't want to import
photo_clipboard onto every single page, I'd rather they click through
to the full search UI. Otherwise every single page will have the tray
and often not a good enough reason for it.
So, since the functionality of the checkbox is completely reliant on
the photo_clipboard.js module anyway, there's no reason not to have it
generated by that module.
Previously, then the tags list was very long and dominated the scroll
height of the page, the #right and thus the photo would be floating
halfway down the page. By making it sticky, the photo always occupies
the correct position in the viewport no matter how long #left gets.
The current system has bad performance when you've got 100,000+ tags.
I discovered that when the server returns 304, the browser gives the
ajax a 200 with the full response, and it's not clear to me if js can
know it got a 304. So, the tag set is being fully re-parsed from the
response on every page load. I was thinking that I should store that in
IndexedDB to avoid the parsing step, but... since the JSON.parse is
done by my common.get before it hits this function, it's meaningless.
Not to mention I still have to rebuild the datalist on every page since
of course that state isn't shared between tabs. Not worth the DB stuff.
We'll see what happens next.
There was always some semblance that two blank lines has some kind of
meaning or structure that's different from single blank lines, but
in reality it was mostly arbitrary and I can't stand to look at it
any more.
Any properties that are different in wide/narrow mode should be defined
in the correct media query. I got tired of having wide mode be the
default and then narrow mode having to unset/initial all the attributes
that aren't relevant to narrow.
Instead of requiring a page refresh to see the new tags. They
just won't be sorted.
Slight bummer, the datalist dropdown pretty much obscures the
whole thing anyway.
I think my original reason for doing this was to prevent the button
from being operational until after the spinner initialization has
completed, so you don't get any weird half-functional spinner buttons.
However, in practice I'm finding that I constantly forget about this
and it adds tedium to creating spinner buttons.
Will review if any actual problems come up.
I tried putting them in the #left but it was looking seriously ugly.
Actually #left is always ugly because the variety of info and buttons
and text alignments. Hover toolbox is not ideal and I don't want it
to become a dumping ground, but deleting should be a rare action and I
don't want it right next to stuff like the basic metadata.
