[nemo-preview] allow to browse further through files while preview is open

[paskalito]

I think it would be very awesome if not even mandatory for the preview feature to be successful if you can use it to browse through files.

eg. you have a folder of pictures you wonder what a picture looks like you hit space - now you now and you wonder what the picture before and the picture tight after looks like you simply click move to them via arrow keys or with mousclick and the preview window should stay open just load new content.

currently you have to space> look > space > arrow down > space > look > arrow down > ..... i would like to space > loook > arrow down > look > arrow down >look

[jpzbkk]

I have been googling in my off time for days and find it super surprising that this is the only post I have found in regard to this. Personally for me, I use preview to quickly glance at files when I am in list mode, I absolutely need to keep sampling files with the arrow keys, otherwise its an entirely pointless feature to have. There are a few other areas of nemo where focus is lost, but I will make a separate post about those.

[RedBearAK]

I can't believe this issue hasn't been resolved now more than 5 years after it was submitted.

Apple's Quick Look feature in Finder allows you to scroll around through all the files in a folder while the preview window is open. It's incredibly handy.

It's very archaic and far less useful to be forced to close the preview window, move to a different file, and then hit Space again just to see a preview of a different file. The Nautilus plugin GNOME Sushi has major stability issues on previewing certain large files, but if I'm in a folder full of just normal documents or images I can scroll around all I want with the Sushi preview window open.

The fact that Nemo-preview still can't do this in 2021 is... surprising.

[leigh123linux]

@RedBearAK Find the sushi commit that adds this feature and I will consider porting it.

https://github.com/GNOME/sushi

[RedBearAK]

@leigh123linux

Not everyone on this planet is a Linux software developer. I couldn't even begin to imagine what part of the Sushi code base would have anything whatsoever to do with that ability. Or whether it would have any relevance to how it would work in Nemo.

I can ask in the Sushi GitLab forum and see if anyone is gracious enough to point out the relevant code.

[leigh123linux]

nemo-preview is a sushi fork.

[RedBearAK]

@leigh123linux

From a user on the GNOME Discourse forum:

For this behavior, a new version of the previewer DBus API was implemented. If you search for “previewer” in the commit log, the changes are there https://gitlab.gnome.org/GNOME/nautilus/-/commits/master?utf8=✓&search=previewer https://gitlab.gnome.org/GNOME/sushi/-/commits/master?utf8=✓&search=previewer

Also, searching for the issue, I found this: https://gitlab.gnome.org/GNOME/sushi/-/issues/5 And it links to the merge requests where the feature was implemented

The Sushi issue is titled: "Allow left/right arrow keys to change a file to preview". Seems very relevant. There are two related merge requests.

[u2n]

Since Nemo has become the preeminent file browser, this is an essential upgrade. The now single-pane (ancestral) nautilus with gnome-sushi currently sets the preview standard, which is unfitting. All of the best features should rightly be vested in the top program, which nemo is.

[rbreaves]

Could have sworn the arrow keys were working for me on preview just the other day lol.. maybe not. May just implement a bit of hack in my kinto app. Surprised to see you here @RedBearAK & that you've not submitted a fix to me already lol.

Also fossfreedom sorta has nemo-preview added to Ubuntu Budgie 21.04 now. https://discourse.ubuntubudgie.org/t/add-nemo-preview-extension/4844/3

[RedBearAK]

@rbreaves

Fancy meeting you here, fellow macOS refugee. [ waves ]

With my limited imagination it didn't occur to me that Kinto could somehow mitigate this problem until it gets fixed in source. In fact I still can't quite imagine how that would work, other than mapping something like Alt+Arrow to a macro of Space/Arrow/Space to close, move the file selection and then reopen the preview window so that it will preview the newly selected file. But I feel like that would probably be slow enough to be not really worth the trouble.

Did you have something simpler in mind?

Also fossfreedom sorta has nemo-preview added to Ubuntu Budgie 21.04 now.

Nice. A good addition to your chosen DE.

[rbreaves]

However fast xdotool would be, but I also mentioned it in the discourse thread we're in lol. There'd be some delay, but I don't think it'd be that significant. I am doing something similar already on the dev branch of Kinto.. although it has gone unmerged now for like a month. I have been merging other branches instead - simply because I wanted to test it more.

I seem to have a number of irons in my fire atm, but I will get back to it and merge dev and maybe implement a work around for this, but I assume that will be several days from now.

[RedBearAK]

@rbreaves

Sounds very interesting. I'd like to help test that whenever you think it's ready for general use.

[Adesin-fr]

Hi, Just adding that I went a few days ago from Gnome, and sushi was working , with arrow keys ? Don't know if my comment adds a lot, but here it is ;)

[u2n]

Thanks @LemarinelNet for reinvigorating this feature request.

Just checked v5.0.3 to find it already works for at least one file type -- sometimes (not images yet), and shift-space causes a separate preview window to launch. (Ctrl-space still shifts focus from the selected file back to the pane.)

This really highlights the opportunity for consensus on how this whole preview thing should operate. There are options.

For a taste of preview without focus shift, try it on audio files. Behavior is inconsistent so if focus still shifts to the popup, try it with files in another tab or pane. Pretty sweet, eh? And the play point can be adjusted by hovering and scrolling, unlike with the preview of image files in which scrolling does nothing.

PDF previews seemed to always steal focus, except just tried some and they didn't. WTH?

So maybe a bug is causing this inconsistency. The fix might be easier than previously thought.

[somody]

Any hopes of progress on this?

[u2n]

New post brought me back (TY @somody); can't believe it's been a year.

Just re-tried preview with v5.2.4 on LM 20.3 and find even the audio preview no longer works (without focus shift).

Workaround for now is to install gnome-sushi and run nautilus. Works perfectly for images.

[chumariesco]

https://gist.github.com/OKsign/720472d30ff5fcab1dd6ba86c27836a3 https://www.youtube.com/watch?v=qjn22XEgeTY

That code and video explain how to do this with Autokeys, real easy and works fine. Reducing times in the scripts makes it more responsive, probably a good idea also not having the whole code for each arrow but shortened like below. It's not Sushi but it works quite responsive. Also Nautilus is not Nemo: no actions, no working media-columns, can't afford that. I'm not a Mint user btw. Hope this gets solved for good!

Simplified script for Autokeys (dependency: xdotool). This is only for down arrow, other arrows must be added in separate scripts:

#Enter script code# app: Xdotool
# user input
direction = 'down' # 'up' or 'down' or 'left' or 'right'
# end of user input
time.sleep(0.2)
system.exec_command("xdotool key space")
time.sleep(0.2)
activeApp = window.get_active_class()
if activeApp == 'nemo.Nemo' or activeApp == 'nemo-desktop.Nemo-desktop':
    if direction == 'down':
        system.exec_command("xdotool key Down")
        time.sleep(0.2)
        system.exec_command("xdotool key space")
        quit()
else:
    time.sleep(0.5)
    activeApp = window.get_active_class()
    if activeApp == 'nemo.Nemo' or activeApp == 'nemo-desktop.Nemo-desktop':
        if direction == 'down':
            system.exec_command("xdotool key Down")
            time.sleep(0.2)
            system.exec_command("xdotool key space")
            quit()