# Upcoming changes with Gallery **URL:** \ **Category:** 💻 Development\ **Created:** [June 10, 2016, 7:09pm UTC](https://help.nextcloud.com/t/upcoming-changes-with-gallery/514 "2016-06-10T19:09:17Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![oparoz](https://help.nextcloud.com/user_avatar/help.nextcloud.com/oparoz/32/135_2.png) [@oparoz](https://help.nextcloud.com/u/oparoz)\ **Post date:** [June 10, 2016, 7:09pm UTC](https://help.nextcloud.com/t/upcoming-changes-with-gallery/514/1 "2016-06-10T19:09:17Z")
As I suspected a year ago, trying to maintain an app on top of an unstable core base is far worse than working off a stable branch and upgrading the app once it has stabilised. I’ve wasted too much time debugging core when I could have worked on new features and I never run the latest version of the server because it’s never stable. So there is really zero benefit to me. So, I’m thinking about focusing on the stable branch of Gallery+ since the policy of the main projects is for official apps to commit to the development branch. ### The benefits - Easier to review PRs for end-users - Faster merges - New features delivered quicker, depending on my availabilities and not on how broken master is ### The drawbacks - Gallery might be broken when a new major version launches. It will really depend on how stable and backward compatible the core components will be or if someone else maintains that project - It might take longer for some features which require changes in core to be delivered ### The process - PRs are done against the stable tree (Gallery+) - Most fixes from the stable branch upstream (security, design, etc.) are merged or taken into account - Test regularly on master and notify the core project if something unexpected is detected - Try to upgrade in the time between the server code freeze and release - Re-evaluate the situation from time to time That’s of course, if I stay the maintainer of all those Gallery projects. If someone or a team wants to take over the official versions, they will be free to do whatever they want. I value your feedback 🙂 ---
**Author:** ![hustenfrei](https://help.nextcloud.com/letter_avatar/hustenfrei/32/5_5575768a8748004e209b776fc1b2916d.png) [@hustenfrei](https://help.nextcloud.com/u/hustenfrei)\ **Post date:** [June 12, 2016, 12:54am UTC](https://help.nextcloud.com/t/upcoming-changes-with-gallery/514/2 "2016-06-12T00:54:37Z")
Will this be further developed? > > > Sunday Funday! > > Here are some command some of you may find useful to manage your… thumbnails: > \## Create thumbnails > > Solution for https://github.com/owncloud/core/issues/17536 > \### Documentation > > \[Create thumbnails\](https://github.com/owncloud/gallery/wiki/Create-Thumbnails) > \### Specs > \- Collect user(s) or path info from the list of command arguments > \- Die if encryption is enabled > \- Compute path to analyse > \- Only work with folders starting with \`/\/files\` > \- Scan the given path using Cache\\Scanner in order to work with reliable data > \- Update the DB cache > \- Generate previews \*\*only for media types supported by the Gallery and for which we have a preview provider\*\* > \- Collect stats > \#### Stats > \- # of folders > \- # of files > \- # of images > \- # of previews generated > \- # of failed previews (listed) > \- Time to complete request > \- Last scanned file > \- Size of processed data > \### TODO > \- \[x\] Quit if encryption is enabled > \- \[x\] Only scan a mounted volume if previews are enabled for that storage location > \- \[x\] Restrict scan to \`/\/files\` > \- \[x\] Add some stats > \- \[x\] Add a switch to force the regeneration of thumbnails > \- \[x\] ~~Offer a safer scanning option, with transactional locking. I'm hoping this will solve the error 1205 problems and not create more problems when trying to generate thumbnails~~ > \- \[x\] Presents stats even if operation was cancelled > \- \[\] Add tests > \- \[\] Make operation cancelling optional > \- \[\] Use \[OCP\\Files\\Cache\\IPropagator\](https://github.com/owncloud/core/blob/master/lib/public/files/cache/ipropagator.php) on 9 > \- \[\] Check if this is fixed https://github.com/owncloud/core/issues/17196 > \### Possible extensions > > For future PRs > \- Make coffee > \- Support mimetype as a filter > \## Delete thumbnails > \### Documentation > > \[Delete thumbnails\](https://github.com/owncloud/gallery/wiki/Delete-Thumbnails) > \### Specs > \- Collect user(s) or path info from the list of command arguments > \- We do not care about encryption > \- Wipe the thumbnails folders if we're asked to remove thumbnails for one, a few or all users > \- Compute path to analyse in all other cases > \- Search for files \*\*of media type supported by Gallery and for which we have a preview provider\*\* and delete as we go > \- Collect stats > \#### Stats > \- # of images > \- # of thumbnails deleted > \- # of failed deletion (listed) > \- Time to complete request > \- Saved space > \### Possible extensions > > For future PRs > \- There could be an option to delete thumbnails for all files. This would only be useful if the providers were changed in between the time the thumbnails were generated and the time at which the command is run > \### TODO > \- \[x\] Find an easy way to update the cache without re-scanning > \- \[x\] Fix bug in core which prevents the use of a shared folder as the path (sub-folders work) https://github.com/owncloud/core/issues/19544 (8.1+) > \- \[x\] Ask confirmation before launching the operation as we're deleting files from the system > \- \[\] Add tests > \## Notes > > Of course, it would be much more useful to be able to run that from a cron, from the user's settings panel, etc. so don't hesitate to improve this solution ;) > > @mmattel @setnes @EricReiche @jospoortvliet @DeepDiver1975 @icewind1991 @Xenopathic @demattin @thedd @patman15 @africanforest @MorrisJobke @PVince81 @libasys @mbazdell @blackm > **[ownCloud Central](https://central.owncloud.org)** > > ownCloud Central: Discuss - Learn - Ask ---
**Author:** ![oparoz](https://help.nextcloud.com/user_avatar/help.nextcloud.com/oparoz/32/135_2.png) [@oparoz](https://help.nextcloud.com/u/oparoz)\ **Post date:** [June 12, 2016, 12:59am UTC](https://help.nextcloud.com/t/upcoming-changes-with-gallery/514/3 "2016-06-12T00:59:03Z")
> [@hustenfrei](#): > > Will this be further developed? Probably, yes, especially if I have customers with large media collections. The fact that ownCloud 9.1 will be able to execute tasks in the background should also help a lot. ---
**Author:** ![jan](https://help.nextcloud.com/user_avatar/help.nextcloud.com/jan/32/75_2.png) [@jan](https://help.nextcloud.com/u/jan)\ **Post date:** [June 13, 2016, 9:09am UTC](https://help.nextcloud.com/t/upcoming-changes-with-gallery/514/4 "2016-06-13T09:09:58Z")
So this mainly results in slower development of the normal Gallery app? Maybe it makes sense to split the pure picture viewer from Gallery again then, because then that can be used independent of Gallery, and also with a potential future grid view? What do you think @oparoz? ---
**Author:** ![oparoz](https://help.nextcloud.com/user_avatar/help.nextcloud.com/oparoz/32/135_2.png) [@oparoz](https://help.nextcloud.com/u/oparoz)\ **Post date:** [June 13, 2016, 11:20am UTC](https://help.nextcloud.com/t/upcoming-changes-with-gallery/514/5 "2016-06-13T11:20:37Z")
> [@jan](#): > > Maybe it makes sense to split the pure picture viewer from Gallery again then, because then that can be used independent of Gallery, and also with a potential future grid view? Absolutely, given your current resources, you should extract the slideshow JS to a separate slideshow app. This could even become a component which can be used by any app (mail ;)) to offer a full size view of a picture. The grid view would then fill the gap in terms of image management and be fully maintained by the core team. Gallery+ would offer a different experience and different features and will be free to have different requirements. ---
**Author:** ![oparoz](https://help.nextcloud.com/user_avatar/help.nextcloud.com/oparoz/32/135_2.png) [@oparoz](https://help.nextcloud.com/u/oparoz)\ **Post date:** [June 13, 2016, 1:32pm UTC](https://help.nextcloud.com/t/upcoming-changes-with-gallery/514/6 "2016-06-13T13:32:01Z")
> [@jan](#): > > So this mainly results in slower development of the normal Gallery app? I think the speed is not really the issue since Gallery has 3 releases a year. The goal is to try and port Gallery+ features once for every release and as long as things are easily portable most will be ported with every server release. That’s on top of the ones created directly in Gallery. The problem is that if too much has changed in the server, the old Gallery might not work any more. This sort of breakage will probably be easily detectable during the beta and rc phase of each NC release since the PHP side has good coverage, but if no resources are allocated to regularly check and fix Gallery, then NC might ship a broken app, like ownCloud did in the past, or an app without any additional features until the next release.