To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
by allowing the generation of multiple previews at once we save on having to find, open and decode the max-preview for every preview of the same file
the main use case for this is the preview generator app (pr for that comming next)
in my local testing this saves about 25% of time when using the preview generator app
Signed-off-by: Robin Appelman <robin@icewind.nl>
Fixes#17828
* Modified the preview provider to provider smaller fonts for the
previes (so it is not so screaming)
* Modified the sidebar to show plain text and markdown files full size.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Signed-off-by: npmbuildbot[bot] <npmbuildbot[bot]@users.noreply.github.com>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The main use case here is storage provided versioning where we dont have
separate file ids for all the versions, by allowing a prefix for the
version we can store separate previews for all the versions.
Additionally, by keeping all the version previews in the same folder as the
"normal" previews they will be cleaned up properly when the file is deleted
Signed-off-by: Robin Appelman <robin@icewind.nl>
the main difference is passing the `File` object to the provider
instead of a `View` + path
Old providers will still continue to work as before
Signed-off-by: Robin Appelman <robin@icewind.nl>
Before we'd round up all preview request to their nearest power of two.
This resulted still in a lot of possible images. Generating a lot of
server load and taking up a lot of space.
This moves it to previews to be powers of 4: 64, 256, 1024 and 4096
Also the first two powers are always skipped (4, 16) as it doesn't make
sense to generate previews for that.
We cache preview pretty agressively and I feel this is a better
tradeoff.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
To allow us to create previews of files stored in appdata we need to
construct the view differently.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Else if a preview provider is registerd but not available (for example
missing support in some external lib). It will do 💥. This way the
providers can at least do the sanity checks required.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
- implement isAvailable
- run tests only if ImageMagick with HEIC support is available in the
environment
Signed-off-by: Sebastian Steinmetz <me@sebastiansteinmetz.ch>
Exporting all pages of a document to a PDF is a waste of time. All we
need is a thumbnail of the first page anyway. Plus, reading that PDF
(even just the first page of it) into imagick is presumably much
slower than reading a simple PNG.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Fixes#9469
When a version of a file is restored the previews are no longer valid.
Thus we should remove them so they are regenerated.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This code had the potential to time out. If a huge folder with pictures
for example was deleted then this could easily grow the number of files
to clean with a factor 5 (or more).
Now the previews just get cleaned up in the background. Which is good
enough for the 99% case
As a bonus this now also keeps the previews when in the trashbin so you
don't have a spiking server load when a user opens the trashbin view.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>