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 cannot remember if there is a reason I chose to use empty lists.
If there is, I'll rediscover it and write a comment. Until then, it
makes sense to use clear as an explicit clearing of the list.
1. When the list is long, scrolling back up to hit to search
button is annoying.
2. If you select too many, there's no way to know if you're
going to wind up constructing a search with 0 results thus
wasting your time.
I've been thinking about this for a while but couldn't think of
the perfect way to implement it. I still haven't, so instead I'm
just starting with something and we'll see how to improve later.
At any rate, I can update the rest of the system to expect Albums
coming out of search so that if I ever have a better algorithm
everything else will already be ready for it.
For this first experiment, just any photos that are part of an album
will send that album out as a result. It doesn't even respect the
limit parameter, it's really just to see how it feels to use.
Unfortunately these cards are taller rather than wider so the
already-neglected unlink buttom becomes even more horizontally crammed.
That's going to need a big fixup anyway.
The two-sided margin was meant to create a particular spacing on the
albums page, but the purpose of cards is I should be able to use
them in many other contexts. So an all-round margin is easier to
work with when displaying cards anywhere else.
With a name like add_searchtag you'd think it'd be past the point
of reading box input, and deeper into the abstraction zone. But nope,
it wasn't. I'll try to take this a few steps further from here too.
I think at one point I was using full qualnames on the tag objects
in the mmf uls. But now they just show their base name, so this
code is useless. And I don't think I'll reinstate it because tags
have multiple parents now and I don't want to implement all the
lineage checking in the client js. We'll just let the server handle
the slightly less efficient query.
The problem was that during the expansion of A, B would get added to
the `total` set. And then because B was already in total, it would
bail early instead of expanding, but that meant it got left out of
the final query. But this only happened sometimes since random set
ordering would sometimes expand B before A and everything was ok.
I think the best solution is to do this first pass that eliminates
ancestors. Furthermore, I realized that the entirety of expand_nested
hinged on this flawed logic and was otherwise completely redundant
for a simple list comprehension.
