When a view is rendered it should not be concerned with where it is
going to be placed in the document; in general this should be a
responsibility of the object using the view.
Moreover, when the details view is rendered it should simply prepare a
skeleton that includes the root elements provided by the plugins; those
elements will be updated by the plugins as needed when a file or a tab
is selected.
Finally, the details view should not be explicitly rendered. The
rendering removes the previous elements, but that is needed only when
the details view is in a dirty state, that is, when new plugins were
added since the last time that it was rendered. However, that dirty
state is internally handled, and the view is automatically rendered
again if needed when a file info is set.
Due to all that the details view is no longer explicitly rendered when
updating it with a different file. Also, as each file list has its own
details view, and each details view has its own element, but there can
be only one details view/sidebar element in the document, when the file
list updates the details view it also replaces the current one in the
document with its own details view if needed (that is, if it is not the
current one already).
Besides that, when the element of a details view is replaced with the
element of a different details view the old one should be detached from
the document, but never removed. Otherwise the event handlers would not
work when that element is attached again later (when changing to a
different section in the Files app and then going back to the previous
one).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Navigating to the root folder is already handled by
OCA.Files.Navigation.setActiveItem in case the view doesn't change.
Signed-off-by: Julius Härtl <jus@bitgrid.net>
fixes#10934
Else it triggers the rendering two times. Resulting is weird state in
for example the comments. Because the comments for OLD_FILEID are
retrieved but then the model is changed to NEW_FILEID. But the old
comments still get in and get parsed.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The custom handler for "URL changed" events were added to reload the
file list whenever the sections for favorites and shares were opened;
this was used to fix the problem of not reloading the file lists when
opening them for a second time. However, besides that the handlers were
not really necessary, and as the root of the bug was fixed in the
previous commit those handlers are now removed.
The file list for tags uses the handler for a different purpose, though,
so that one was kept.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a section is open in the Files app a "show" event is triggered.
File list objects handle that event by reloading themselves, but only
if the file list was shown at least once. However, the file list objects
of plugins are created when the "show" event is triggered for the first
time for their section; as the file list objects register their handler
for the "show" event when they are created they never handle the first
triggered "show" event, as the handler is set while that event is being
already handled. Therefore, from the point of view of the handler, the
second time that a "show" event was triggered it was seen as if the file
list was shown for the first time, and thus it was not reloaded. Now the
"shown" property is explicitly set for those file lists that are created
while handling a "show" event, which causes them to be reloaded as
expected when opening their section again.
Note that it is not possible to just reload the file list whenever it is
shown; the file list is reloaded also when the directory changes, and
this can happen when the web page is initially loaded and the URL is
parsed. In that case, if file lists were reloaded when shown for the
first time then it could be reloaded twice, one with the default
parameters due to the "show" event and another one with the proper
parameters once the URL was parsed, and the files that appeard in the
list would depend on which response from the server was received the
last.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Large files are not uploaded in a single operation, but uploaded in
several chunks; once all the chunks are uploaded then the server needs
to assemble them to get the final file.
Before, once the chunks were uploaded the progress bar was hidden.
However, this was confusing for the users, as the file could still need
some time to appear in the file list due to the assembling. Now once all
the chunks are uploaded the text in the progress bar changes to inform
the user that there are still some pending operations, and only when the
file is finally assembled the progress bar is hidden.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, the file or folder was opened when clicking on the name span,
but not when clicking on the link that contains the name; clicking on
the link highlighted the file and opened the sidebar, just like clicking
on the file size or date. Now clicking on the link opens the file or
folder, so the unit tests that tested clicks on the link were changed to
test clicking on the file size instead.
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
Fix sidebar and scrollbar on content
Sidebar fixes, and sidebar-width + header-height variables
Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Added icon-change on drag
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Navbar-closing in app when favorites-list is toggled on mobile
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Refactored Code
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed to alphabetical sorting
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed deletion of folder with identical names
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed ability to add files to the quickaccess
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed wrong path-generation when added from favorites-star
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed Element from navbar when favorite-star in detailview is toggled off
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed Quota-Text to prevent boundarybreaks
Reverted last commit
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Bad url-generation in javascript for new quickaccessitems
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed vertical scrolling in sortable-list which leads to "hidden" navbar
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed unnessessary console logs
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Bounds in custom sorting
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Reformatted code
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed horizontalscroll on sortable-list
Fixed "stuck element" where you could not switch back to the original ordering in the sortable-list
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Added FavoritesQuickaccess-Sidebar
Added Files-FavoritesQuickaccess-Toggle
Fixed CSS for SpacerElement
Removed Unnessessary Alerts and added Translations
Tried fixing initial Quick-Access Checkboxstate
Signed-off-by: fnuesse <fnuesse@techfak.uni-bielefeld.de>
Tried fixing initial Quick-Access Checkboxstate
Changed double-Quotes to single-Quotes
Revert webdavurl which was changed by mistake
Revert quota-icon which was changed by mistake
Changed the Folderhandling from custom-designed to nextcloud-NavigationManager-handling
Signed-off-by: fnuesse <fnuesse@techfak.uni-bielefeld.de>
Moved CSS-Spacerclass to apps.scss for global usage
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Renamed settings-caption in apps.scss to app-navigation-caption
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed old input-tag for showQuickAccess-state
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed old spacer element in files.scss
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed style of favorites-sublist and disabled the ability to disable files-quickaccess
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
