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.
Move save_clipboard into a 0-timeout. Check checkboxes immediately
instead of relying on apply_check_all / update_pagestate to make a
redundant loop through everything.
In narrow mode, it's very possible to wind up with only 1 photo per row,
and it looks silly when they are left-justified. Centered looks a little
more natural to me in this case.
Primarily affects the "unlink" / "delete" buttons on /tags.
Without the padding we can get an extra pt of font size, and these
buttons are somewhat of a readability struggle.
Instead of defining the function with an internal if that will always
pick the same path, let's use that if to instead define a
straightforward function that just does what we want.
Since meta.status would be undefined for an incomplete request,
I would have to check response.completed && response.meta.status,
which is too much burden. Let's set the status immediately, and
if a callback wants to do further diving we'll use completed then.
- tag_autocomplete.tags and .synonyms are separate vars, not in tagset.
- tag_autocomplete.tags is now a Set object for faster resolve().
- get_all_tags moved to api.js.
- server provides "updated" timestamp with the all_tags list.
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.
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.
I'm having some performance issues with button_with_confirm on /tags.
This won't magically make that faster but I'm trying to stop the main
thread from dragging at least.
Following the previous commit about the checkbox on the /photo page,
this fixes all of the code assuming that we're dealing with photo_card
divs, the majority of which was doing nothing but accessing the id.
I'm finding weird behavior where on the main /tags page, hovering
over the tags shows the delete / unlink button without a problem,
but on a specific tag page hovering over this button causes the
rest of the list to shift a pixel or two.
I'm sure this line-height fix is nothing more than a bandaid and
not the right thing to change.
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.
