owncloud / gallery

:sunrise: Gallery app for ownCloud, which includes previews for all supported media files

Gallery

Media gallery for ownCloud which includes previews for all media types supported by your installation.

Provides a dedicated view of all images in a grid, adds image viewing capabilities to the files app and adds a gallery view to public links.

This version is for ownCloud 10.0. If you need the same app for older versions of ownCloud. Use Gallery+ from their respective app stores.

Featuring

• Support for large selection of media types (depending on server setup)
• Upload and organise images and albums straight from the app
• Large, zoomable previews which can be shown in fullscreen mode
• Sort images by name or date added
• Per album design, description and copyright statement
• A la carte features (external shares, browser svg rendering, etc.)
• Image download straight from the slideshow or the gallery
• Switch to Gallery from any folder in files and vice-versa
• Ignore folders containing a ".nomedia" file
• Browser rendering of SVG images (disabled by default)
• Mobile support

Checkout the full changelog for more.

Maintainers

Current

Alumni

• Olivier Paroz
• Jan-Christoph Borchardt (Design)
• Robin Appelman

Contributors

• All the people who have provided patches to Gallery(+) and Pictures over the years

Requirements

See this wiki article about the requirements for Gallery.

Supporting the development

There are many ways in which you can help make Gallery a better product

• Report bugs (see below)
• Provide patches for owncloud/core or the app itself
• Help test new features by checking out new branches on Github
• Design interface components for new features
• Develop new features. Please consult with the maintainers before starting your journey
• Fund a feature, either via BountySource or by directly hiring a maintainer or anybody else who is capable of developing and maintaining it

Bug reporting and contributing

Everything you need to know about bug reporting and contributing is located here.

Preparation

Here is a list of steps you might want to take before using the app

Supporting more media types

First, make sure you have installed ImageMagick and its imagick PECL extension. Next add a few new entries to your config/config.php configuration file.

  'preview_max_scale_factor' => 1,
  'enabledPreviewProviders' =>
  array (
    0 => 'OC\\Preview\\PNG',
    1 => 'OC\\Preview\\JPEG',
    2 => 'OC\\Preview\\GIF',
    11 => 'OC\\Preview\\Illustrator',
    12 => 'OC\\Preview\\Postscript',
    13 => 'OC\\Preview\\Photoshop',
    14 => 'OC\\Preview\\TIFF'
  ),

Look at the sample configuration (config.sample.php) in your config folder if you need more information about how the config file works. That's it. You should be able to see more media types in your slideshows and galleries as soon as you've installed the app.

Improving performance

Redis for files locking

Using Redis for files locking improves performance by a factor of 10 when loading an album.

Read about it in the ownCloud Administration Manual

Assets pipelining

Make sure to enable "asset pipelining", so that all the Javascript and CSS resources can be mixed together. This can greatly reduce the loading time of the app.

Read about it in the ownCloud Administration Manual

Installation

Installing from the app store

• As an admin, select "Apps" in the menu
• Go to the "disabled apps" section
• Enable Gallery

Installing from archive

• Go to the the releases page
• Download the latest release/archive to your server's apps/ directory
• Unpack the app
• IMPORTANT: Make sure the folder name is gallery

Installing from Git

In your terminal go into the apps/ directory and then run the following command:

$ git clone https://github.com/owncloud/gallery.git

Now you can activate it in the apps menu. It's called Gallery

To update the app go inside you apps/gallery/* directory and type:

$ git pull --rebase

Uninstalling

Redirect gallery link shares

When disabling or uninstalling the app, all link shares created with the app will stop working. Instead of having to resend new links to all recipients, you can setup a redirection on the server to redirect gallery-style links to regular public links. This means that people with the original link will get redirected to the regular file view instead of getting a 404 page.

For this, edit your .htaccess file in the ownCloud root folder and add a new rewrite rule among the existing ones or with a new block at the bottom of the file:

<IfModule mod_rewrite.c>
  RewriteEngine on  
  RewriteRule ^/apps/gallery/s/(.*)$ /s/$1 [L,R=301]
</IfModule>

List of patches

None so far

gallery's Issues

Work around problems introduced by the File Locking app

The File Locking app is slowing things down a lot: owncloud/core#14107 , but I found that it could also sometimes prevent the app from getting large previews.

Make the slideshow controls work with a light background

The current controls icons are dark grey and that works well with a black background as it's non-intrusive, but as soon as a picture with a white background fills the screen or if we manually switch the background to white to better see dark pictures with a transparent background, then we can't use the controls, as they become invisible.

@jancborchardt, feel free to chime in and discuss possible solutions.

TODO

All that remains are bugs which need to be fixed

• Clean up the icons
• Add missing icons

Protect the app from Preview breakage

If the Preview class breaks down for whatever reason, we get an error 500 and nothing else will happen, so we need to catch all exceptions and soften the blow.

App does not always work on IE

There are several issues when loading the app in Internet Explorer

• OC_EventSource in core does not work with multiple, simultaneous EventSource objects
• Polyfills can't seem to be able to deal with multiple EventSource objects
• IE freezes and can't decode previews sometimes https://connect.microsoft.com/IE/feedback/details/1088192/ie11-when-loading-large-number-of-images-images-begin-to-fail-to-load-in-ie11-with-dom-7009-error-unable-to-decode-in-console

Next steps

• Warn users (and be nice)
• Use a supported polyfill which can handle multiple EventSource objects
• Fix the image downloading

EventSource is not compatible with most mobile devices

EventSoure is a great way to send thumbnails as they're generated, but the problem is that it's not compatible with the most popular mobile platform: Android.

Here are 3 libraries to test as a replacement for the one found in core:

• https://github.com/Yaffle/EventSource
• https://github.com/amvtek/EventSource
• https://github.com/remy/polyfills/blob/master/EventSource.js

They're all available via bower

Implement a search engine

oC8 comes with a more efficient search engine, but the app is not yet plugged into it.

Thoughts on possible solutions

As soon as a search is started, the view and models should be cleared and thumbnails should be generated.

• If we keep the current way of building the view, then nothing might show up until a row is full.
• If we make it so that a search is authorised to ask the backend for one thumbnail as a time, then that backend may get flooded with requests (that's what the Files app is doing)

Prerequisites

• Show thumbnails as soon as they're received

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Let the user download the file if the preview is broken

If a file can't be previewed for some reason, its media type icon will be shown. We won't be showing the file in the slideshow (#33), but the user can download it, if the system can find it.

Upload straight from the app [$250]

Being able to upload files is just one click away with the "switch to files view" button, but it could be even better if we could just create folders and upload files straight from the app.

Specifications

The idea is to be able to easily drag and drop files in the current album, to be able to detect conflicts and to refresh the view once the process is complete.

• Upload via drag and drop only
• Upload to current album only. The whole photowall is the drop zone
• Upload as a logged in user only
• Upload both files and folders (Chrome only)
• Show progress bar
• Reload view at end of the process
• Conflict management (same as in Files)
• Don't block in-app navigation. Keep uploading where the upload started (same as in Files)
• Leaving the app kills the upload process (same as in Files)
• Let users upload by clicking on a button in the controls bar

Bugs

• Error 500 when uploading on an empty Gallery...
• Conflict dialogue breaks when comparing images located in folders which don't appear in the album representation

Did you help close this issue? Go claim the $250 bounty on Bountysource.

Switch quickly between Files and Gallery mode

As a user I want to be able to switch back and forth between Files and Gallery mode and not lose the folder/album I'm currently in.

Current situation

When the user is a few folders down in the hierarchy of folders, his only option is to click on the Gallery app and go inside albums until he finds the same files

Proposed solution

Add the same button which is used in public shares to switch back and forth

Large previews are not shown properly on High DPI devices

Previews should fit in the advertised screen resolution. Full screen and zooming should work.

This will stay open for a while as I can't test on all available devices...

Review the PHP

The rewritten Gallery app and soon to be called Media app needs some people to review its PHP code to make sure it's a sound base for the future.
The methods are kept short and the complexity low, in hope to make them easier to test.

5 controllers

• HTML pages
• 2 Files controllers. One for calls from within OC and one for public pages

public function getFiles($location))

• 2 Preview controllers. Same configuration as above

public function getMediaTypes($slideshow = false)
public function getThumbnails($ids, $square, $scale)
public function getPreview($fileId, $width, $height, $download)

2 middlewares

• Make sure sharing is enabled for public pages to work
• Make sure we have a valid token which is linked to a valid resource and that the user is authorised to access the page

4 services

• FilesService looks for files to show

public function getMediaFiles($folder, $supportedMediaTypes)

• PreviewService generates and fixes previews

public function getSupportedMediaTypes($slideshow)
public function isPreviewRequired($file, $animatedPreview)
public function createPreview($file, $maxX = 0, $maxY = 0, $keepAspect = true, $base64Encode = false)
public function previewValidator($base64Encode)

• DownloadService prepares content to be downloaded

public function downloadFile($file, $base64Encode = false)

• ThumbnailsService provides information about what a thumbnail should look like, specswise

public function getThumbnailSpecs($square, $scale)

1 environment class

• Holds everything that the services need in order to be able to access files

1 http response type

• Returns images (previews or files as-is)

2 other classes

• A smarter logger to make things easier before it's added to core
• A preview helper class

The code is documented, but there are some methods which are more complex than others:
https://github.com/interfasys/galleryplus/blob/master/service/previewservice.php
https://github.com/interfasys/galleryplus/blob/master/preview/preview.php
https://github.com/interfasys/galleryplus/blob/master/service/environmentservice.php

cc @MorrisJobke @Raydiation @LukasReschke @icewind1991 @georgehrke @libasys

Create documentation for developers

• Generate document base on PHPdoc
• Explain some of the workflows
• Explain some design decisions

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

no-show and high cpu load

Hi,

I get a blank page and on my server, some running processes eating all CPU:
24774 wwwrun 20 0 430424 158872 13472 R 90.03 1.942 0:31.86 httpd2-prefork
24777 wwwrun 20 0 234520 36920 12836 R 76.08 0.451 0:06.78 httpd2-prefork
24416 mysql 20 0 1765760 204048 14568 S 16.94 2.494 0:45.98 mysqld
25418 wwwrun 20 0 233756 36240 12836 S 12.29 0.443 0:01.70 httpd2-prefork

Will check in the morning if they're still eating CPU, this might be initial indexing (I have a big pic collection).

Perhaps it'd be nice to show that indexing is happening, if that is what is going on... Now I'm just mystified as to why nothing shows.

Catch "new picture" events

We only show the gallery button and gallery link creator when the files list contains files we can preview.
Currently, if a file is uploaded in a folder which does not contain media files, our additions to the view will not magically appear. It would be nice if it did.

Do not generate previews if storage is external/slow

Current situation

We want to avoid loading images from slow storage, because it will make it seem like the app has frozen and can take minutes to generate a handful of thumbnails.

I've found 2 methods which can help but they can't be used as is.
See this ticket for a description of the problem

So I've designed a custom method, in place since 2.0.10, based on isMounted(), but which excludes federated clouds.

The problem is that the app "External storage" mounts folders locally, so it's more difficult to exclude them.

The future

Hopefully, there will be new methods included in core which will help with this.

At some point, there should be a way to configure external storage:
owncloud/core#5917, part of owncloud/core#12216

And hopefully the same thing will be available for shares.

Add REST API

General

• Versioning will happen using headers
• Authentication happens via HTTP auth

Config API

Gives information about the supported features as well as the list of supported media types

• /api/config

Files API

Gives the list of files found in the folder given as argument and lets you download a file

• /api/files/list
• /api/files/download/{fileId}

Preview API

Gives you a list of base64 encoded thumbnails when you connect to the thumbnails endpoint using EventSource and gives you a resized preview when you use the preview endpoint

• /api/preview/thumbnails
• /api/preview/{fileId}/{width}/{height}

Find a way to regenerate empty thumbnails

Maybe it's just on my test setup, but I can end up with blank thumbnails, probably because an error message was converted to a picture or something similar.

It would be nice to be able to find a way to re-generate just those.

We could do just one round trip if the preview was cached and its size is less than 500 bytes maybe.
In the future, if thumbnails feature a menu button, here could be an entry to regenerate just those thumbnails #39

App won't find mime icon if data folder is not at the standard location

I'm using a hack to find the path to the mimeicon in the Preview class, based on the data folder, forgetting that this is usually moved away for security reasons.

The "Files" slideshow should better handle broken previews

The files app is not telling plugins whether a preview is working or not, so we have to try to load it to see what happens.

If we encounter a broken preview, we should let the user know and remove it from the list of images for the currently loaded slideshow

A good test case is to enable the SVG provider. Most moderately complex SVGs won't have previews because the provider is crippled for security reasons.
The thumbnail should be blank and the slideshow will fail to get an image.

PHP 5.6 compatibility

The app may not be compatible with PHP 5.6.

In order to test it on PHP 5.6, you need to edit apps/galleryplus/appinfo/info.xml
Change

<php min-version="5.4" max-version="5.x"/>

to

<php min-version="5.4" max-version="5.7"/>

Windows compatibility

The app is untested on Windows, so I would appreciate it if users could provide feedback

Don't just send a 404 when we can't download a thumbnail

A thumbnail can be either generated by the preview system or downloaded if it's a SVG and the user has not enabled the SVG provider.
The cache is used to get a list of files which the app should be able to show, but something may happen (broken encryption, broken binary, etc.) when we're actually trying to download and show it.

We're currently sending a 404, along with a message, but that will break the app as the loading will only stop if the loader can match a sent path with a received path.

Review the JS

The JS part has not been rewritten, but there are a few changes due to the move to the AppFramework and because I've included all the PRs which were waiting to be merged because of missing rebasing or light bugs.

Summary

• Modified the endpoints to match new routes
• Light refactoring to make some methods shorter
• Added a couple of utility methods
• Added the zoom PR #110 @davidrapin
• Added the Preview Images 1-2-3-4 Pics PR #82 @libasys
• Added the Download button to public gallery #33 @DeepDiver1975
• Added a download button to the slideshow to be able to download a single image when looking at it @libasys

I realise that adding the PR at the same time was not the best move as it makes the change set larger, but the changes are available in the original PRs.

I could create a PR of just the js folder to highlight the changes with the original project. Let me know what works best for you.

Also, since this is not a rewrite, I think it would be best NOT to focus on refactoring the JS or changing methods which are also present in the original work. It can be done later on when more people might be willing to participate.

cc @icewind1991 @LukasReschke @MorrisJobke

Improve the touch area of some buttons

I think next and previous should have larger click/tap areas.
Buttons at the top (download, toggle, etc.) should also have a larger tap area and should be spaced accordingly.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Dealing with errors programme

This is a meta ticket which tracks all the various work being done to improve the reliability of the app

Loading the app

• Fail gracefully when something unpredictable happens in the backend #45
• Try to find a working folder, based on the given location #44

Getting thumbnails

• The backend should send back a 404 status if we can't access the file and a 500 status if we can't generate the thumbnail
• Remove 404 thumbnails from the view if they don't belong to an album
• Show a media type icon for 505 thumbnails, unless they belong to an album
• Only show proper thumbnails in the album representation. There is no point showing blank or media type thumbnails

Slideshow

• Do no load previews of files which have a media type icon thumbnail #33
• Download previews of files which have a media type icon thumbnail #34
• On the files side, show an error message in the slideshow if we receive a broken thumbnail. We currently can't know before receiving it #47

Feel free to add your thoughts and to raise new issues to address specific problems.

URL used to retrieve thumbnails can generate "URI too long" error messages [$15 awarded]

Current situation

Initial post: #159
A thumbnail is identified by its path. So if we're 10 levels deep and have lots of sub-folders with long-names, we're going to max out the limit set for GET requests.
Note: We have to use GET requests because we're using Server-sent Events.

Solution

• Identify thumbnails by their ID
• Only retrieve what's needed for the current view
• Use file IDs when requesting thumbnails in batch
• Use file IDs when requesting large previews and to download files

This requires re-factoring a fair bit of the current code

Next steps

Feasibility study

• Collect requirements
• Calculate effort required
• Build proof of concept

Development

• Secure funding - Sponsored by "La Fondation Hainard" and @graywind
• Finalise specifications

QA

Test will be written after another big upcoming change

The $15 bounty on this issue has been claimed at Bountysource.

Generate thumbnails on demand

Background thumbnail generation might be coming in the future. We're tracking it here: #18

In the meantime or in addition, we could offer a way to generate these thumbnails on demand in order to make the app usable from the first load.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Disable search field

The search field is not yet automatically disabled in core for apps which have not registered with the search system, see owncloud/core#11635 (comment)

We should hide that field for now since it does not work.

@jancborchardt - Feel free to voice your opinion

Hide download button on the "files" side

No point in having a download button on the slideshow, when you can already do it when looking at files.

Action menu for thumbnails

Each Album or thumbnail could feature a menu giving quick access to actions such as

• Regenerate thumbnail #38
• Edit meta data, requires #101
• Share, requires #68
• Edit name
• Delete image
• Select image (for drag and drop #405)

There is a menu in Files. I don't think we can use it as is, but we could copy it if it's not too large. It would look something like this.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Initialisation process of the app takes too long and is too memory and CPU hungry as it tries to map all media files found in the system

Gallery+ App does not scale

Similar to the original version - as in this issue, the gallery app still does not scale. There are over 100,000 images on the server, and very quickly after opening the main app page, the 512MB of memory allowed to PHP are exhausted. The same "searchByMimes" is still used to initialize the gallery as in the previous version, and as is noted in the comments in service/infoservice.php, it "can lead to performance issues", or it may fail entirely.

Slideshow does not restore URL when closing

On the files side, the URL is not restored to its initial state after the slideshow ends.

How to deal with empty parent folders?

When building the gallery view, we need to provide navigation so that sub-folders containing media files can be shown as albums.
We also have to make sure that looking for media files doesn't "freeze" the app.

So how do we address the case where pictures are only found 10 levels deeper in a large repository with many folders per level?

Some thoughts

• Drilling down each folder to see if there is something to show could lead to the issues we're currently seeing when trying to load the whole hierarchy in memory when first loading the app.
• Stopping at an arbitrary number of levels could lead to empty galleries, even though there are media files to show.
• Defining only one folder as the "Gallery folder" doesn't work for most people as it requires organising all media files, many of different types in a single folder.

Any suggestions @icewind1991 @libasys @ftree @bwoester @jancborchardt @dbeckmann @TheDD?

Cursor just spins when running gallery plus

Chrome, owncloud 8 (upgraded from owncloud 7, which was working fine).

Confirmed that the app directory is called galleryplus, set permissions to www-data:www-data.
When choosing the Gallery+ icon from apps, I get an empty page with a spinning cursor that never stops.

Error in the logs:

Feb 11 18:28:53 nowlas ownCloud[12945]: {index} Exception: {"Message":"Unable to generate a URL for the named route "galleryplus.page.index" as such route does not exist.","Code":0,"Trace":"#0 /var/www/owncloud/lib/private/route/router.php(282): Symfony\Component\Routing\Generator\UrlGenerator->generate('galleryplus.pag...', Array, false)\n#1 /var/www/owncloud/lib/private/urlgenerator.php(42): OC\Route\Router->generate('galleryplus.pag...', Array)\n#2 /var/www/owncloud/apps/galleryplus/appinfo/app.php(36): OC\URLGenerator->linkToRoute('galleryplus.pag...')\n#3 /var/www/owncloud/lib/private/app.php(379): require('/var/www/ownclo...')\n#4 /var/www/owncloud/settings/ajax/navigationdetect.php(9): OC_App::getAppNavigationEntries('galleryplus')\n#5 /var/www/owncloud/lib/private/route/route.php(135) : runtime-created function(1): require_once('/var/www/ownclo...')\n#6 [internal function]: __lambda_func(Array)\n#7 /var/www/owncloud/lib/private/route/router.php(250): call_user_func('\x00lambda_295814', Array)\n#8 /var/www/owncloud/lib/base.php(763): OC\Route\Router->match('/settings/ajax/...')\n#9 /var/www/owncloud/index.php(36): OC::handleRequest()\n#10 {main}","File":"/var/www/owncloud/3rdparty/symfony/routing/Symfony/Component/Routing/Generator/UrlGenerator.php","Line":134}

Clients: Linux (Fedora 20) with Firefox, Linux (Arch) with Chrome, Windows with Chrome
Server: Debian 7.8, lighttpd 1.4.31, php 5.4.36, OC 8.0, Gallery+ newest from git

owncloud is reachable via nowlas.org/owncloud
owncloud is installed in /var/www/owncloud

Show thumbnails as soon as they're received

Current situation

• The app sends X requests to the preview system to generate Y thumbnails at a time
• At the same time, the view asks for a row
• Elements are added to the row one at a time
• The script waits for the thumbnail to be available <- This is blocking the rendering of the row
• Thumbnail is added to the row and total width is checked against max width (browser window)
• When the row is full, it is rendered

The thumbnails needs to be analysed so that the row can be composed to fit and look nice. If we only generate thumbnails of 400x200, then the view will be plain looking.

Ideal situation

• Identical first steps
• As soon as a thumbnail is received, it is used to populate the row
• To the user, the view is filled one thumbnail or album at a time

Next steps

Feasibility study

• Collect requirements
• Calculate effort required
• Build proof of concept
• Implement

IE8 is not supported

Solution

Screencasts

Note: the refresh rate in the videos is quite low, so this is not reflective of the smootheness of the animation

With cached thumbnails
http://screencast-o-matic.com/watch/cDn6n7hR39

You can see that once the album is cached, there is no resizing taking place any more

On an empty cache
http://screencast-o-matic.com/watch/cDn6nEhR3E

Features:

• Semi-opaque row while it's being filled
• Spinners on images in albums
• Spinners on single images on row (with caveat, see below)

Caveats

• Since we don't have the real size of the images, the next image or its spinner are sometimes misaligned. It's currently impossible to fix and has to be accepted as a side-effect of being able to show some information before having the full picture
• When resizing the window on a desktop, there is a flashing effect as each time the wall is being redrawn, the opacity goes back to being semi-transparent until the images are resized. In my experience, the fix involves introducing and monitoring a state to know if we're currently in a resizing loop. I don't think it's worth for me to invest time to improve this, but a PR can certainly be introduced later if someone finds a better way
• On low powered devices, there may be a bit of stuttering when resizing very wide images. I find this acceptable, compared to the advantages.

Fixing performance issues programme

This is a meta ticket which tracks all the various work being done to improve the performance of the app

Please support and comment on individual tickets if you want to help as it's difficult to track what's important to backers otherwise.

Loading the app

• Do not map the whole cloud into memory, load one folder at a time #17 . Potential side effects are discussed here #24
• Cache albums as we go along so that we don't have to reload the list of pictures when we're in an album we've visited before #41

Getting thumbnails

• Only preload the number of thumbnails we were told to preload #60
• Switch to an ID based mapping of pictures and Thumbnails to fix #27
• Shorten the paths of pictures located in sub-albums. Requires #27
• Show thumbnails as soon as they're received (#511) instead of waiting for the whole row to be loaded #29
• Generate thumbnails on demand (#22), so that users don't have to wait too long before being able to see something. The cron/background task solution won't be implemented here, but is a core solution owncloud/core#11685

For issues in core, see this meta ticket: owncloud/core#13609
Things should be much better on oC 8.1+, once core can generate thumbnails in seconds rather than minutes for large media files.

Feel free to add your thoughts and to raise new issues to address specific problems.

There is a $60 open bounty on this issue. Add to the bounty at Bountysource.

Use multithreading when processing batches of thumbnails

Hi, compared to the old Gallery, this one does no longer split 1st preview generation into seperate threads/requests (~1/4 of speed or slower) and it does not load in IE11 (spinning wheel).

Let the user generate a Gallery link from the Files app

As described here: owncloud/core#8268 (comment)
It would be very useful to be able to generate Gallery links straight from the Files app.

It's possible to modify slightly the sharing dialogue.
One caveat is that other apps may do the same.

Use bower in the dev env to manage JS libs

Bower works by fetching and installing packages from all over, taking care of hunting, finding, downloading, and saving the stuff you’re looking for. Bower keeps track of these packages in a manifest file, bower.json. How you use packages is up to you. Bower provides hooks to facilitate using packages in your tools and workflows.

http://bower.io/

On a touch device, controls should show up when tapping the screen

Controls automatically hide after a while, but they don't reappear when touching the screen

Error PHP Call to a member function getMimetype() on a non-object at /var/www/owncloud/lib/private/files/node/node.php#276

Hi!
When i want to open gallery+ i see the following error in the log: "Error PHP Call to a member function getMimetype() on a non-object at /var/www/owncloud/lib/private/files/node/node.php#276"

I do not experience this error with all users but only with some (the users have an extensive number of images in their accounts)

BR

In-app settings buttons and user settings section [$15]

Arbitrary choices have been made for some parameters such as the preview scaling or zoom factor

A user should be able to set his own preferences

The IConfig interface should allow any developer to collect the user's preferences to configure the view

Ideas

• Enable/disable advanced graphical interface (also available via shortcut)
• Exclude (.nomedia) or include (gallery.cnf) folders
• Set maximum zoom factor
• Enable/disable upscaling
• Show/Hide broken pictures

There is a $15 open bounty on this issue. Add to the bounty at Bountysource.

Background thumbnail generation [$25]

Feature request

User type: any

User level: any

Description

@TheDD
Since the app is extremely slow when opening a folder for the first time I think some actions like thumbnail generation should be moved to a background/cron job.

(I didn't review the code and have no idea if there's already some background work happening. If there is, I'd still like to discuss performance improvements)

@astroleo
I run owncloud 8.2.2 on a Raspberry Pi which works just fine (and thank you all for this!), but isn't terribly fast. When I share a link to a gallery it takes quite some time to browse through the gallery for the first visitor. opening the gallery, clicking on an image, then clicking the overlaid "next" arrow in the screen-sized image. I understand that opening one screen-sized image triggers the creation of the next one, but (for the Raspy) this isn't fast enough and the first user has to wait each time she clicks the "next" button.

My suggestion would be to add an option to create, right after uploading the album, the various required image sizes so that they are served quickly from the cache already for the first visitor.

Benefit / value

For OC installations on low-power computers (e.g. Raspberry Pi) the first visitor would already be able to smoothly scroll through an album.

Risk / caveats

If uploading a large amount of pictures, creating the cached versions may create quite some server load. The pre-caching task should therefore be given a low priority.

Sponsorship

@astroleo
I'm afraid I cannot sponsor anything yet, but I'd be happy to help developing / testing this new feature if an expert could provide me with some background on how caching works in OC.

Are you a developer willing to implement this feature?: @astroleo: yes

Can you sponsor the development of this feature or do you know somewone who can?: no

There is a $25 open bounty on this issue. Add to the bounty at Bountysource.

Add a button to toggle the colour of the background in the slideshow

As described here by @anarcat
owncloud/core#11418 (comment)

Happens as soon as you're starting to preview more than just JPEGs.

Requirements

• Design a toggle button. I don't see which standard oC icon we can use. Suggestions welcome.
• Place the button next to the download button
• Make the controls work with a light background. A solution could be to create a light theme #51
• Implement the CSS background colour decoder and the switching logic

Open discussion

• Should the user-chosen "theme" stay for as long as the app remains running? The colour of the slideshow won't change until the button is pressed again.
• Should the theme be reset at every picture change?
• Should the theme be reset every time the slideshow is launched?

Your input (and help) is welcome @jancborchardt, @anarcat

Only load working previews in the slideshow on the Gallery view

When a slideshow is started, there is no point in showing broken images as mime icons, so let's remove them from the array of images to show

Add an admin settings section

Arbitrary choices have been made for some parameters such as the media types to support or if we should send SVGs as is.

An admin should be able to control those.

The IAppConfig interface should allow any developer to collect an admin's preferences and to use it in the app.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Fail gracefully

There is no point in having silent errors as it only confuses users.

core is still failing in unpredictable ways and it doesn't always raise exceptions. See #28
We should do our best to catch these behaviours and turn them into different HTTP status, error messages, sanitized or empty returned data so that the view can display an appropriate error messages to the user.

List of related tickets

• #14
• #28
• #47
• #69

Cache albums as we go along

In Gallery+, we're not mapping the entire cloud in memory any more, which means that every folder change will trigger a request to the server to get a new list of files.

We could improve the situation by caching what we receive and check that cache before making a new request.

Stop sending the mimeicon so that the browser can cache it

We currently send a base64 encoded mime icon as the thumbnail when we can't get a preview of a media file.
It should be more efficient to just send the path to the icon so that the browser can cache it.

Try to find a working folder, based on the given location

There could be a typo in a filename or folder, we should try our best to find a working parent and as a last resort, we'll show the root folder