-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Comments
I absolutely agree with you 😉 |
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... |
@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) |
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? |
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? |
This would make a lot of users happy. I'll summarize:
|
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). |
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. |
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.
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. |
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)
Glad to hear it! I already previously opened a feature request on owncloud/gallery requesting exactly that. 😉 |
Just one important comment on things which have been said above:
and
Please please please keep in mind that every added thing will
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. 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. |
In terms of design, for things like where to put the menu, its colour, etc., yes
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.
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.
It's a good thing that Gallery is an app which can be disabled then ;) |
@jancborchardt any reason you added the "needs info" label? What is missing here? |
# 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>
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>
EDIT by @jancborchardt, todo for grid view:
Breakdown of steps for grid view
Essential
Non-essential
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:
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.
The text was updated successfully, but these errors were encountered: