Building MMview, a universal file viewer

[vovchik]

Dear 01micko and MochiMoppel,

We can give that svg a little eye candy with linear gradients and not much extra bloat, e.g.:

Code: Select all

<?xml version='1.0' encoding='UTF-8'?>
<svg xmlns='http://www.w3.org/2000/svg' version='1.1' 
	height='128' width='128' viewBox='0 0 16 16'>
 <linearGradient id='lg1'> 
  <stop offset='0' stop-color='white' stop-opacity='1' /> 
  <stop offset='1' stop-color='red' stop-opacity='1' /> 
 </linearGradient> 
 <linearGradient id='lg2'> 
  <stop offset='0' stop-color='gray' stop-opacity='1' /> 
  <stop offset='1' stop-color='white' stop-opacity='1' /> 
 </linearGradient> 
 <rect width='100%' height='100%' fill='url(#lg1)' rx='4' ry='4' 
  stroke='white' stroke-width='2' stroke-opacity='0.2'/>
 <g fill='none' stroke='url(#lg2)' stroke-width='1'>
  <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'/>
 </g>
</svg>

And I needed to change the compile command for the xmp mmvicon.c code example because newer gcc syntax is less forgiving:

Code: Select all

gcc mmvicon.c -o mmvicon `pkg-config --cflags --libs gtk+-2.0`

With kind regards,
vovchik

[MochiMoppel]

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.

What I meant with "similar" is that I'll eventually have to re-code anyway because I'm not yet satisfied with my crude artwork. And when I do that. I'll choose a viewbox large enough to let ROX downscale to 48x48. One file for all. No need for height and width then.

We can give that svg a little eye candy with linear gradients

Hmmm...there is a fine line between eye candy and eye sore

Request to all: I consider the "MochiMoppel looking at files" phase finished. I can't think of any more file types in need of a viewer function. Please let me know if there are any types not covered yet that would benefit from the viewer capabilities. Otherwise I would like to move on to the next phase and give the user some tools to "do stuff" with the files. No, not a right click menu, but something like that.

[MochiMoppel]

Update 2017-05-22 (see also initial post)

I consider this the most important update so far because it gives real power to this little script.

Commandbox
This emulates ROX-filer's "Shell command box" which opens when the user presses Shift+!. It allows to execute any command, script or application.

In ROX-Filer this feature is severely crippled by the lack of any output. Hard to tell if a command was successful or not. More a nuisance is its habit of closing the box after the command has finished, which makes repeated runs cumbersome. And lastly there is a danger of freezing the computer completely by an unsuitable (interactive) command.

In MMview these shortcomings are fixed. Commands are run in a visible terminal emulator and commands can easily be repeated for other selected files by pressing F4 (in MS Excel F4 is the tremendously useful shortcut to repeat a previous command or macro). As for stability it should always be possible to stop a command gone berserk by pressing Ctrl+C or - as a last resort - by closing MMview altogether.

F4 allows efficient workflows. Examples:
- View image files and rotate selected images (e.g. with imagemagick)
- Copy or symlink selected files into a specified directory
- Send selected files to trash

For a comparison between ROX-Filer and MMview see below table.

Terminal
Gtkdialog's terminal widget is rarely used and not fully documented. A good chance to try its features and discover its bugs. By default it is limited to a dismal 100 lines of output. With the undocumented tag attribut "scrollback-lines" this value can be changed. I set it to 1024 lines, the urxvt default.

All options are accessible from the Terminal menu. Tooltips try to explain them. Shortcut Ctrl+T toggles visibility on/off.

Which of the options is most suitable depends on the commands. Some commands like "hexdump" or "stat" are useless without a visible terminal, so "Keep open" should be a useful option. For other commands like "cp" or "mv" the opening of a terminal could be rather distracting, making "Never open" a better choice.

Of course the terminal can be used like any other terminal emulator, with commands entered directly into the terminal pane. Still there are advantages by using the command box. Editing and copy/paste is easier. The command never scrolls off the screen and the output keeps tidy. The command box also sets the tab width of the terminal to 4 characters, thus compatible with Geany, while the "raw" terminal uses the traditional 8 character width.

Other changes
Some menu items changed location. Audio/video play is not a saved preference anymore. WIth Ctrl+Z there is now a convenient way (at least with a US keyboard layout) to start/stop audio.

Comparison of "Shell command box" features in ROX-Filer and MMview

Code: Select all

Feature                            | ROX            | MMview
-------------------------------------------------------------
Open command box with keyboard     | Shift+!        | Shift+!
Open command box with mouse        | yes            | yes
Close command box with keyboard    | Esc            | Esc
Close command box with mouse       | no             | yes
C.box closes when command starts   | yes            | no
Execute command with keyboard      | Enter          | Enter or F4
Execute command with mouse         | no             | yes
Command output visible             | no             | yes
Command execution interruptable    | no             | yes
Interactive cmd can freeze computer| yes            | no
Alert user when error occurs       | no             | yes
Template when opened               |  "$@"          |  "$@"
Template configurable              | no             | yes
Procedure "Select another file     |                |
and repeat command"                |1)select file   |1)select file
                                   |2)press Shift+! |2)press F4
                                   |3)press Up key  |
                                   |4)press Enter   |

[drunkjedi]

Good one MochiMoppel, will test it out ASAP.

[zigbert]

First time I have seen the gtkdialog terminal widget in use...
Great!

[smokey01]

It was working on Fatdog-710 but this version isn't, segfault.

[step]

It was working on Fatdog-710 but this version isn't, segfault.

If I recall correctly, Fatdog compiles the stock gtkdialog without the terminal widget, or you need to install libvte to be able to use the terminal widget; one or the other. I can't check right now because I'm not on my computer. I'll have to come back later with further details...
edit: see this

[01micko]

Code: Select all

# ldd `which gtkdialog` | grep vte
	libvte.so.9 => /usr/lib64/libvte.so.9 (0x00007f0bf0b8e000)

If libvte (+ headers) is installed at gtkdialog compile time it is included by default unless explicitly excluded in the configure options; otherwise, of course, it is not included so I guess Mochi should add a check for this before trying to run any code with the terminal widget.

[step]

For Fatdog64-70x Users:

To use the new command box feature, first you need to install this package from the package manager: gtkdialog-vte-514-x86_64-1

[SFR]

It was working on Fatdog-710 but this version isn't, segfault.

If I recall correctly, Fatdog compiles the stock gtkdialog without the terminal widget, or you need to install libvte to be able to use the terminal widget; one or the other. I can't check right now because I'm not on my computer. I'll have to come back later with further details...
edit: see this

That, too. But it (gtkdialog) segfaults anyway.
I pinpointed it to this <action> statement:

Code: Select all

		<action condition="command_is_true(
			## Stop here if NB_PAGE =3 (=terminal page. A manual Refresh via menu sets to 0, thus lets not break here), menu item Keep Terminal Open is checked and the command box is open
			[[ $(<$NB_PAGE) = 3 && $vMENU_KEEPOPEN = true && -s $CBOX_OP ]] && echo true )">
			"break:"
		</action>

Removing the line with ##comment fixed the crash.
___________

Another thing:

Code: Select all

CNFGDIR=$HOME/tmp/mm_view				# For user settings. ($HOME/tmp not saved to savefile. Eventually should be $HOME/.config/<appname>

I was just wondering what's the reasoning behind using ~/tmp instead of the usual ~/.config for user settings?
The fact it's excluded from saving? IOW, not saving is intentional?
FYI, in Fatdog everything in $HOME gets saved.

Greetings!

[step]

Code: Select all

# ldd `which gtkdialog` | grep vte
	libvte.so.9 => /usr/lib64/libvte.so.9 (0x00007f0bf0b8e000)

If libvte (+ headers) is installed at gtkdialog compile time it is included by default unless explicitly excluded in the configure options; otherwise, of course, it is not included so I guess Mochi should add a check for this before trying to run any code with the terminal widget.

gtkdialog --version reports VTE is available

Code: Select all

# gtkdialog --version
gtkdialog version 0.8.4 release (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with support for: GTK+ 2, Glade, VTE.

[mavrothal]

It would appear that the fatdog issue is related to the gtkdialog compile rather mmview or gtkdialog configuration. Was it in FD710?
Compiling gtkdialog in df710 according to the FD recipe, with or without the disable-vte and/or enable-inotify patches does not segfault. No terminal with the disable-vte patch of course but still no crash.
Might need to recompile and update the package.

BTW m2_view or 2m_view sounds better in "exotic" languages than mm_view
BTW2, hardcoding busybox calls may limit its use in no-busybox based distros or with busybox configured "strangely". They may not be mm_view target now, but you never know!

[step]

It would appear that the fatdog issue is related to the gtkdialog compile rather mmview or gtkdialog configuration. Was it in FD710?
Compiling gtkdialog in df710 according to the FD recipe, with or without the disable-vte and/or enable-inotify patches does not segfault. No terminal with the disable-vte patch of course but still no crash.
Might need to recompile and update the package.

Here I'm seeing something different. I just recompiled gtkdialog-vte according to the recipe but unfortunately it does still crash (segmentation fault) when mm_view includes the comment that SFR pointed out.

However, if I keep the comment but erase the tail characters " box is open" it doesn't crash. Maybe it's a buffer overrun somewhere in the gtkdialog code.

[MochiMoppel]

I guess Mochi should add a check for this before trying to run any code with the terminal widget.

I guess Mochi doesn't need to add anything. I heard that he checked with Tahrpup605, which apparently also lacks vte support. Whenever gtkdialog tries to access the (not installed) terminal, instead of the terminal gtkdialog shows a message:"The terminal (VteTerminal) widget requires a version of gtkdialog built with libvte.". Hard to believe that Mochi could say it any better, and on top of it the script remains functional - except for the terminal stuff.

I was just wondering what's the reasoning behind using ~/tmp instead of the usual ~/.config for user settings?

- User settings are now stored separately from tmp files. Directory $HOME/tmp/mm_view is still temporary and will be destroyed by the Puppy shutdown process, but experienced users may change the location to something more permanent like $HOME/.config/mm_view. I prefer to keep the user's system clean from any traces of the script, at least until a proper uninstall process is in place.

In orthodox Puppies everything in $HOME gets saved, except $HOME/tmp, should it exist.

BTW2, hardcoding busybox calls may limit its use in no-busybox based distros or with busybox configured "strangely"

Changed: 'pkill' to 'busybox pkill'. Some Puppies seem to miss the busybox symlink (thanks dejan555)

Can't please everyone...

However, if I keep the comment but erase the tail characters " box is open" it doesn't crash. Maybe it's a buffer overrun somewhere in the gtkdialog code.

You are close. It is not the comment per se and not the fact that it's a multiline command. Tahrpup crashes too. I found that there is a limit of maximum characters, including newline and tab characters, in the command part of command_is_true(command) . In Tahrpup the limit is 254. In Slacko the limit is 266. That's why I didn't receive a buffer overflow error on my system for the problematic 260 character command. Maybe I shouldn't include comments anyway. That was more a reminder for me which I forgot to remove.

And before somebody asks: In Slacko the maximum number of characters of command in an ordinary <action>command</action> is exactly 16382. .Beyond that I get a "input buffer overflow, can't enlarge buffer because scanner uses REJECT" error. I don't expect to ever see this, but then there are the Tahrpup and Fatdog users....nothing surprises me anymore

I uploaded a fixed version.

[MochiMoppel]

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

This update was born out of curiosity. I was curious as to what it takes to convert HTML into pure text. I can convert text into HTML, and all I need is any text editor and a fair knowledge of (X)HTML and CSS. But converting into the other direction I've never done.

I didn't find anything useful on the net, so I decided to roll my own conversion routine. Basically strips all tags, all <style> and <script> sections and displays what's left. I added bullets for some semantic tags, but apart from that no style is applied simply because the edit widget is not able to format text.

In order to convert a page select View => Additional info from the menu or push F1.

HTML
Many files can be found in /usr/share/doc/. Most of them display decently well though none of them uses good HTML .

My locally saved Gtkdialog reference files display the "Definition" section well. All other sections, using tables, are less impressive. Rendering HTML tables with a proportional font and a widget that knows nothing about pixel dimensions is close to impossible, but if anyone has a good idea how to format tables, let me know.

Of course anything beyond simple HTML should be left to a dedicated browser, but to push the envelope I tested with locally saved webpages. Not so bad. The result is close to what I get when in Opera I use "Save as text", sometimes even better. The acid test were webpages of the Washington Post since they use multiple <style> and <script> sections in the <body> part and almost no newline characters. The most extreme and concise HTML I found in Google pages: Giant one liners, not a single byte wasted.

Abiword
Abiword files use HTML and can be viewed as well. How well? Don't really know. I don't use Abiword and I have no other examples than what's already in Puppy.

Notecase
Same as with Abiword. In principle possible, but no experience and no examples.

Have fun!

[zigbert]

Wonderful

[vovchik]

And I agree with zigbert - works really well, looks great and does a lot. Thanks.

[step]

Thank you for this new feature. The attached page is converted well, but there are some spurious '0' characters. Perhaps something odd with the version of sed?

Code: Select all

Fatdog64-710# sed --version
sed (GNU sed) 4.2.2

[MochiMoppel]

Perhaps something odd with the version of sed?

Unlikely. The sed job (adding blank line before "Page Not Found" and the following paragraph) worked well, but something must be wrong with your tr version. Mine is BusyBox v1.21.0.

Try

Code: Select all

echo -n $'Hello\nWorld' | tr -s '\r\n' '\x01'

If this results in Hello0World then tr failed to translate the newline character into hex01.

The converted page should look like this:

[musher0]

Thanks, MochiMoppei.