Building MMview, a universal file viewer

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#181 Post by technosaurus »

Can you post a tar.gz of the file... It may just have a stray non-ascii character.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#182 Post by MochiMoppel »

greengeek wrote:Seems to work fine.
Obviously not. Your viewer pane is empty :wink:
technosaurus wrote:Can you post a tar.gz of the file... It may just have a stray non-ascii character.
You must have misunderstood. See greengeek's example.
step wrote:mm_view shows and empty pane and detects:
/tmp/testfile │ application/octet-stream; charset=binary
Are you sure? You see "charset=binary"? Here it reports no charset at all.
"charset=binary" for a file containing a single ASCII character would be even more disturbing.
MMview uses command file -i filename.

Code: Select all

# T=/tmp/testfile           
# echo -n > $T ; file -i $T
/tmp/testfile: application/x-empty; charset=binary
# echo -n A > $T ; file -i $T 
/tmp/testfile: application/octet-stream
# echo -n AA > $T ; file -i $T
/tmp/testfile: text/plain; charset=us-asci

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#183 Post by fredx181 »

Same as step for me on Debian Stretch:

Code: Select all

# echo -n A > $T ; file -i $T
/tmp/testfile: application/octet-stream; charset=binary

User avatar
puppy_apprentice
Posts: 299
Joined: Tue 07 Feb 2012, 20:32

#184 Post by puppy_apprentice »

Another info:

Code: Select all

# echo -n > test.txt ; file test.txt
test.txt: empty
# echo -n A > test.txt ; file test.txt
test.txt: very short file (no magic)
# echo -n AA > test.txt ; file test.txt
test.txt: ASCII text, with no line terminators
Slacko 5.7, UTF-8, Locale PL
Last edited by puppy_apprentice on Mon 26 Feb 2018, 11:40, edited 1 time in total.

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#185 Post by peebee »

LxPupSc (Slackware Current)......

Code: Select all

# file -v
file-5.32
magic file from /etc/file/magic
# echo -n > test.txt ; file -i test.txt
test.txt: inode/x-empty; charset=binary
# echo -n A > test.txt ; file -i test.txt
test.txt: application/octet-stream; charset=binary
# echo -n AA > test.txt ; file -i test.txt
test.txt: text/plain; charset=us-ascii
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

some1
Posts: 117
Joined: Thu 17 Jan 2013, 11:07

#186 Post by some1 »

Just meddling:

MM may need feedback on the VERSION of file
peebee provided the version in his post.
Furthermore: test with the -i-switch - MM parses the mime.

I think that I recall, that file was changed,so that 1-char followed by \0 - was to be interpreted as a binary.

(Unrelated - but common rule of thumb :No \0 in a file -> text-file)

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#187 Post by MochiMoppel »

Thanks to all for the feedback. I'm using file version 5.03. Interesting how file has gone through so many versions and IMO has changed for the worse. It's OK to produce no charset when for whatever reasons it is unable to classify a single ASCII, but now binary? But then to classify a zero length file as "binary" is equally strange.
some1 wrote:JI think that I recall, that file was changed,so that 1-char followed by \0 - was to be interpreted as a binary.
That would be perfectly OK and that's the result I get (see below)
(Unrelated - but common rule of thumb :No \0 in a file -> text-file)
Not that simple. My file command classifies 1 ASCII char followed by a nul char as "application/octet-stream". Good.
And for 2 or more ASCII chars followed by a nul char? Surprise! See yourself:

Code: Select all

# echo -ne 'A\0' > /tmp/testfile ; file -i /tmp/testfile  
/tmp/testfile: application/octet-stream; charset=binary
# echo -ne 'AA\0' > /tmp/testfile ; file -i /tmp/testfile
/tmp/testfile: text/plain; charset=binary

User avatar
puppy_apprentice
Posts: 299
Joined: Tue 07 Feb 2012, 20:32

#188 Post by puppy_apprentice »

Ok i've had some suspicions so made some tests.

When my system Locale and Keyboard is Polish i have:
(all files made in PL settings)

Code: Select all

# file -i empty.txt
empty.txt: application/x-empty; charset=binary
# file -i A.txt
A.txt: application/octet-stream
# file -i AA.txt
AA.txt: text/plain; charset=us-ascii
When changed to ENG/GB i have:
(all files made in ENG/GB settings)

Code: Select all

# file -i emptyGB.txt
emptyGB.txt: application/octet-stream
# file -i AGB.txt
AGB.txt: text/plain; charset=us-ascii
# file -i AAGB.txt
AAGB.txt: text/plain; charset=us-ascii

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#189 Post by MochiMoppel »

1-byte files
Thanks again for the feedback. One way to handle such funny "octet-stream" would be another case condition. On the other hand I really want to keep the main routine, the one that kicks in whenever the user makes a new selection, as lean and fast as possible. Therefore I will not give special treatment to such files. Nevertheless I can't ignore them, so I plan to make them viewable through a viewing mode for binaries, something that's on my agenda.

edit v. text
Another thing I need to address is line wrapping mode. Has been requested before and with the new support for ebooks has gained some usefulness. Currently I force ebook displays to wrap latest after 60 characters (and HTML after 90).This wrapping is achieved by using the busybox fold command and is not dynamic.

Since gtkdialog does not support to change line wrapping programmatically, the only solution would be to prepare 2 separate widgets, differing only in their line wrapping properties.

I thought that using the text widget for the viewer instead of the currently used edit widget would provide some advantages. After all an edit widget seems odd when there is nothing to edit, and text should be faster too. That's what I thought...

Wrong I was. Here a small demo of both widgets. While edit works as expected I can't figure out how to make the text widget wrap at the window boundaries. If this is impossible then text is a no-go.

Code: Select all

#!/bin/sh
echo '
<vbox>
	<edit editable="false" wrap-mode="3">
		<width>200</width>
		<height>400</height>
		<input file>/etc/rc.d/rc.sysinit</input>
	</edit>
</vbox>'|gtkdialog -s

echo '
<vbox scrollable="true" width="200" height="400">
	<text selectable="true" can-focus="false" xalign="0" wrap="true">
		<input file>/etc/rc.d/rc.sysinit</input>
	</text>
</vbox>'|gtkdialog -s
However the real show stopper is speed, or better the lack of it. And I'm not talking of milliseconds. In above demo you might notice that the text widget loads slowly. The filesize of /etc/rc.d/rc.sysinit is about 40KB. I also tried a much bigger file (/root/puppy-reference/doc/index.html), which is about 1MB. While edit showed the file instantly on my lame netbook, text needed more that a minute to display an empty window, followed by another minute to display the file. That's more than 2 min for plain text! Unless something is wrong with my distro the text widget is flawed. This is not acceptable and disqualifies the text widget for any larger text portion.

P.S.: The text widget wraps by default, so wrap="true" is not really needed.
Interesting and undocumented (?): The wrap-mode tag attribute is also supported. Value assignments are different from those for the edit widget:
wrap-mode="0" is the same as the default wrap="true". Wraps lines at word boundaries.
wrap-mode="1" wraps lines at character boundaries
wrap-mode="2" wraps lines at word boundaries, but fall back to character boundaries if there is not enough space for a full word
Attachments
edit_vs_text.png
(59.55 KiB) Downloaded 539 times

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#190 Post by MochiMoppel »

Update 2018-04-19 (see also initial post)

Line wrapping
Dynamic line wrapping of text (see also previous post for some of the technical aspects) pretty much reduces the need for the vertical layout. Nevertheless for reading large texts I prefer fullscreen mode (right click on viewer pane).

Line wrapping can be invoked by menu or togglebutton.
I didn't find any suitable button icon for line wrapping, so I rolled my own. Hope that the icon is clear (and not mistaken for number "2" :lol: ).

Line wrapping is off by default and any "on" status is not retained between sessions. Keeping the menu and the button in sync is a bit tricky and applying a saved status at startup, though not difficult, would require more code than I consider justified. Just my personal opinion.

Rearranged menu
I felt that "View" was not the right menu for "Play" and "Show line numbers" items.
"Play" has now its own menu and for "Show line numbers" and the new "Line Wrapping" item I created the "Document" menu, making it consistent with Geany.
Attachments
Line_wrapping.jpg
(79.9 KiB) Downloaded 443 times

slavvo67
Posts: 1610
Joined: Sat 13 Oct 2012, 02:07
Location: The other Mr. 305

#191 Post by slavvo67 »

Mochi,

I've been following this for quite a while and I just wanted to say how great this project is. Haven't been around much since I "Cut the cord" from the monopoly cable company but wanted to express how appreciated this is.

Best,

Slavvo67

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#192 Post by MochiMoppel »

Thanks for your appreciation, Slavvo67. Good to know that I'm not the only one following this project.

Sorry to say that you may have to follow a bit longer before you see a version 1.0. I'm lazy and notoriously slow but I have great fun in what I am doing.

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#193 Post by sc0ttman »

I also think this is class...

I like ranger, the console file manager, and this has a similar feel ... I think it's great work, and have long wanted someone more skilled than me to have a stab at something like this for Puppy..
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

User avatar
drunkjedi
Posts: 882
Joined: Mon 25 May 2015, 02:50

#194 Post by drunkjedi »

MochiMoppel wrote:Good to know that I'm not the only one following this project.
That's quite an understatement.
We have been using this since day one.

It's also included in my daily driver fatdog linux.
It's in Menu > Utility > MMView.

It's good that you keep improving it, I am quite satisfied with it though.

Keep having fun.

mfb

#195 Post by mfb »

As shown in the image - I've clicked the icon immediately below "Help" , chosen the "root" directory, then typed a lower case "m" and the single file and the three unhidden directories which start with that character are listed.

My questions are - is the list for information only - or can I view any of the four items directly from the list and, if so, how?
Attachments
image.jpg
(133.7 KiB) Downloaded 192 times

User avatar
perdido
Posts: 1528
Joined: Mon 09 Dec 2013, 16:29
Location: ¿Altair IV , Just north of Eeyore Junction.?

#196 Post by perdido »

MochiMoppel wrote:Update 2018-04-19 (see also initial post)
Got most of them :)
Missing 5-24-17 & 5-22-17

Thanks mochimoppel!

Image

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#197 Post by MochiMoppel »

perdido wrote:Got most of them :)
Missing 5-24-17 & 5-22-17
:lol:
Try ebay

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#198 Post by MochiMoppel »

mfb wrote:As shown in the image - I've clicked the icon immediately below "Help" , chosen the "root" directory, then typed a lower case "m" and the single file and the three unhidden directories which start with that character are listed.

My questions are - is the list for information only - or can I view any of the four items directly from the list and, if so, how?
You can view any of the listed items by pressing F5 (Refresh)
This location box (and the search box) are part of the chooser widget and make more sense when the chooser is used as originally intended - as a mere file picker, where the chooser would close after the user picked a filename and pressed an OK button.

Gtkdialog does not make these elements available for programming and I see little use for them in MMview. One thing you can do is to paste a file path into the location box and view the file immediately (after pressing F5). No need use the tree. The tree remains unchanged (see screenshot).

BTW: This widget is the basis for the File-Open dialogs in most GTK applications like Geany,Leafpad,Palemoon,Firefox etc. Unless you have selected Search or Recently Used, some built-in keyboard shortcuts can be used:
- Ctrl+L toggles the location box
- Typing '/' (forward slash) will open it too
- My favorite: Ctrl+V will open it and paste the content of the clipboard. (not supported in Geany)
All these tricks are supported in MMview.

IMO the search box works a bit better. It searches for files in your $HOME directory (usually /root), populates the tree with the results and keeps the entry even after closing the box, though apparently no keyboard shortcuts are available.
Attachments
location_box.jpg
(55.6 KiB) Downloaded 661 times

mfb

#199 Post by mfb »

My thanks to MochiMoppel (the author of this "viewer") for his helpful answer in the post immediately above and also for this entire project.

Explorers will find 25 Main + 4 Built-in (well worth a read) features currently listed in the opening post at page 1 of this thread and, of course, the download should they wish to try them.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#200 Post by MochiMoppel »

Update 2018-05-19 (see also initial post)

Rearranged and simplified "File" menu. Three new features added.

New (file or directory)
This combines the "New Blank file" and "New Directory" menu items of ROX-Filer into one menu item. Shortcut Ctrl+N is same as in ROX-Filer. To create a directory a trailing / (slash) has to be added to the new name.
Unfortunately gtkdialog is unable to reliably determine the currently displayed directory (if a selected or currently entered directory is empty). For this reason the full filepath is provided as default template.

Properties
Layout similar to the ROX-Filer dialog. Most of the values are the result of a single stat command. The "Used on disk" size information for files is not available in ROX-Filer and may be useful (and hopefully is correct :lol: )
Some other ROX specific items like "Run action" are (not yet) implemented.

MD5 checksum
Does what it says. The twist is that it records previously checked files and their checksum and thus makes it easy to find identical files or answer the nagging question "Are these 2 file identical?"

Have fun!
Attachments
new_features_mm_view_20180519.jpg
(95.34 KiB) Downloaded 435 times

Post Reply