Commit graph

9 commits

Author SHA1 Message Date
Dan Stillman
9c52ebdf8b Show saved searches under "Collection" search condition
With icons to identify collections and searches

Also:

- `savedSearch` search condition in general
- Clean up some search window code
- Reorganize search tests
2016-10-06 01:17:06 -04:00
Dan Stillman
c1f7a188e2 Fix error modifying existing saved search with more than 1 condition
Closes #1056, which wasn't actually the problem
2016-07-07 07:55:15 -04:00
Dan Stillman
8e0e69332e Fix syncing of search conditions 2016-06-20 01:08:25 -05:00
Dan Stillman
2894e4f462 Fix search by collection 2016-05-06 04:31:49 -04:00
Dan Stillman
a05134e903 Fix search by file type
Fixes #966
2016-04-25 00:50:27 -04:00
Dan Stillman
b7b246e741 Saved search fixes
- Fix saved search editing
- Refresh items list on search change
- Generate correct conditions array for search JSON
2016-03-26 04:14:56 -04:00
Dan Stillman
daf4a8fe4d Deasyncification 🔙 😢
While trying to get translation and citing working with asynchronously
generated data, we realized that drag-and-drop support was going to
be...problematic. Firefox only supports synchronous methods for
providing drag data (unlike, it seems, the DataTransferItem interface
supported by Chrome), which means that we'd need to preload all relevant
data on item selection (bounded by export.quickCopy.dragLimit) and keep
the translate/cite methods synchronous (or maintain two separate
versions).

What we're trying instead is doing what I said in #518 we weren't going
to do: loading most object data on startup and leaving many more
functions synchronous. Essentially, this takes the various load*()
methods described in #518, moves them to startup, and makes them operate
on entire libraries rather than individual objects.

The obvious downside here (other than undoing much of the work of the
last many months) is that it increases startup time, potentially quite a
lot for larger libraries. On my laptop, with a 3,000-item library, this
adds about 3 seconds to startup time. I haven't yet tested with larger
libraries. But I'm hoping that we can optimize this further to reduce
that delay. Among other things, this is loading data for all libraries,
when it should be able to load data only for the library being viewed.
But this is also fundamentally just doing some SELECT queries and
storing the results, so it really shouldn't need to be that slow (though
performance may be bounded a bit here by XPCOM overhead).

If we can make this fast enough, it means that third-party plugins
should be able to remain much closer to their current designs. (Some
things, including saving, will still need to be made asynchronous.)
2016-03-07 17:03:58 -05:00
Erik Hetzner
aac1255d3d Add basic tests for full-text search
- also add importFileAttachment support function
2015-05-31 14:39:37 -07:00
Dan Stillman
ac12d5891a Rename remaining files to *Test.js
Closes #701
2015-05-19 14:46:17 -04:00
Renamed from test/tests/searchTests.js (Browse further)