Building MMview, a universal file viewer
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Obviously not. Your viewer pane is emptygreengeek wrote:Seems to work fine.
You must have misunderstood. See greengeek's example.technosaurus wrote:Can you post a tar.gz of the file... It may just have a stray non-ascii character.
Are you sure? You see "charset=binary"? Here it reports no charset at all.step wrote:mm_view shows and empty pane and detects:
/tmp/testfile │ application/octet-stream; charset=binary
"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
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
- puppy_apprentice
- Posts: 299
- Joined: Tue 07 Feb 2012, 20:32
Another info:
Slacko 5.7, UTF-8, Locale PL
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
Last edited by puppy_apprentice on Mon 26 Feb 2018, 11:40, edited 1 time in total.
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
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
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)
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)
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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.
And for 2 or more ASCII chars followed by a nul char? Surprise! See yourself:
That would be perfectly OK and that's the result I get (see below)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.
Not that simple. My file command classifies 1 ASCII char followed by a nul char as "application/octet-stream". Good.(Unrelated - but common rule of thumb :No \0 in a file -> text-file)
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
- puppy_apprentice
- Posts: 299
- Joined: Tue 07 Feb 2012, 20:32
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)
When changed to ENG/GB i have:
(all files made in ENG/GB settings)
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
(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
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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.
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
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
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
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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" ).
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.
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" ).
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
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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..
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]
That's quite an understatement.MochiMoppel wrote:Good to know that I'm not the only one following this project.
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.
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?
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
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
You can view any of the listed items by pressing F5 (Refresh)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?
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
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.
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.
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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 )
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!
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 )
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