Building MMview, a universal file viewer

[perdido]

Update 2017-04-06 (see also initial post)



Directory info
F1 will add information about the disk usage of a directory's subfolders. Since subfolders are sorted by size this will make is easy to spot the biggest "disk eaters". IMHO a useful feature.

.

Hi MochiMoppel,

This is an improvement.
One thing about it.
When I use the F1 to look at my /mnt/home/ directory I get no directory list in the right-side window due to my /mnt/home/ being a sym-link. Though /mnt/home/ does open and display contents in the left side window when clicked.

Also....
Are there plans to implement the [Esc] key to back out of things?

Thanks

.

[SFR]

can I be sure that MIME is always labeled as 'x-gzip' and 'x-xz' and not 'gzip' and 'xz'?

At least in case of 'gzip', you can't - file (at least versions 5.04, 5.28 & latest) uses 'x-gzip', however Fatdog uses this patch from Debian:

Code: Select all

Description: Report gz as application/gzip
Author: Daniel Baumann <mail@daniel-baumann.ch>
Bug-Debian: https://bugs.debian.org/688886
Last-Update: 2015-09-18

--- a/magic/Magdir/compress
+++ b/magic/Magdir/compress
@@ -21,7 +21,7 @@
 #	* Produce shorter output - notably, only report compression methods
 #         other than 8 ("deflate", the only method defined in RFC 1952).
 0       string          \037\213        gzip compressed data
-!:mime	application/x-gzip
+!:mime	application/gzip
 !:strength * 2
 >2	byte		<8		\b, reserved method
 >2	byte		>8		\b, unknown method

So, probably all Debian-based distros (including some Puppy derivatives), have it, too.

But there can be more:

Some applications have informally used media types including application/gzip-compressed, application/gzipped, application/x-gunzip, application/x-gzip, application/x-gzip-compressed, and gzip/document to describe data compressed with gzip.

Perhaps using *gzip*) (or even *g*zip*) instead of gzip) in case statement would be more reliable...

Anyway, the bottom line is that application/gzip is the right one.

I also don't know if the tar command really needs the -I option since it seems to sniff the compression program without it.

Yeah, it shouldn't have problems with auto-detecting the used compression method.

Seems that MIME application/x-gzip can be a lot of things. I don't like that

Then you're gonna hate this - just checked in UExtract and files with the following extensions can be seen as application/gzip:

• .adz
• .apk
• .bgz
• .blend
• .cgz
• .cld
• .cpgz
• .cpio.gz
• .cpio.gzip
• .cvd
• .cxarchive
• .depot.gz
• .dia
• .dsl
• .dz
• .emerald
• .emz
• .epk
• .fat
• .gnumeric
• .graphmlz
• .gtp
• .gz
• .gzi
• .gzip
• .iar
• .igz
• .ipk
• .jgz
• .mpz
• .nif
• .oar
• .obt
• .ogz
• .pet
• .psz
• .qpk
• .qpr
• .rub
• .sdz
• .sifz
• .svgz
• .tar.gz
• .tar.gzip
• .tg
• .tgz
• .unitypackage
• .vbox-extpack
• .vgz
• .wrz
• .x3d
• .xcfgz
• .xjtgz
• .zabw

Greetings!

[technosaurus]

all posix shells do globbing, so you can use application/*gzip in your case statement. This reminds me of some code I threw together to implement Xarchive in shell and gtkdialog. I only wrote the reading and formatting code for it, but it seems like that might be enough for your usage. I'm on my droid right now, so the link will have to wait, but it is linked to in goingnuts gtkdialog1 (backport to gtk1) thread.

[MochiMoppel]

@greengeek As I already tried to explain: In principle there is no relation between symlink and viewability, hence no need to highlight, blink or sound anything when a symlink is not viewable. The only case where such relation exists would be a dead link, but this would be evident from the status bar and I don't intend to take additional measures for such case.

@perdido I'm not sure what you are after. The behavior you describe is normal and intended, but maybe not well understood and the "no subdirectories" message is irritating ( a not dereferenced symlink can't have subdirectories by definition). After lot of hair pulling I concluded that it would be best to avoid any ambiguities by treating links like empty directories: Just a hint that it's a symlink to <target> and no additional F1 info. And while I'm at it I will do the same for the /proc directory. Just a hint that it's a virtual file system. Avoids needless processing and delays for calculating useless information.

Regarding [Esc]: Plans? It's already implemented. The [Esc] key serves as the panic key for stopping autoplay and was introduced with Update 2017-02-04 ("To stop the audio: Press ESC key or change to non-audio file or close the window or dbl-click the file, which will stop ffplay and start to play the file in the default player.")

@SFR,technosaurus I think I'll have to tackle any problems resulting from this mess pragmatically. Knowing the specs of files inside an archive is nice but not terribly important. If MMview fails for any less common archive construction, it fails. Not the end of the world. Here is what I will do:
- throw an archive to tar and see if it can display the contents
- if not, feed it to gzip. Ideally the content is a single text file. MMview would display the content of the file, and that's the ultimate purpose of the viewer.
- if it wasn't a gzip file? Bad luck.

As a bonus I will add support for .iso images, .zip and .7z archives, and that should be it. If I screw up or something is really missing the users will let me know ... maybe.

[greengeek]

@greengeek As I already tried to explain: In principle there is no relation between symlink and viewability, .

Accepted. I think my post was badly written - i was not re-requesting symlink info to be displayed, just asking if file types (for non-viewable files) could be highlighted in some way.

[perdido]

@perdido I'm not sure what you are after. The behavior you describe is normal and intended, but maybe not well understood and the "no subdirectories" message is irritating ( a not dereferenced symlink can't have subdirectories by definition). After lot of hair pulling I concluded that it would be best to avoid any ambiguities by treating links like empty directories: Just a hint that it's a symlink to <target> and no additional F1 info. And while I'm at it I will do the same for the /proc directory. Just a hint that it's a virtual file system. Avoids needless processing and delays for calculating useless information.

I was expecting too much, I understand now that the program will not display contents of a sym-linked directory in the right-side window.

Regarding [Esc]: Plans? It's already implemented. The [Esc] key serves as the panic key for stopping autoplay and was introduced with Update 2017-02-04 ("To stop the audio: Press ESC key or change to non-audio file or close the window or dbl-click the file, which will stop ffplay and start to play the file in the default player.")
.

Yes, I missed that. I was attempting to use [esc] to go backwards in the directory structure in the left-side window.

Thanks for taking the time to explain.

.

[MochiMoppel]

I was attempting to use [esc] to go backwards in the directory structure in the left-side window.

Keyboard: Backspace
Mouse: Use button in "path-bar" (that's the button row above the file list, allowing a kind of a bread crumb navigation)

[technosaurus]

It looks pretty good so far, only a few pointers. Feel free to ignore since constructive criticism wasn't solicited.

If you want really fast MIME type detection by extension only first and then by magic values at an offset, you can use my simple MIMEtype program, but for the small number of filetypes a case statement is fine as long as you put the "multiple-dot" extensions first (Example follows).

Code: Select all

do_tgz_stuff(){
#template
}

do_gz_stuff(){
#template
}

case "$filename" in
  *.tar.gz|*.tar.gzip|*.tgz)do_tgz_stuff "$filename";;
  *.gz|*.gzip)do_gz_stuff "$filename";;
  #more here
esac

When case statements get really long it is helpful to put each in its own function. Humans tend to be able to take code in better if it fits on a single screen.


Here is another snippet that might be useful ... checks for the first match in a list of programs

Code: Select all

set_handler(){
	#$1 is the name of the variable you want to set
	#after shift the remaining $@ are executables you want to check for
	var="$1"
	shift
	while ! type -p "$1" 2>&1 >/dev/null; do
		shift #not found so go to next candidate
	done
	#this sets the variable to the value
	eval $var=\"\$1\"
}
#example usage
#note that there is no $ when you pass Do_sh to the function
[ "$Do_sh" ] || set_handler Do_sh loksh dash  hush ash sh bash
echo "$Do_sh is set as the preferred handler for .sh files"

Also rather than hardcoding urxvt, bash etc, you can use $TERM and $SHELL ... or for a text editor $EDITOR and web browser $BROWSER

BTW, I just finished compiling mupdf on fatdog64 and it has the ability to view or convert .xps, .pdf, .epub, .cbz and a few other formats and output them to png, pnm, pgm, ppm, pam, tga, pbm, pkm, pdf, svg or cbz ... it even comes with builtin javascript engine that allows you to do quite a bit of manipulation to build documents, but for this thread, the output to png and svg are the most significant (convert the first page of a pdf to an image for display). If you leave out the ridiculously large fonts (it's a PITA to do), the build is around 2MB.

[MochiMoppel]

If you want really fast MIME type detection by extension only first and then by magic values at an offset, you can use my simple MIMEtype program

Thanks. Currently I'm content with the speed. I'm more concerned with the correctness but haven't seen serious problems so far.

Also rather than hardcoding urxvt, bash etc, you can use $TERM and $SHELL ... or for a text editor $EDITOR and web browser $BROWSER

Yes, I can, but I shouldn't . Using these global variables (if that's what you mean and not locally assigned variables) I would end up in Slacko and maybe other Puppies with mp as $EDITOR and the (non existent) rxvt-unicode as $TERM. Even the global "Puppy variable" $DEFAULTTEXTEDITOR (in Slacko assigned to Geany) would be problematic since I can't be sure that the user hasn't changed his default editor after starting X. Hardcoding gives me control and avoids using programs the script is not designed for.

for this thread, the output to png and svg are the most significant (convert the first page of a pdf to an image for display)

IIRC converting pdf to an image can be done relatively easy with command line tools already available in Puppy, but then the question comes up if this is really worth it. However where I see a real potential are formats for which no suitable program is installed. In such cases an image could be a helpful work around and would be better than viewing nothing at all.

[MochiMoppel]

Update 2017-04-16 (see also initial post)

Some new functions and support for additional archive formats.

Line numbers
"Show line numbers" (shortcut F2) adds line numbers to text in the viewer pane. This feature in itself can be useful when viewing scripts etc., but beyond that it complements the new "Find again" feature (see below).

Refresh
For removing above line numbers the new "Refresh" feature (Shortcut F5) comes handy. So far the user had to select a different file, then reselect the current file to achieve a refresh/reset. F5 is common in browsers to reload a page, so it looks like a natural choice. The shortcut for "Execute selected file in console" had to move from F5 to Ctrl+F5 (which also better prevents accidental file execution).

Find
Frankly I never thought it would be possible to implement decent search capabilities in gtkdialog. Too many tools are missing, particularly a tool to highlight matching search results...no, Pango markup is not an option.

Finally I came up with a "Find" dialog (shortcut Ctrl+F), which allows 2 alternative display options, each of them with pros and cons, but both already much better than Total Commander's QuickView.

Extract matching lines
This is the default and very similar to Geany's brilliant "Find document usage" (In Geany select a word, press Ctrl+Shift+D and Geany will present a list with all lines containing this word). MMview diplays a similar list. It's not possible to jump to a specific line, but with F2 (show line numbers) it's possible to display all lines. F3 (Find again) returns to the extracted match lines. Particularly for large documents the F2 / F3 combo allows a fast review of search matches.

Use inline markers
All document lines remain displayed and matching search strings are marked with a fat unicode character. Not as good as the impossible highlighting, but not bad either. Here again the F2 / F3 combo comes handy. Hawk-eyed users will notice a ':' after numbers of matching lines and a '-' after numbers of not matching lines. That's the way grep shows results.

Find again
In most applications F3 is a shortcut for "Find next" and would jump to the next match within a document. Gtkdialog can't jump. "Find again" performs the search definded in the Find dialog, but not only for the current file. After selecting a different file F3 will perform the same search on the newly selected file. Again and again...until the user changes the pattern in the Find dialog.

A summary of the search is displayed in the status bar.

New archive formats
MMview now diplays contents of initrd.gz , .iso, .zip and .7z archives

[vovchik]

Dear MochiMoppel,

Great work and thank you. How about including a self-contained icon in the script, e.g.:

Code: Select all

ICONFILE="<""svg width='128' height='128' viewBox='0 0 216 112'> 
<g transform='translate(0.0,112.0) scale(1.0,-1.0)' 
fill='#000000' stroke='none'> 
<path d='M90 104 c-31 -6 -61 -24 -86 -52 -1 -2 1 0 6 4 63 57 129 57 185 0 8 
-9 15 -9 15 0 0 5 -1 6 -10 13 -36 28 -76 41 -110 35z'/> 
<path d='M86 92 c-20 -4 -47 -17 -66 -33 -14 -12 -14 -12 3 0 14 9 41 23 45 
23 1 0 -1 -3 -3 -7 -13 -27 9 -58 39 -56 27 2 44 32 32 56 -1 4 -3 7 -2 7 5 0 
25 -15 33 -25 12 -13 9 -20 -13 -35 -37 -24 -88 -20 -133 8 -8 5 -7 4 1 -2 35 
-25 76 -31 115 -19 15 5 33 15 36 20 3 3 4 3 8 -1 4 -4 8 -4 12 0 13 13 -28 
52 -66 63 -7 2 -33 2 -41 1z m21 -21 c13 -7 9 -27 -6 -27 -16 0 -21 21 -7 27 
6 3 8 2 13 0z m-30 -11 c4 0 5 0 5 -2 0 -2 0 -4 1 -5 1 -3 1 -3 -6 -6 -9 -4 
-10 -3 -11 9 l0 6 3 -1 c2 0 6 0 8 -1z'/> 
</g> 
</svg>"

echo "$ICONFILE" > /tmp/mmview.svg
ICON="/tmp/mmview.svg"

and then adding this to the main gtkdialog:

Code: Select all

export MAIN_DIALOG='
<window title="'${0##*/}'"allow-shrink="true" margin="'$WINDOW_MARGIN'" image-name="'$ICON'">

Just an idea....

With kind regards,
vovchik

[MochiMoppel]

How about including a self-contained icon in the script

Good idea, though I must admit that icons are the last thing on my mind.
Your SVG is a bit problematic since it doesn't scale well to 16x16. For such small icons I prefer XPM. Simple format and full control over every pixel:

Code: Select all

echo '/* XPM */
static char *mmview_xpm[] = {
"16 16 3 1",
"0 c None","1 c Black","2 c White",
"0000000101000000","0000000010000000","0000001111000000","0000112222110000",
"0011222222221100","0122222222222210","1222222222222221","1221112222111221",
"2212221221222122","1122222112222211","2122222112222212","2212221221222122",
"2221112222111222","2222222222222222","2222222222222222","2222222222112222",
};' > $TEMPDIR/mmview.xpm

ICON="$TEMPDIR/mmview.xpm"

Adding to MAIN_DIALOG would be the same as your code.

Edit 2017-4-28: Fixed transparent left-overs (value 0) in the last 6 rows
  
  

[greengeek]

I can view the icon with viewnior but mtpaint seems unable to open it. Does Mtpaint open it for you? If so which version please?
cheers

[MochiMoppel]

I can view the icon with viewnior

..but you shouldn't, now that you have MMview
Viewnior shows ugly artefacts, MMview does not.

Does Mtpaint open it for you?

No.

Edit 2017-4-29: I see now that Viewnior makes invisible/transparent backgrounds visible by replacing them with a gray pattern, hence the "dirty" look. No way to disable this stupid behavior.

[vovchik]

Dear MochiMoppel,

Your not so little app is really well done, and deserves its own icon - and I like to see something unique in the taskbar, so thanks.

With kind regards,
vovchik

[01micko]

SVG icon based on based on MochiMoppel's XPM version..

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 16 16">
  <path d="m 1,16 0,-7 -1,0 0,-1.5 q 0,-3 4,-4 l 4,-1 4,1 q 4,1 4,4 l 0,8.5 z" style="fill:#fff"/>
  <path d="m 0.5,7.5 q 0,-3 4,-4 l 3.5,-1 3.5,1 q 4,1 4,4 m -8.5,-7 1,1 1,-1 m 1,15 2,0 m -12,-6 2,0 a 2.75,2.75 0 1 1 0,0.1 z m 14,0 a 2.75,2.75 0 1 0 0,0.1 z l 2,0" style="fill:none;stroke:#000;stroke-width;1"/>
</svg>

Note: should open in mtpaint (recent), gpicview, viewnior, firefox, seamonkey (other recent browsers that support SVG). Fails in inklite (as do many hand crafted SVG images).

greengeek - MochiMoppel's XPM opens in mtpaint for me with some minor hacking.

MochiMoppel - very nice script by the way.

(edit: whoops, stray backslash crept in, probably fumbling fingers.)

[greengeek]

Based on micko's hack I can get an mtpaint readable xpm by modifying the xpm build as follows:

Code: Select all

echo $'/* XPM */ 
static char *mmview_xpm[] = { 
"16 16 3 1", 
"0 c None",\n"1 c Black",\n"2 c White", 
"0000000101000000",\n"0000000010000000",\n"0000001111000000",\n"0000112222110000", 
"0011222222221100",\n"0122222222222210",\n"1222222222222221",\n"1221112222111221", 
"2212221221222122",\n"1122222112222211",\n"0122222112222212",\n"0212221221222122", 
"0221112222111222",\n"0222222222222222",\n"0222222222222222",\n"0222222222112222", 
};' > /tmp/mmview.xpm

Makes me happier to have it compatible with mtpaint. Hope that doesn't conflict with mmview.

[01micko]

Further to our pm discussion @greengeek I reckon it's an mtpaint bug.

Try this (anyone) and the icon displays. (compile line in the comment).

Code: Select all

#include <gtk/gtk.h>
/* compile with
 *  gcc `pkg-config --cflags --libs gtk+-2.0` mmvicon.c -o mmvicon */
 
static char *mmview_xpm[] = { 
"16 16 3 1", 
"0 c None","1 c Black","2 c White", 
"0000000101000000","0000000010000000","0000001111000000","0000112222110000", 
"0011222222221100","0122222222222210","1222222222222221","1221112222111221", 
"2212221221222122","1122222112222211","0122222112222212","0212221221222122", 
"0221112222111222","0222222222222222","0222222222222222","0222222222112222", 
};

int main(int argc, char *argv[]) {
    
  GtkWidget *window;
  GtkWidget *image;
  GdkPixbuf *x_pixbuf;
  gtk_init(&argc, &argv);

  window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
  gtk_window_set_title(GTK_WINDOW(window), "Image");
  x_pixbuf = gdk_pixbuf_new_from_xpm_data((const char**)mmview_xpm);
  image = gtk_image_new_from_pixbuf(x_pixbuf);
 
  gtk_container_add(GTK_CONTAINER(window), image);

  g_signal_connect(G_OBJECT(window), "destroy",
        G_CALLBACK(gtk_main_quit), NULL);

  gtk_widget_show_all(window);

  gtk_main();

  return 0;
}

Apologies for OT MochiMoppel.

[MochiMoppel]

I reckon it's an mtpaint bug.

Well, it's not completely unreasonable. Mtpaint expects each declaration on a separate line. That's how XPMs are normally written. On the other hand I found nothing in the specification that mandates this format, and since I like it more compact and other apps have no problem with it I grouped multiple declarations on one line. Mtpaint will happily open it in the "classic" format. I didn't use Mtpaint for creating the file, so I didn't notice.

Thanks for the SVG. Creating relative paths by hand is not my cup of tea. Anyway, since I had to correct my XPM (some transparent pixels on bottom left edge. See edited post above) I also took the liberty to change the SVG. The first path should probably read

Code: Select all

<path d="m 0,16 0,-7  0,0 0,-1.5 q 0,-3 4,-4 l 4,-1 4,1 q 4,1 4,4 l 0,8.5 z" style="fill:#fff"/>

I'll see if I can come up with a similar 48x48 SVG so that it can be used as a desktop icon as well.

[01micko]

I reckon it's an mtpaint bug.

Well, it's not completely unreasonable. Mtpaint expects each declaration on a separate line. That's how XPMs are normally written. On the other hand I found nothing in the specification that mandates this format, and since I like it more compact and other apps have no problem with it I grouped multiple declarations on one line.

Agree & agree.

Thanks for the SVG. Creating relative paths by hand is not my cup of tea.

You're welcome.

Anyway, since I had to correct my XPM (some transparent pixels on bottom left edge. See edited post above) I also took the liberty to change the SVG. The first path should probably read

Code: Select all

<path d="m 0,16 0,-7  0,0 0,-1.5 q 0,-3 4,-4 l 4,-1 4,1 q 4,1 4,4 l 0,8.5 z" style="fill:#fff"/>

I'll see if I can come up with a similar 48x48 SVG so that it can be used as a desktop icon as well.

I thought the missing pixels were intentional and in my opinion added a bit of character, but hey it's all yours in the end.

Also, there is absolutely no need to re-code the the svg for 48x48 (or any size for that matter). Just add height="48px" width="48px" to the header just before the viewBox. You'll see in the screen shot I also have a 500x500 version. Any larger and you can go into the T-shirt printing business. This is how the Puppy Icon Theme is built.

Later...

Hmm, I found a bug in my svg while scaling large with this script:

Code: Select all

#!/bin/sh

[ -z "$1" ] && echo "you must specify at least 1 size!" && exit

TMP=${TMP:-/tmp/mmviewicon.html}

echo -e "<html>\n<head>\n<title>mmview icon demo</title>\n<head>\n<body bgcolor="#aaa">" > $TMP

for size in "$@"
do
	cat >> $TMP << _EOF
<p>
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="${size}px" width="${size}px" viewBox="0 0 16 16">
  <path d="m 0,16 0,-7  0,0 0,-1.5 q 0,-3 4,-4 l 4,-1 4,1 q 4,1 4,4 l 0,8.5 z"
   style="fill:#fff"/>
  <path d="m 0.5,7.5 q 0,-3 4,-4 l 3.5,-1 3.5,1 q 4,1 4,4 m -8.5,-7 1,1 1,-1
   m 1,15 2,0 m -12,-6 2,0 z m 2,0 a 2.75,2.75 0 1 1 0,0.01 z m 12,0 a 2.75,2.75 0 1 0 0,0.01 z
   l 2,0" style="fill:none;stroke:#000;stroke-width;1"/>
</svg>
${size} x ${size}</p>
_EOF
done

echo -e "</body>\n</html>" >> $TMP

It makes a demo web page.

Notice I've altered the svg path for the line.

The original is now changed to this:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 16 16">
  <path d="m 0,16 0,-7  0,0 0,-1.5 q 0,-3 4,-4 l 4,-1 4,1 q 4,1 4,4 l 0,8.5 z" style="fill:#fff"/>
  <path d="m 0.5,7.5 q 0,-3 4,-4 l 3.5,-1 3.5,1 q 4,1 4,4 m -8.5,-7 1,1 1,-1 m 1,15 2,0 m -12,-6 2,0 z m 2,0 a 2.75,2.75 0 1 1 0,0.01 z m 12,0 a 2.75,2.75 0 1 0 0,0.01 z l 2,0" style="fill:none;stroke:#000;stroke-width;1"/>
</svg>