Building MMview, a universal file viewer

[MochiMoppel]

I intend to add "Run action" to the MMview Properties display and mimic the Properties dialog of ROX-Filer

ROX-Filer determines the "run action" by the MIME type.
So the question is: How does ROX-Filer determine the MIME type?

MMview uses the file command to retrieve the MIME type and displays it in the statusbar. ROX-Filer often disagrees.

While file looks into a file and determines MIME types primarily by magic numbers, ROX-Filer firstly tries to determine MIME by the file extension (as defined in /usr/share/mime/globs). Consequently ROX-Filer is easily fooled by a fake extension. Add a .jpg extension to any file and ROX-Filer "sees" an image file.

It would be not my job to correct ROX. If ROX produces nonsense MMview would have to faithfully reproduce the nonsense.
I thought that this would be easy with the -m option of the rox command:

Code: Select all

-m, --mime-type=FILE	print MIME type of FILE and exit

Two surprises:
1) The MIME type rox -m outputs may depend on the state of the executable file attribute. For files on a FAT file system, where the executable attribute is automatically set for all files, this may lead to funny results.

2) ROX-Filer's properties dialog may not agree with the output of rox -m. With ROX-Filer having its own method of MIME sniffing the prediction of the run action becomes difficult.

In order to sort out this mess I have listed MIME types produced by different commands and for different filenames and attributes. I marked results which I find plain wrong red, those acceptable yellow and the "good" ones green.

Based on this table I will have to come up with a formula for MMview.

[MochiMoppel]

Another day, another ROX oddity.

I stumbled upon the "Count" dialog. This dialog is very impressive and I would like to copy the functionality for MMview. It is very fast. E.g. after selecting the /usr directory the "Count" dialog tells me in the blink of an eye that this directory contains 369 M, in total 13226 files in 1191 directories.
Good. But this isn't "disk usage" as it claims. 369 M is the sum of 13226 single file sizes.

On the other hand the "Properties" dialog shows disk usage - sometimes. It does it only for directories. For single files it shows filesize in byte units. ROX does never show disk usage of a single file.

[MochiMoppel]

Update 2018-08-03 (see also initial post)

Completed "Properties" view, new additional infos for directories and a new menu item to compress/decompress files.

Properties
The Properties view now includes (almost) all features of the ROX properties dialog - only better.

My problem with ROX-Filer's "Run action" item: Most of the time only something feeble like "defaultviewer $@" is displayed.
That's not good enough. Knowing the code that is executed when the user clicks on a file in ROX-Filer is OK, but I also need to know the name of the script which contains the code, otherwise I can't change it.

Guessing the script name does not help here as ROX may store the code in up to 6 different files. E.g. for a PNG file this could be
/root/.config/rox.sourceforge.net/MIME-types/image_png
/root/.config/rox.sourceforge.net/MIME-types/image
/etc/xdg/rox.sourceforge.net/MIME-types/image_png
/etc/xdg/rox.sourceforge.net/MIME-types/image
/root/Choices/MIME-types/image_png
/root/Choices/MIME-types/image

Though ROX will display the script name if it can't figure out the code, it would then not display the code
For ROX it is script name or code, for MMview it's script name and complete code.
As a bonus MMview checks and displays the real application behind default<whatever>.

Count
Pressing F1 after selecting a directory now displays a count of all files in this directory and the accumulated size of all files. See previous post for details.

Compress/decompress file
A new menu item in the File menu. Nothing spectacular, just a toggle to gzip/unzip a file.
Note that this adds/removes a .gz extension.

Other changes
- Permanent settings are now saved to $HOME/.config/mm_view
- Improved support for multiple instances. No clean-up if another instance of MMview still runnung
- Improved running/terminating of audio/video play. No more PID temporary file
- Applying F1 on directory with hundreds of subdirectories displays result dramatically faster (<1sec vs. former 1min)
- Find (Ctrl+F) now faster (redundant function call removed)

[mfb]

Hi MochiMoppel,

Thank you very much for your update.

An immediate favourite, for me, is your new feature whereby

- Permanent settings are now saved to $HOME/.config/mm_view

so that mm_view

starts with last used directory and last used window size.

As a really minor point - I always toggle "Document Line Wrapping" to on - so I wonder if that might be easily saved, as well.

--------------------------------------

PS You've been a star help to me, but the Forum software is not always reliable and both of my most recent PMs to you remained in my Outbox for weeks.

[vovchik]

Dear MochiMoppel,

Thanks. Very nice improvements - and useful. All working for me.

With kind regards,
vovchik

[perdido]

Once again, thank you MochiMoppel!

It was a nice suprise to see MMview included in upup bionic beaver.

One of my "would like to see" things, not urgent

I like how ROX lets me go deeper into the directory tree with a single mouse click. Is something like that planned for MMview?

.

[MochiMoppel]

As a really minor point - I always toggle "Document Line Wrapping" to on - so I wonder if that might be easily saved, as well.

Relatively easy, but may I ask why you need line wrapping so often? For my decision not to save this setting I took Geany as a model. Geany saves almost everything - except line wrapping. It always reverts to no wrap, and for an editor I consider this a good design. Have you tried fullscreen mode? I use this a lot when the viewer pane is not wide enough. Documents in EPUB format MMview already display in line wrap mode by default.

Very nice improvements - and useful. All working for me.

Glad to hear that. In order to find out which Puppy you are using I checked your posting history and stumbled on your gxlat project. Very impressive. I would like to play with the massive gawk command of the trans script in MMview , but first I have to get it to work and then - the more daunting task - I have to understand it.

I like how ROX lets me go deeper into the directory tree with a single mouse click. Is something like that planned for MMview?

Quick answer: no.
Technically it is not possible. The GtkFileChooserDialog, the "father" of gtkdialog's chooser widget, does not allow this selection mode - for very good reasons.

[slavvo67]

Mochi:

I haven't looked at this in quite sometime. Congratulations, your file viewer has come along nicely. Can I ask you to consider a few things?

In viewing .jpg files, you have an option under preferences to fit image in viewer size. When using that option, it reflects the % of the original size and the actual size, For example, "Scaled at 30% of 1080x1350." When an image isn't scaled to fit the image viewer, it solely states, "Original Size". Would you consider reflecting the size of the original image next to the "Original Size" wording, such as, "Original Size 600x800?"

Secondly, the .rtf preview window shows the hidden code instead of just the typed letter. Is there a way to fix that?

Either way, it's a great file viewer! - Thanks. Slavvo67

[MochiMoppel]

When an image isn't scaled to fit the image viewer, it solely states, "Original Size". Would you consider reflecting the size of the original image next to the "Original Size" wording, such as, "Original Size 600x800?"

The header text is just a hint to distinguish original sized from scaled images. Even in scale mode an image would be labeled as "Original Size" when the image fits into the viewer pane without scaling, so the header is there to avoid ambiguities. In scale mode the dimension has to be calculated and the width/height values in the header are a by-product of this calculation.

Currently In original size mode no calculation is taking place. That's good for performance. Would I add a calculation just to add the image size to the header, I would not only worsen performance but I would also have to deal with the problem of fetching dimension values for all supported image formats. There is simply no single tool that would give me this information and for some formats there is no tool at all.

Secondly, the .rtf preview window shows the hidden code instead of just the typed letter. Is there a way to fix that?

There is nothing broken so there is nothing to "fix". What you see is not hidden code but the content of the RTF file. It's the same as with your earlier request for PDF: If you want to see the source data of the file converted into a styled document you will need to open it with a dedicated program. If you expect MMview to convert RTF into plain text I have to disappoint you:
- Puppy does not ship with tools that could convert them
- RTF is dead. Microsoft practically abandoned it.
- And writing a conversion routine from scratch? Take a look at the function view_htm2txt to get an idea what it takes to (very insufficiently!) convert HTML.
RTF is much more difficult than that. For me a waste of time, but if anyone volunteers I will gladly incorporate the result into MMview.

[Argolance]

Bonjour,
Thanks for this great and so useful application that was missing from Puppy's panoply!
May I say that it is a pity that the GUI was not built to allow internationalization?

Cordialement.

[slavvo67]

Any puppy with LibreOffice or OpenOffice will convert .rtf files. MS abandons anything that doesn't make them money so I'm not surprised.

Anyway, thanks for the clarification. I already packaged the Universal File Viewer and hope to add it to a new version of RU Xerus. Good stuff.

[MochiMoppel]

@slavvo67: Coming back to your request for displaying image size: Though I don't think that this information should be part of the on-the-fly view I agree that it should be made available somehow as an on-demand view (F1).
I checked the possibilities and summarized them in below chart. I can't see a 100% perfect solution but I'll try to address your request in future updates.

Code: Select all

        Ability to display image size
Format  exiv2   file    identify    xprop
ANI     -       -           -       ok
BMP     ok      ok          ok      ok
GIF     ok      ok          ok      ok
ICO     -       ok          -       ok
JPEG    ok      -           ok      ok
PCX     -       ok          ok      ok
PNG     ok      ok          ok      ok
SVG     -       -           ok      ok
TIFF    ok      -           ok      ok
XPM     -       -           ok      ok

exiv2
MMview uses exiv2 for scaling images. So far nobody reported that scaling fails. I therefore assume that exiv2 is present in all current Puppies. It also means that according to above chart scaling is possible for images of type BMP, GIF, JPEG, PNG and TIFF. SVG is scalable by design and doesn't require exiv2.
Displaying image sizes is possible for the listed formats.

file
MMview uses file for the Properties dialog. For formats BMP, GIF, ICO, PCX and PNG image sizes are already displayed when the user pushes the Properties button or Ctrl+P.
Allegedly newer versions of file can also display JPEG size (haven't tested)

identify
identify is part of the ImageMagick suite, not commonly preinstalled in Puppy, therefore I can't rely on it in MMview (though, of course, if installed it can be used via the CommandBox )

xprop
Looks like a winner but is more a work around.
Among many other data xprop can display the requested minimum window size, which is identical with the image size if the window displays just the image without any window decoration or border.
Just for fun I integrated a function into MMview which
- creates a new window for the displayed image
- calls xprop to read the image size (not actual window size!)
- closes the window
Works well and so fast that the user may notice only a flicker, and for small images not even that.
Still I find this solution odd and don't intend to keep it. The only formats for which such work around would be needed are ANI, SVG and XPM. Shouldn't be too hard to doubleclick and get the required information from the default viewer.

[slavvo67]

Hi Mochi:

Thanks but after I posted, I realized you have an icon on the top right for view file properties. That gives me the info I need. Very happy with the MM File Viewer.

Thanks again!

Slavvo67

[MochiMoppel]

I realized you have an icon on the top right for view file properties. That gives me the info I need

Are you saying that you can see JPG sizes in the Properties display? I can't. How does the output look?


RAW formats
For fun I fed MMview some digicam RAW images. I didn't expect to see anything but to my surprise some camera maker's formats can be displayed. Of course the main image is not viewable but the embedded thumbnails are. How many thumbnails are contained and how big they are depends on the maker. "Thumbnail" can be a gross understatement. In case of an iPhone test image the size was 852 x 640.

Another good news: Though RAW files are huge, seldom less than 10MB and sometimes as big as a Puppy distro, scrolling through the file list is smooth. Obviously gtkdialog stops reading the file when it finds the thumbnail

Adobe's DNG format is used by many makers but there seem to be variations that explain the mixed results in my small test.

"Not yet supported" in below list means that MMview can't view the thumbnail directly. I will have to extract it first and then create a symlink. Shouldn't be too difficult. If anyone has tested other formats I would appreciate feedback.

Code: Select all

MMview support for thumbnail display of some Camera maker's RAW formats

Already supported
.DNG        Apple (iPhone); Leica
.ERF        Epson
.3FR        Hasselblad
.MEF        Mamiya
.NEF        Nikon

Not yet supported but planned
.CR2        Canon
.DNG        Canon
.RAF        FujiFilm
.MRW        Minolta
.ORF        Olympus
.RW2        Panasonic
.PEF        Pentax
.SRW        Samsung
.ARW        Sony

Probably impossible
.MDC        Minolta
.X3F        Sigma
.DNG        Google (Pixel 2 XL). Gtkdialog crashed

[MochiMoppel]

Recently I've received some digicam JPGs, each about 3.5M with a resolution of 3456 x 4608 px.
Scrolling through these pictures in MMview was *very* slow. Each picture needed 3sec before it was displayed. That's unacceptable.

I then switched preferences to "Fit images to viewer size" - and the pictures were rendered in less than a second. I never anticipated such a huge difference. I always thought that scaled images would result in slower, not faster rendering. After all GTK has to calculate the new dimension and also MMview has to go through a couple of routines to determine size of viewer pane and scaling factor. Anyway, despite all these additional procedures scaled down pictures display faster.

For comparison I viewed the pictures with Viewnior to see if I can see the same effect. To my surprise in Viewnior the pictures always loaded slowly, scaled or not.

First idea that came to mind: Make "Fit images to viewer size" the default.
On a second thought I figured that the current "Original size" mode isn't of much use anyway, so I decided to scrap this option in the next update. This still leaves 3 different display options, which I think is sufficient and covers all useful display modes.

[anewuser]

I then switched preferences to "Fit images to viewer size" - and the pictures were rendered in less than a second. I never anticipated such a huge difference. I always thought that scaled images would result in slower, not faster rendering. After all GTK has to calculate the new dimension and also MMview has to go through a couple of routines to determine size of viewer pane and scaling factor. Anyway, despite all these additional procedures scaled down pictures display faster.

Offtopic.

My reasoning on scaling images down is a far less quantity of pixels to process and send to the display, that might be a reason why it is faster compared to 10x, 20x, 30x, or 40x the quantity of pixels to display.

[MochiMoppel]

My reasoning on scaling images down is a far less quantity of pixels to process and send to the display

Your guess is a good as mine, but all pixels of the original image have to be processed and blocks of original pixels have to be converted into 1 pixel for the scaled image, that's a lot of processing. The number of pixels eventually to be displayed (in the viewer pane) is the same.

I didn't notice a difference for PNG files and for uncompressed formats as BMP it's also no issue as they always are rendered very fast despite their huge file size. So it could well be related to the JPEG compression algorithm.
Anyway, it's interesting but, as you already noted, a bit off topic. Shouldn't be our concern. Important lesson is that scaling doesn't slow the display.

BTW: Next update will include support for Photoshop, RAW and some other image formats. Also included will be support for Exif and other metadata.

[davids45]

G'day MochiMoppel,

Thanks for this interesting and useful addition to Puppy's small utilities. It worked nicely as a pinboard script.

I turned your (August?) script into a pet then an sfs then an sfs based on links to the sfs files on my data partition. This is the form of added app I now prefer for all my Pups (I combine all these sfs into one so setting up a new Pup with my applications is as easy as possible).

I found your MMView will run in a 64-bit Pup - with its 32-bit compatibility libs also loaded (screenshot). I don't know if MMView would run without the 32bit libs included but these libs are already in my all-applications sfs for my 64bit Pup Frugals.

I've attached my (non-links) sfs for anyone to try - who's brave enough .

Looking forward to your next update of mm_view.

David S.

[MochiMoppel]

Update 2018-09-20 (see also initial post)

This update adds more functionality to view and manage digicam photos:
Support for metadata (Exif,IPTC,XMP, Exif comments, GPS geolocation data)
Many more file formats, including camera maker specific RAW formats. I believe that with this update all real life image formats are now supported by MMview.
New or improved buttons make operations easier (I hope).

Metadata
When an image file contains metadata like Exif, it is mentioned in the text above the image. A typical text might read

• 36% of 1360x1020 Metadata:Exif,Comment,GPS

This would be a 1360x1020px image, scaled to 36%, containing metadata.
In this case pushing F1 or the new info button will display an "EXIF SUMMARY", a short list of most important Exif values in human readable form, and a usually long list of "EXIF METADATA" , a list of Exif keys and maker notes. Also included may be "IPTC METADATA" , usually used by photo managing applications for adding tags and key words, and "XMP METADATA", a format preferred by some applications, e.g. Adobe Photoshop.

"Comments" would indicate that the file contains an Exif comment. Comments are typically added by the user. MMview allows to add comments via the Commandbox (editing metadata is interesting stuff but I don't want to go into details here. Would be a topic of its own).

"GPS" geolocation data are present when the user has enabled this function in his/her GPS capable smartphone or camera. These data can then be translated into URLs for sites like Google Maps and help to pinpoint the exact location where a photo was taken.

New file formats
.psd (Adobe Photoshop)
MMview displays the preview image embedded in Photoshop files

.ppm, .pgm, .pbm (Portable Pixmap, Portable Greymap, Portable Bitmap).
All part of the Netpbm toolkit. Gtkdialog can't read such files natively so MMview shows a JPEG copy. Note: PPM did not work when tested with Dpup Stretch 7.5. PGM and PBM were fine. Seems that newer versions of ffmpeg have problems with PPM.

.webp (Google's WebP format)
One of the most amazing formats. Much better compression and retained quality than JPEG. See my comparison here. Because of the small file sizes it produces it is ideal for document archiving and is also increasingly used in Japanese ComicBook archives. The catch: ffmpeg can convert them into JPEGs but in my tests avconv could not, so MMview's support is restricted to Puppies with installed ffmpeg.

.dng, .cr2, .mef, .nef, .pef, .erf, .orf, .arw, .mrw, .srw, .rw2, .raf, .3fr
These are all camera specific RAW formats and probably cover most of the popular camera models and makers. All RAW files have preview files embedded, mostly in JPEG format. MMview extracts and displays these previews. Since (undisplayable) main picture and (displayed) preview image usually have different dimensions, no dimension is given in the header text to avoid confusion.

Buttons
An "Additional Info" button is added as an alternative for F1. This also makes it easy to switch between "Instant View" and "Additional Info View".

A new "Toggle Instant View" button deactivates Instant View. This can be useful to speed up scrolling, particularly when "heavy" images or directories make scrolling sluggish. Also useful when only "Additional Info" or "Properties" is of interest and the file content is not needed to display.
This function is also accessible via Menu - View - Disable Instant View Mode.

The "Line Wrapping" button now displays the current status. With most GTK themes is is difficult to see if a button is pushed ("sunken") or not, in this case if line wrapping is on or off. The button icon now changes depending on status, making this destinction much clearer.

Other changes
"Fit images to viewer size" is now the default mode. The previous default, which showed all images in their original size, has been abolished (see here)

[greengeek]

Is there any possibility of adding a function which could display thumbnails of images in a directory? Even if it was a pretty slow process it could be handy when you are trying to hunt down a specific image within a multitude of images on a camera card or similar.