Viewer integration issues

[juliushaertl]

There are some issues with the viewer integration:

• Keyboard events should be disabled (arrow, enter should only be catched by the editor, not the viewer)
• Expose the file id to the viewer component
• Overwrite max-width for mobile view, so that the editor is shown full size on small screens
• We probably don't need navigation between documents with the arrows
• Slideshow doesn't make sense for documents

[karlitschek]

May I ask a stupid question? Why is it important to have it integrated into the viewer? I understand that we get the sidebar for free which is nice. But on the other hand we loose the header bar which can be useful to navigate around, see other people in the same document, search, setting, ...

[juliushaertl]

Why is it important to have it integrated into the viewer? I understand that we get the sidebar for free which is nice.

We also aimed to have a more standardized way for apps to show file content. Before the viewer, each app needed to handle the overlay, styling and edgecases themselves, so just integrating in the viewer makes it a lot easier to maintain and the overall experience more consistent.

But on the other hand we loose the header bar which can be useful to navigate around, see other people in the same document, search, setting, ...

I agree that the header bar is useful here. Maybe we can have some different styling in the viewer for editing files, which could also be used by collabora/other file editors. Showing the header is something that is pretty straight forward with some basic styles:

cc @skjnldsv

[skjnldsv]

I agree that the header bar is useful here. Maybe we can have some different styling in the viewer for editing files, which could also be used by collabora/other file editors. Showing the header is something that is pretty straight forward with some basic styles:

Agree, but the nextcloud header bar should not be used for apps-customisations (like richdocuments for example)
This is confusing as the header is the same across all apps, so it's not really where the user should expect to find apps-related informations I'd say.

We can add the informations we want into the viewer header, which is already where we have infos, so it is better in a UX point of view. cc @jancborchardt

But on the other hand we loose the header bar which can be useful to navigate around, see other people in the same document, search, setting, ...

Well, if you click anything in the header, you'll quit the collaborative editing anyway as it will change the page. So I'd rather have the user make sure to quite the text app and navigate away than thinking it will not lose its current editing session and go into another app/setting section :)

[skjnldsv]

• Keyboard events should be disabled (arrow, enter should only be catched by the editor, not the viewer)
• Expose the file id to the viewer component
• Overwrite max-width for mobile view, so that the editor is shown full size on small screens
• We probably don't need navigation between documents with the arrows
• Slideshow doesn't make sense for documents

So basically, aside from the fileid prop, we should just add a config to force an independant view? I'd say, if the dev do not provide a group property, then handle it as a standalone view? What do you think?
It would then not fetch the nearby similar files. Arrows will automatically be disabled and slideshow as well (already in the viewer), as well as keys binding :)

[juliushaertl]

So basically, aside from the fileid prop, we should just add a config to force an independant view? I'd say, if the dev do not provide a group property, then handle it as a standalone view? What do you think?
It would then not fetch the nearby similar files. Arrows will automatically be disabled and slideshow as well (already in the viewer), as well as keys binding :)

Yes, I had the same in mind. 👍

[skjnldsv]

Closed by nextcloud/viewer#79

[juliushaertl]

All fixed already, thanks @skjnldsv