The slideshow is a direct child of the body that is shown in front of
the other elements (header, content and footer) and fills the whole
viewport by using absolute positioning. However, as the other elements
were still shown behind it they affected the size of the body, and as
the body is the scrolling container its scroll bars were shown even if
the slideshow was shown.
Now the content and the footer are hidden when the slideshow is shown
(there is no need to hide the header due to its fixed position, which
does not affect the body size), so the body gets the size of the
slideshow and thus no scroll bars are shown.
Note, however, that when those elements are shown again the body scroll
bars will be reset to their initial position, so it is necessary to
explicitly restore them to their previous value. This is not needed for
the scroll bars of other elements, like the navigation bar or the
sidebar, as in that case the whole scrolling container was hidden and
shown; in the case of the body the scrolling container is kept and what
is hidden and shown are their contents, which alters its size and thus
its scroll bars.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that the proper replacemente for "#content-wrapper" in this case is
"#app-content" instead of "#content" due to "#app-content" having a
background colour set in the server, so if it was set to "#content" the
custom background would not be visible.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In the layout provided by the server the scrolling container is now the
body instead of the content wrapper.
Note that the container used in "galleryfileaction.js" was not modified
on purpose, as that feature is currently broken; it restores the scroll
position when the slideshow is hidden due to the file list being
reloaded, but that does not happen in Files app, only in public pages.
Thus, in Files app it restores the position as soon as the file list is
reloaded after closing the slideshow, so it changes the scroll position,
for example, when the directory changes. However, as "#app-content" is
used as the scrolling container in that case the scroll position of the
body does not actually change.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The standard layout in the server uses "#app-navigation",
"#app-content" and "#app-sidebar" as children of "#content"; the
navigation and sidebar are not needed, so "#app" is simply renamed to
"#app-content".
Also note that "#controls" is already the first child of "#app-content",
so there is no need to prepend it. In a similar way there are standard
CSS rules defined in the server for "#controls" as a child of
"#app-content", so no special rules need to be defined here.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, whenever a pending operation (getting the suggestions,
confirming a share or selecting a recipient) finished the working icon
was hidden and the confirm button was shown again, even if there were
other pending operations (the most common case is typing slowly on the
input field, as several operations to get the suggestions could pile if
the server response is not received fast enough). Now, the working icon
is not hidden until the last pending operation finishes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The suggestions depend on the results returned by the server, but also
on the sharees already shared with. Due to that adding a share changes
the suggestions, so now the cached suggestions are discarded when a
share is added.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a share is confirmed the suggestions are got to check if there is
an exact match. Usually the suggestions were already got with the same
parameters in order to fill the autocomplete dropdown, so to avoid a
superfluous request now the last suggestions are reused when got again,
although only if the same parameters as the last time are used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Besides confirming a share by clicking on the confirm button now it is
possible to do it by pressing enter on the input field.
Clicking on the confirm button implicitly hides the autocomplete
dropdown. On the other hand, pressing enter on the input field does not,
so the autocompletion must be disabled and closed when the confirmation
begins and then enabled again once it finishes. Otherwise the
autocomplete dropdown would be visible and it would be possible to
interact with it while the share is being confirmed.
The order in which the input field and the autompletion are disabled is
important. Internally, the autocompletion sets a timeout when the input
field is modified that requests the suggestions to the server and then
shows them in the dropdown. That timeout is not cancelled when the
autocompletion is disabled, but when the input field loses its focus and
the autocompletion is not disabled. Therefore, the input field has to be
disabled (which causes it to lose the focus*) before the autocompletion
is disabled. Otherwise it could happen that while a share is being
confirmed the timeout ends, so an autocompletion request is sent and
then, once the share is successfully confirmed and thus the
autocompletion is enabled again, the request is received and processed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Clicking on the confirm button now adds a share, but only if there is
just a single exact match. If there are no exact matches or there is
more than one exact match no share is added, and the autocomplete
dropdown is shown again with all the suggestions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This unifies the behaviour with the one used in the file list, and it
will also simplify other changes in following commits (like not needing
to show error messages when confirming a share and instead rely on those
from the autocompletion).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"_getSuggestions" returned all the suggestions from the server, which
are composed by exact matches and partial matches. Now the exact matches
are also returned on their own parameter. This will be used by the
button to confirm a share.
Note that until now the order of the suggestions was "exact users,
partial users, exact groups, partial groups, exact..."; this commit also
changes that order to become "exact users, exact groups, exact...,
partial users, partial groups, partial...". This is not a problem, as
the suggestions were used in the autocomplete dropdown, and this new
order is arguably better than the old one, as all exact matches appear
now at the beginning.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of silently failing now an error is shown to the user when the
ajax call to get the suggestions succeeds yet it returns failure content
(for example, if an "OCSBadRequestException" was thrown in the server).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"OC.Notification.hide" expects the notification to be hidden to be
passed as an argument. As it was being used to show a temporary
notification the combination of "OC.Notification.show" and
"OC.Notification.hide" was replaced by a single call to
"OC.Notification.showTemporary".
The timeout could have been specified in the options of the call, but it
was left to the default value (7 seconds) for consistency with other
notifications.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The confirmation button right now is just an icon; its behaviour will be
added in the following commits.
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
If the tooltip is not explicitly hidden it would still be shown once the
autocompletion dropdown is shown (behind it while it is open, but fully
visible when it is closed).
This unifies its behaviour with the one used in the server, but it does
not address its problems (for example, if a search is started and while
it is being performed the input field is cleared the tooltip would be
still shown once the search response is received, even if the input
field is now empty).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
After calling "Gallery.Share.share" the UI was restored (the working
icon was hidden, the input field enabled...). However, "share" is
asynchronous, so the UI was restored while the share was still being
added. Now the UI is restored in the share callbacks, so it is restored
once the sharing finished, either successfully or with a failure; in
this later case now a notification is also shown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "No results found" tooltip is now removed when the input field is
cleared.
This unifies its behaviour with the one used in the server, but it does
not address its problems (for example, if a search is started and while
it is being performed the input field is cleared the tooltip would be
still shown once the search response is received, even if the input
field is now empty).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There is no "view" nor "configModel" in a Share of the gallery;
configuration parameters are got using "oc_appconfig".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "#content-wrapper" element is the scrolling container of the
gallery. As the "#controls" element was a sibling with a relative top
position it overlapped the "#content-wrapper"; the contents themselves
were not overlapped due to the "margin-top" CSS rule for "#content
.hascontrols" elements, but as the scroll bar belongs to the
"#content-wrapper" it was.
This could have been fixed by setting the top position of the
"#content-wrapper" element to visually move it below the "#controls".
However, conceptually the controls are part of the contents, and other
apps may expect that the gallery adds all its contents in the
"#content-wrapper" (like the JSXC app), so also for consistency with the
Files app this commit moves the "#controls" element into the "#app"
element instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In the "Files" app the actions that require the create permission (those
marked as "creatable") are hidden in folders that do not have that
permission. However, as there is only one ".actions" element inside
"#controls" and that ".actions" element also has the "creatable" CSS
class appending the gallery button to it meant that the gallery button
was hidden in folders without create permissions. Now the gallery button
is appended to the "#controls" element instead, and thus it is no longer
affected by the permissions of the folder.
As the button is now appended to the "#controls" element its top margin
was increased to align it with the rest of the buttons (as the
".actions" element uses a padding of 5px), and as the button appears in
the top right corner of the contents its right margin was set to the
same value as the top margin to "frame" the button.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The share drop down was appended to the grandparent element of the
clicked element that caused the drop down to be shown. This, in itself,
was not problematic; however, due to the CSS rules for the actions bar
when the drop down was a child of the action bar (that is, when shown in
the gallery) it was not properly shown. Now the drop down is appended to
either the "#slideshow" element (when in the slideshow, just like
before) or to the "#controls" element (when in the gallery, the parent
of the actions bar).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When in slideshow mode certain keys trigger actions like toggling full
screen or zooming. However, due to event bubbling, those actions were
triggered too when typing in the input fields of the share dropdown.
Instead of stopping the propagation in each input field this is now
fixed by not triggering the actions if the element that received the key
press was an input field.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
John Molakvoæ (skjnldsv)