Add Nemo-preview extension?

I just tested this and it appears to work just fine, it’d be awesome to get this added as a default though. Not really how you guys would want to compile or bring in the xapps dependencies - but that’s all that is really lacking it seems.

Install repo for dependencies
sudo add-apt-repository ppa:savoury1/xapps
sudo apt update
sudo apt install gir1.2-gtksource-4 xreader
Download the latest tar.gz
https://github.com/linuxmint/nemo-extensions/releases/download/master.mint20/packages.tar.gz
sudo apt install ‘~/Downloads/nemo-preview_4.8.0_amd64.deb’

Definitely worth a relook

there is an xapps package in focal/groovy/hirsute.

It’s really a question what extra is needed. Anything extra needs to be uploaded to Debian first OR

A patch held that reworks the source to remove the need for the extra bits and bobs.

Ok - I think I’ve reworked the source to remove the nonsensical fork references called xreader - it now uses evince. Linux Mint forking needlessly early versions of apps like evince and calling it xreader etc is something I personally can’t see why they exist … but anyway - my personal view.

build instructions tested on 21.04 (hirsute hippo)

git clone https://github.com/ubuntubudgie/nemo-extensions -b ubuntubudgie
cd nemo-extensions/nemo-preview
sudo apt install build-essential meson ninja-build libclutter-1.0-dev libclutter-gst-3.0-dev libclutter-gtk-1.0-dev libcjs-dev  libgtksourceview-4-dev libmusicbrainz5-dev libwebkit2gtk-4.0-devlibevince-dev 
mkdir build
cd build
meson --prefix=/usr
ninja
sudo ninja install

Probably more dev libraries needed since the above were extra libraries that I installed on my development laptop

Need a debian package created for the above

Ok - for 21.04 I have created a package for this in our backports PPA

sudo add-apt-repository ppa:ubuntubudgie/backports
sudo apt install nemo-preview

Logout and login - press space on files highlighted in Nemo - press space again to close the preview.

1 Like

That is awesome @fossfreedom! Thank you, and will this PPA also work for 20.04? Not sure that I am ready to move from the LTS 20.04 as my primary.

Also I hadn’t ever really heard of either evince or xreader, but it sounds like you are saying evince is I guess the preferred replacement for xreader these days and referencing it instead is sufficient? I guess I ought to test this out under a VM w/ 21.04. If I need to also find the right forum to bring this up to the Ubuntu guys I can do that later as well. I’ve never really reached out to them besides posting an issue on launchpad that usually goes ignored lol, at least in the past because I am usually just confirming that a bug that existed years ago is still relevant and unfixed.

Will also add that I updated my initial post - I had the wrong package name and a missing package name dependency, but it looks like you figured those things out and improved on it.

Also I am not sure what is going on but earlier when I was testing it I was able to open up a preview and then use my arrow keys to change to other files and the preview would automatically update. Right now though it looks like the preview is only stuck on one file at a time… so I am not sure why this appears to be inconsistent and what you may be seeing.

I’ve respun the build for focal and groovy - so nemo-preview packages exist now.

In terms of your arrow key observation - it does sound like nemo is missing support for arrow keys. Logically nemo needs to send a message to the nemo-preview extension to refresh its display.

1 Like

I must have been really tired when I got it working previously, what I had probably done was highlight a file in nemo with the preview open and then move the selection around with my arrow keys and was just hitting the spacebar again. That seems to refresh the preview window just fine.

I do like what you are suggesting though, not sure how to go about updating nemo and the preview extension to interact with each other via the arrow keys. Only issue I see with it would be with text files where the up and down arrow could realistically also scroll.

@rbreaves

Only issue I see with it would be with text files where the up and down arrow could realistically also scroll.

In the gold standard previewer software that we should be comparing this to, the arrows are passed through to the file manager selection at all times, regardless of file type. When it’s open, the preview window binds the PgUp/PgDn/Home/End keys, and these can be used for navigating any previewable “paged” document. It’s very intuitive since the document is displayed as “pages” with a page thumbnail sidebar.

Having the arrow keys only operate in the parent file manager window shouldn’t be a problem unless Nemo-preview doesn’t yet support the use of the PgUp/PgDn/Home/End keys within the preview window.

I’ve seen a solution for using autokey, but really something like this would be better to update directly to work with nemo as fossfreedom suggests. But that would be smart to make the document manipulations based on holding down the Fn and arrow keys or in my Kinto app’s case the Cmd key location and arrow keys.

Kinto can’t really re-route key presses to a specific app when another app has focus - Autokey can do that though, as I had mentioned. Four global hotkeys could be created though for Kinto then those keypresses (arrow keys) on the preview window could easily be mapped via a tool like xdotool to then reroute back to the most recently used nemo file manager. That would be kinda hacky and not as ideal.

@rbreaves

But that would be smart to make the document manipulations based on holding down the Fn and arrow keys or in my Kinto app’s case the Cmd key location and arrow keys.

I hope not. The Cmd-Arrow shortcuts are used for navigation in the file manager in Kinto. This should be restricted to whatever keys have the PgUp/PgDn/Home/End functions. Which, as you’ve seen in the case of my Acer Aspire 5 Slim (A515-43), is not always on the Fn-Arrow keys. That’s Play/Pause/Back/Forward on my keyboard. So the KP_PgUp/KP_PgDn/KP_Home/KP_End key codes from the numpad also need to be supported in the same way.

Implementing this properly needs to be done with bi-directional communication between the main Nemo window and the Nemo-preview window. I assume that’s the kind of purpose for which D-Bus was invented.

If the file manager doesn’t currently have the sole focus then I do not really see why remapping Cmd-Arrows would impact anything at all when the preview window has focus. I assume this type of stuff happens all the time on macs - it shares context more often than most other OS’s and the web browsers are a perfect example of this. Cmd-Arrow can change based on the context of having a text field with focus or have the webpage focused with no text field active. You can go back or forward a page when text is not being manipulated.

It’s really pretty intuitive imo.

@rbreaves

If the file manager doesn’t currently have the sole focus then I do not really see why remapping Cmd-Arrows would impact anything at all when the preview window has focus.

I’m somewhat confused by this.

When previewing in Finder the Quick Look window normally has the active focus the entire time, and there is seldom a reason to go to any effort to switch the focus back to the Finder window. This is precisely because the QL window in macOS is transparent to both the arrow keys alone, for jumping around between different files in a single folder, and to the Cmd+Arrow shortcuts, so you can navigate around to different folders without closing the preview window. I would not want the preview window to interfere with folder navigation just because it has the focus. The way QL works in this manner has always been very handy.

You’re talking about changing context, but in practical terms I can’t really tell exactly what you mean by that where the preview window is concerned. I’d have to experience your implementation of what you’re trying to do. The only thing I can think of is (from your example of the web browser) that it would make sense to grab the arrow keys, and possibly the Cmd+Arrow shortcuts, when actively selecting text inside the preview window. (Which is actually not possible in macOS. It acts more like an image browser, even with text documents.) But outside of that context the arrow keys and Cmd+Arrow shortcuts should otherwise be forwarded to the file manager window for navigating files and folders.

If that kind of context is all you mean by this then I’m confused for no good reason. As usual. But it seems like we may be thinking about the basic function of the preview window differently. As if it’s more like the Preview.app application in macOS, and meant to open with the space bar like QL but act somewhat independently of the file manager window. That’s not the way I think of a “preview” plugin, so having the preview window take over the Cmd+Arrow keys wouldn’t normally make sense to me. Outside of the active text field context.

I just opened up my macbook air to see how things handle and I do indeed see the Fn+Arrow keys move the pages up and down in the preview - but I can’t rely on Fn always being page up and down or those physical keys existing, although it probably does most of the time. My suggestion of using Cmd-Arrow to manipulate the preview is due to Fn differences and limited modifier situations, such as chromebooks.

This situation can be resolved by using either the Cmd key position or Alt/Ctrl on the right side of the keyboard imo and treat it as a secondary Fn key if needed. The mappings though may end up commented out or in the tweaks menu of Kinto (think secondary Fn key, a key I can modify.)

1 Like

I see. Sort of.

Somewhat related, I was just drafting a new comment on the “ctrl+fn arrow” thread about how I got both the KP9/KP3 keys to work as shortcuts, and also was able to use the Fn-arrow media keys for testing the PgUp/PgDn shortcuts. Looks like I got distracted and never finished the comment. But anyway the point is there may be more than one way to skin this cat.

Between normal PgUp/PgDn/Home/End keys, Play/Pause/Previous/Next media keys on arrows, and also the numpad KP_PgUp/KP_PgDn/KP_Home/KP_End keys, I think there might be a good reason to add some new key identification screens to the Kinto installer. So that you can adapt to the unusual keyboards like mine that don’t have proper PgUp/PgDn keys for situations like this.