Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a thumbnail/grid view to the Files app #17357

Closed
oparoz opened this issue Jul 2, 2015 · 19 comments
Closed

Add a thumbnail/grid view to the Files app #17357

oparoz opened this issue Jul 2, 2015 · 19 comments

Comments

@oparoz
Copy link
Contributor

oparoz commented Jul 2, 2015

Every files manager has more than one view. The current list view doesn't fill all use cases, some people will prefer to have a detailed view while others will want to see large visual representations of their files.

You might think that Gallery is the Files' thumbnail view, but that's wrong. Gallery will not show all possible media types and focuses on visual media. It's currently being misused as a poor man's thumbnails view for files.

So, it's high time the Files app introduces its thumbnails view.

Next steps

  • Create CSS and methods to be able to render the files list as a grid. The process could be sped up by retrieving 200x200 thumbnails, shrunk to 36x36 for the list view
  • Keep title under the thumbnail.
  • Keep all actions next to the title
  • Add info button which would reveal size, date, etc.
  • Move result of actions to the new right sidebar. It's a logical place since everything about sharing will be shown there already, as well as tagging info, virtual groups, etc.

@jancborchardt , as discussed

Input welcome: @DeepDiver1975 @PVince81 @georgehrke @LukasReschke @BernhardPosselt @schiesbn @nickvergessen @libasys @deMattin @setnes

@jancborchardt
Copy link
Member

I do agree with the basic point, however I’m still not sure if it’s a good idea to introduce a third view.

It will be a maintenance nightmare on top of what we already have, and I kinda doubt the benefit over the Gallery, since you will just see a bunch of big filetype icons on top of what the Gallery would already show.

@oparoz
Copy link
Contributor Author

oparoz commented Jul 6, 2015

I don't think the 2nd view exists. It's another app, with a different purpose.
Switching to grid view in Files would be much quicker and could offer some benefits such as:

  • Readable office/text/pdf thumbnails
  • Possible thumbnails in folders
  • Support for many more media types which don't make sense in a gallery (code, fonts, etc.)

There are lots of reusable components such as panels, thumbnails, actions. Only the UI changes.
If you take every row we have today and turn each one into a square, you're half-way there imo. The row rollover would work the same, etc.

@elpraga
Copy link

elpraga commented Nov 4, 2015

I totally agree, the current behaviour is misleading. I am reposting my original issue "When in File view, when I switch from list to grid view, folders disappear owncloud/gallery#462" here:

When I am viewing a list of folders in list view and swith to grid view, only the folders with only photos in them will stay visible, other folders disappear.

User is not consciously choosing the Gallery app, in his/her mind he is only swithing the view on existing files. Current behaviour makes it seem that foldders suddenly go missing.

Expected behaviour:
All folders should be visible as before with large thumbnails for photos and equally large icons for files without thumbnails.

@jancborchardt jancborchardt added this to the 9.1-next milestone Nov 10, 2015
@jancborchardt
Copy link
Member

Setting as to be discussed for 9.1

@oparoz
Copy link
Contributor Author

oparoz commented Mar 2, 2016

This is part of the GSOC 2016 and someone has already taken an interest. Since Files is not my speciality, I think someone other than me should be handling the project. @PVince81? @MorrisJobke? @rullzer?

@PVince81
Copy link
Contributor

PVince81 commented Mar 2, 2016

I don't think we should add a grid view to the files app in core.
However, an app could be developed to provide an additional nav entry on the left that provides a new file list with a thumbnail view.

Alternatively it would have to be a plugin system with buttons in the controls bar (or another way of switching) where apps can provide their own file list views for all existing views.

@PVince81
Copy link
Contributor

PVince81 commented Mar 2, 2016

This would require some extension points in core to make it possible for apps to register such views on the JS side.

@oparoz
Copy link
Contributor Author

oparoz commented Mar 2, 2016

OK, so just like for the sidebar, add a plugin system to that central column in Files and create core/apps/view_grid which can be invoked by any app to provide a grid view of a list of fileinfo objects.
That view could even be used in a sidebar in apps like document or image viewers.

That's more work than simply changing CSS classes at the flick of a button to present the information differently, but would be more useful in the long run.

@oparoz
Copy link
Contributor Author

oparoz commented Mar 4, 2016

Thinking about this some more, being able to completely replace the table full of rows with a different view would open a world of possibilities in terms of files+data visualisation. The photowall from gallery could be implemented directly in Files as an alternative view, you could have a virtual earth view, clever colour coded mapping based on meta data, etc.

@thenamelessthing
Copy link

I dream of something like that!

@DeepDiver1975
Copy link
Member

@PVince81 how much work is it to introduce the plugin system?

We don't want GSoC students to work in core due to the known issues.
So we need to come up with the plugin system and let the student implement the app

@PVince81
Copy link
Contributor

It depends how much of the existing code we want to be reusable.

The FileList class is still a mess from the early OC days and ideally the model needs to be separated from the view in a way that makes it possible to have one model/collection (the file list entries) and several views (tabular file list, grid file list), etc. Refactoring that would take a long time (I still hope to find time to do this some day...).
For the pluggable part, we then need an extension point where apps can register their views and have a UI element to make it possible to switch views.
And all views need to have an event system to be able to integrate with the sidebar.

Maybe we can find a compromise where we only provide the UI elements to switch views (to be designed), and app implementers will have to rewrite their own FileList logic from scratch using OC.Files.Client to fetch the entries, and also need to implement the logic to pass the file info to the sidebar.

@DeepDiver1975
Copy link
Member

So this is a critical decision point regarding the GSoC application - if we cannot come up with a plugin system before the student actually can start working the project idea should be removed from the GSoC page - https://github.com/owncloud/core/wiki/Google-Summer-of-Code#2016--current

@karlitschek @jospoortvliet

@karlitschek
Copy link
Contributor

Let's remove this from the list. Too much core interference for a great GSoC project.

@PVince81 PVince81 modified the milestones: 9.1-current, 9.2-next Jun 14, 2016
@PVince81
Copy link
Contributor

Preliminary work to split model and view from the FileList to make room for additional views: #25909 and #18211

@PVince81
Copy link
Contributor

PVince81 commented Sep 7, 2017

Alternative approach which might be easier and whatever work is done there will be needed anyway for the grid view: provide the gallery app as a files app section owncloud/gallery#727

One drawback of this is only that the gallery is its own file list instead of providing the ability to switch any file view (ex: trashbin) to thumbnail mode.

But as said above, doing the work to have it be a separate files app section already brings us closer to that goal.

@jersey99
Copy link

jersey99 commented Jul 6, 2020

friendly bump

@stale
Copy link

stale bot commented Sep 19, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status/STALE label Sep 19, 2021
@stale
Copy link

stale bot commented Sep 20, 2021

This issue has been automatically closed.

@stale stale bot closed this as completed Sep 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants