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 #6

Closed
5 tasks
maprambo opened this issue Jun 4, 2016 · 19 comments · Fixed by #11573
Closed
5 tasks

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

maprambo opened this issue Jun 4, 2016 · 19 comments · Fixed by #11573
Assignees
Labels
1. to develop Accepted and waiting to be taken care of design Design, UI, UX, etc. enhancement feature: files high
Milestone

Comments

@maprambo
Copy link

maprambo commented Jun 4, 2016

EDIT by @jancborchardt, todo for grid view:

Breakdown of steps for grid view

Essential

  • HTML structure: Current table structure makes it difficult to change the CSS. We need to change to a div-based layout. Only changing table elements to divs, not changing any look or functionality!
  • CSS: Introduce grid view style and hook the switch bildschirmfoto 2016-06-04 um 16 05 05 on the top right to switch between the views

Non-essential

  • HTML: Simplify structure as there are probably a few elements to cut. Keep in mind what we need for Vue.js, and for standardization across apps
  • Documentation: Document the structure for the new list view and grid view. Put them into the currently empty "Main content": https://docs.nextcloud.com/server/14/developer_manual/design/content.html
  • Vue.js: Switch Files app to Vue.js part by part. (Is becoming standard for apps, more maintainable, enables us to use animations easier, etc.)

The essential parts we have to do for Nextcloud 15, and considering the short time-frame we should really focus on that before doing the non-essentials.


(Original post by @maprambo)

When pressing that button, the gallery opens. It would make much more sense to show all the files and folders as symbols, like native file browsers do:
bildschirmfoto 2016-06-04 um 16 09 26

Don't get me wrong - I love the gallery and also that button. But it leads to confusion, so a real symbol view should be opened. The gallery button could just get the gallery's app icon.

@MariusBluem
Copy link
Member

I absolutely agree with you 😉

cc @jancborchardt

@Bugsbane
Copy link
Member

Bugsbane commented Jun 5, 2016

I'm not sure if I understand exactly what @maprambo is requesting, but what I do know is that I'm constantly wishing that we had an app that displayed photos visually like the gallery app, but let us do file operations like delete, copy, raname, share etc as the file app does. Not sure if this is related...

@MariusBluem
Copy link
Member

MariusBluem commented Jun 5, 2016

@Bugsbane Not really. @maprambo is requesting a symbol view as an option beside the classical file grid. He (and some other users) are confused about the icon he mentioned above which redirects to the gallery - but looks like it would redirect to an symbol view of the files 😉 In such an view, you could also do copy, delete and all other file operations. ...and you would see the pictures better (however: this would be independent from the gallery)

@Bugsbane
Copy link
Member

Bugsbane commented Jun 5, 2016

Ok. I guess I just don't understand what a "symbol view" is, possibly because I use KDE+Linux rather than Macos (and possibly Gnome). I'm assuming this is equivalent of Dolphin's Icon view?

@jancborchardt
Copy link
Member

Yeah, we should definitely have a grid view in the Files app. More and more this actually becomes the standard over a bland list view, and Google Drive for example uses it normally.

cc @oparoz because we talked about this in the past. :)

So @MorrisJobke @schiessle @BernhardPosselt @Henni how difficult do you think is it to pull this off?

@jancborchardt jancborchardt added the design Design, UI, UX, etc. label Jun 6, 2016
@oparoz
Copy link
Member

oparoz commented Jun 6, 2016

This would make a lot of users happy.
All I had to say was listed in the thread I started.

I'll summarize:

  1. I'm sure the JS magicians can get a PoC running really quickly. Instead of rendering rows, render boxes and make the icons smaller
  2. There were some interesting discussions at the end of the thread regarding turning the view into a system which accepts plugins, in case apps want to introduce different views

@oparoz oparoz changed the title Symbol view Add a thumbnail/grid view to the Files app Jun 6, 2016
@Bugsbane
Copy link
Member

Bugsbane commented Jun 7, 2016

Possibly this should be in a separate ticket (if so, let me know and I'll create it), but personally, when I go browsing a folder full of pictures, I would rather have a view similar to that in the Gallery app, where picture previews aren't cropped arbitrarily into squares, but it's still possible to carry out file operations.

Of course, there's always the possibility of having both view modes. Personally though, I suspect that both cater to basically the same use case (let the user easily see the image files to choose which file operations to apply to which files).

@Spacefish
Copy link
Member

Would be nice if Gallery and a Media Player just got merged into the file app (HTML5 Videoplayer + Audioplayer), as it is such a common functionality that everybody wants to use it / uses it.
So the whole gallery and mediaplayer thing just becomes core functionality.

@oparoz
Copy link
Member

oparoz commented Jun 7, 2016

Possibly this should be in a separate ticket (if so, let me know and I'll create it), but personally, when I go browsing a folder full of pictures, I would rather have a view similar to that in the Gallery app, where picture previews aren't cropped arbitrarily into squares, but it's still possible to carry out file operations.

Maybe this could be solved by letting you chose the size of the thumbnails in files, like via a slider. Windows has a few different presets per example.

But one day, the file operation menu may be available in Gallery since it has a less distracting interface.

Would be nice if Gallery and a Media Player just got merged into the file app (HTML5 Videoplayer + Audioplayer), as it is such a common functionality that everybody wants to use it / uses it.
So the whole gallery and mediaplayer thing just becomes core functionality.

The viewers could be extracted to different apps, which could be added to core, yes. The problem is that you can be certain that some people will want to disable them and if you need to ship them disabled, then you may as well just keep the viewers in the original apps.

@Bugsbane
Copy link
Member

Bugsbane commented Jun 8, 2016

Maybe this could be solved by letting you chose the size of the thumbnails

To me, what I love about the Gallery view isn't so much about the size of the preview, it's that a) It shows a preview of the whole image rather than arbitrarily cropping the previews to become a square and b) it shows a large number of image previews with minimal wastage of screenspace. To me at least, the Gallery view is far more useful and beautiful than the scalable preview size view in Windows (or KDE's Dolphin for that matter)

But one day, the file operation menu may be available in Gallery since it has a less distracting interface.

Glad to hear it! I already previously opened a feature request on owncloud/gallery requesting exactly that. 😉

@jancborchardt
Copy link
Member

Just one important comment on things which have been said above:

Maybe this could be solved by letting you chose the size of the thumbnails in files, like via a slider. Windows has a few different presets per example.

and

Would be nice if Gallery and a Media Player just got merged into the file app (HTML5 Videoplayer + Audioplayer), as it is such a common functionality that everybody wants to use it / uses it.
So the whole gallery and mediaplayer thing just becomes core functionality.

Please please please keep in mind that every added thing will

  • Need to be developed in the first place
  • Introduce added complexity to the interface
  • Take resources to be maintained

And that is not to be underestimated. Video playing and image viewing already works in files so there’s not really a reason to formally merge them into core, it just increases code complexity.
Also, adding more and more configuration options for thumbnail sizing that we think are needed is a bad approach to handle this.

We should do it like any normal startup: Start small, with an MVP (minimum viable product) and stay agile that way, not developing things which end up not being used. In this case that’s a simple grid view for the files app which makes a lot of sense as I said above. Anything else is for future discussions.

@oparoz
Copy link
Member

oparoz commented Jun 8, 2016

In fact, more than likely, whatever solution was found optimal for grid view, would likely be the same ideal option for a gallery view.

In terms of design, for things like where to put the menu, its colour, etc., yes

In fact, it could even be argued that a grid view may take more coding and maintenance, as it isn't using code that's already in use to display the images.

Not if you don't go with a plugin system. It's purely a job for UI architects. Kind of what's happening with a responsive design.

Code sharing with Gallery app

That's actually more work since that piece of code in Files is not designed to be shared. It' was quite problematic to implement uploading for the same reason. The core team doesn't want to create such components and prefers it if each app comes with everything it needs.

I certainly don't think that both grid and gallery view options being available at the same time helps anyone at the end of the day.

It's a good thing that Gallery is an app which can be disabled then ;)
From my pov, Gallery is just an app, with its own goals, views, features. It shouldn't be a crutch for Files.
A files manager needs a thumbnails view. If the team wants to design it so that it shows images like in Gallery, then it's only slightly more difficult than building a grid, but I think it might confuse users.
Also, switching view in Files is much faster than loading Gallery.

@MorrisJobke
Copy link
Member

@jancborchardt any reason you added the "needs info" label? What is missing here?

zenlord added a commit to zenlord/server that referenced this issue Sep 5, 2022
# This is the 1st commit message:

Patch from PR 24574 to view.js

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>

# This is the commit message nextcloud#2:

Patch from PR 24574 to lib/Connection.php

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>

# This is the commit message nextcloud#3:

Patch from PR 24574 to lib/Wizard.php

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>

# This is the commit message nextcloud#4:

Patch from PR 24574 to lib/LDAP.php (manually)

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>

# This is the commit message nextcloud#5:

Added a function usesLdapi() in Configuration.php and referenced that function throughout the PR

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>

# This is the commit message nextcloud#6:

Removed the questions I added in comments - https://github.com/nextcloud/server/pull/24574/files#r825732903

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>

# This is the commit message nextcloud#7:

Changed the test as requested - https://github.com/nextcloud/server/pull/24574/files#r825726282

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>

# This is the commit message nextcloud#8:

Changing return type from bool to int

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>

# This is the commit message nextcloud#9:

Changing return type of usesLdapi() to bool and adapting references

Signed-off-by: Vincent Van Houtte <vvh@aplusv.be>
alpapan added a commit to alpapan/nextcloud-server that referenced this issue Feb 7, 2024
fixes this error caused when system has usernames that are purely numeric.

An unhandled exception has been thrown:
Error: Object of class OCA\User_LDAP\User\User could not be converted to string in /var/www/nextcloud/apps/user_ldap/lib/User_LDAP.php:312
Stack trace:
#0 [internal function]: OCA\User_LDAP\User_LDAP->userExistsOnLDAP()
nextcloud#1 /var/www/nextcloud/apps/user_ldap/lib/User_Proxy.php(126): call_user_func_array()
nextcloud#2 /var/www/nextcloud/apps/user_ldap/lib/Proxy.php(140): OCA\User_LDAP\User_Proxy->walkBackends()
nextcloud#3 /var/www/nextcloud/apps/user_ldap/lib/User_Proxy.php(262): OCA\User_LDAP\Proxy->handleRequest()
nextcloud#4 /var/www/nextcloud/apps/user_ldap/lib/User_Proxy.php(239): OCA\User_LDAP\User_Proxy->userExistsOnLDAP()
nextcloud#5 /var/www/nextcloud/lib/private/User/Manager.php(168): OCA\User_LDAP\User_Proxy->userExists()
nextcloud#6 /var/www/nextcloud/apps/files_fulltextsearch/lib/Service/FilesService.php(399): OC\User\Manager->get()
nextcloud#7 /var/www/nextcloud/apps/files_fulltextsearch/lib/Service/FilesService.php(226): OCA\Files_FullTextSearch\Service\FilesService->initFileSystems()
nextcloud#8 /var/www/nextcloud/apps/files_fulltextsearch/lib/Provider/FilesProvider.php(246): OCA\Files_FullTextSearch\Service\FilesService->getChunksFromUser()
nextcloud#9 /var/www/nextcloud/apps/fulltextsearch/lib/Service/IndexService.php(174): OCA\Files_FullTextSearch\Provider\FilesProvider->generateChunks()
nextcloud#10 /var/www/nextcloud/apps/fulltextsearch/lib/Command/Index.php(403): OCA\FullTextSearch\Service\IndexService->indexProviderContentFromUser()
nextcloud#11 /var/www/nextcloud/apps/fulltextsearch/lib/Command/Index.php(280): OCA\FullTextSearch\Command\Index->indexProvider()
nextcloud#12 /var/www/nextcloud/3rdparty/symfony/console/Command/Command.php(298): OCA\FullTextSearch\Command\Index->execute()
nextcloud#13 /var/www/nextcloud/core/Command/Base.php(177): Symfony\Component\Console\Command\Command->run()
nextcloud#14 /var/www/nextcloud/3rdparty/symfony/console/Application.php(1040): OC\Core\Command\Base->run()
nextcloud#15 /var/www/nextcloud/3rdparty/symfony/console/Application.php(301): Symfony\Component\Console\Application->doRunCommand()
nextcloud#16 /var/www/nextcloud/3rdparty/symfony/console/Application.php(171): Symfony\Component\Console\Application->doRun()
nextcloud#17 /var/www/nextcloud/lib/private/Console/Application.php(206): Symfony\Component\Console\Application->run()
nextcloud#18 /var/www/nextcloud/console.php(100): OC\Console\Application->run()
nextcloud#19 /var/www/nextcloud/occ(11): require_once('...')
nextcloud#20 {main}roopico /var/www/nextcloud/apps/user_ldap/lib/User/OfflineUser.phparch:index


Signed-off-by: Alexie Papanicolaou <alpapan@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of design Design, UI, UX, etc. enhancement feature: files high
Projects
None yet
Development

Successfully merging a pull request may close this issue.