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
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#261 Post by MochiMoppel »

Lobster wrote: I will be studying the code ...
Have fun! I'm sure you will find plenty of room for improvement. And thanks for the encouragement.
Leon wrote:From my experience with using MMview there is only one and only issue left to be solved to use it as default viewer and this is:
How to click a file name in Rox and pass it to MMview to open it?
Is there a trick to do that?
I'm glad to hear that you like and actually use the script.
I don't quite agree that there is only one issue left :lol:

What you describe is not possible with the chooser widget. To be more precise: It would be possible to pass a filename to MMview and show the file content in the viewer, but it would not be possible to select the corresponding filename in the file list programmatically (a limitation of the chooser widget) . This would lead to an irritating status where the viewer content is not the content of the highlighted file in the list. If you are interested in such odd behavior I can provide the code but I don't think that I should implement it. It surely will be perceived as a bug.

My best advise is to keep MMview open and drag the filename from ROX-Filer to the MMview file list. This is the only way to have the chooser widget select a specific file (apart from manual selection). This also changes automatically to the relevant directory. I find this method pretty neat. Too bad that there is no other way to do that.

Leon
Posts: 265
Joined: Wed 22 Jun 2005, 21:33

#262 Post by Leon »

MochiMoppel wrote:What you describe is not possible with the chooser widget. To be more precise: It would be possible to pass a filename to MMview and show the file content in the viewer, but it would not be possible to select the corresponding filename in the file list programmatically (a limitation of the chooser widget) . This would lead to an irritating status where the viewer content is not the content of the highlighted file in the list. If you are interested in such odd behavior I can provide the code but I don't think that I should implement it. It surely will be perceived as a bug.

My best advise is to keep MMview open and drag the filename from ROX-Filer to the MMview file list. This is the only way to have the chooser widget select a specific file (apart from manual selection). This also changes automatically to the relevant directory. I find this method pretty neat. Too bad that there is no other way to do that.
Thank you for the explanation and for the suggestion.
MochiMoppel wrote:If you are interested in such odd behavior I can provide the code
Yes, I’m interested.
I could configure Rox right click to open two different versions of MMview. :idea:
MochiMoppel wrote:but I don't think that I should implement it. It surely will be perceived as a bug.
I agree. :D

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

#263 Post by MochiMoppel »

Leon wrote:Yes, I’m interested.
Please check your mailbox.

B.K. Johnson
Posts: 807
Joined: Mon 12 Oct 2009, 17:11

#264 Post by B.K. Johnson »

I am not complaining nor fault-finding. This is only the off the cuff comments of a first time user of mmview.

I confess that I save web pages as html. At least 90% of the files on my system are .html.
It is perhaps logical that mmview shows an .html file in html code format, but unfortunately, most times I would want to see it in a browser.

The middle panel which has a fixed width is invariably too small for the file names. Mochi tries to overcome this by providing tool tips that display the full path. Commendable, but I'd much prefer resizable middle and right panels.

I have mmview.sh in /root/my-applications.bin. Just for the heck of it, I thought I'd allow emelfm2 to call it to display a text file. It did, but emelfm2 showed the following in its output pane.

Code: Select all

 >mmview.sh "where_maffs_are (ordered).txt"  (16030)
sh: line 3: echo: write error: Broken pipe
Mochi, I'm just including this in case you think it is worth your while. No need to pursue on my behalf. A thought came to mind just now. Maybe emelfm2 needs mmview.sh %f. I'll check.

I'll continue to play with it intermittently. Thanks for the contribution.
[color=blue]B.K. Johnson
tahrpup-6.0.5 PAE (upgraded from 6.0 =>6.0.2=>6.0.3=>6.0.5 via quickpet/PPM=Not installed); slacko-5.7 occasionally. Frugal install, pupsave file, multi OS flashdrive, FAT32 , SYSLINUX boot, CPU-Dual E2140, 4GB RAM[/color]

User avatar
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#265 Post by tallboy »

MochiMoppel, I now test the Dpup Stretch-7.5 RC4, which has mm-view in the menu. I like it very much! Could you please make room for an About menu item, or include some text elsewhere, showing which version is used?

BTW, I am aware of the date shown in the code and name.
True freedom is a live Puppy on a multisession CD/DVD.

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

#266 Post by MochiMoppel »

I'm very grateful for Leon's contribution because it pushed me to try again the seemingly impossible: to startup the chooser widget with a specific file and not just with a file's directory. Judging from my conversation with him it seems to work.

Well, I know that it does not always work, but even in cases where it doesn't work the result is better, at least not worse than the current situation.

The solution requires xdotool, a tool that I try to avoid because of its unreliability. Before implementing it into MMview I would appreciate if people try this out and report any bad effects or incompatibilities. Faster machines than mine or newer distribution may have a negative impact.

Basically there is only one line to add at the very end of the script:
  • <action signal="delete-event">lastrites_cleanup save</action>
    <action signal="map-event">[[ -f "'$1'" && $(type -p xdotool) ]] && { F="'$1'"; F=${F##*/}; [[ ${#F} == $(printf "$F"|wc -c) ]] && D=12 || D=200; xdotool sleep .2 type --delay $D "$F" && xdotool key Escape F5 ;}&</action>
    </window>
How to test: Make above change, then create a ROX desktop icon for MMview and drag a file from a ROX-Filer window onto this icon. MMview should start as usual with the directory of the dropped file, but then the xdotool action kicks it. It uses the fact that typing the first letters of a filename opens a little search box at the bottom of the list and if the typed letters match a file the first matching file will be selected. The code lets xdotool do the typing. Typing the whole filename would - theoretically - match exactly the dropped file and MMview can display the contents of this file. This works pretty well if the filename contains only 7-bit ASCII characters (us-ascii), however when the name contains multibyte characters like Japanese or diacritics, xdotool tends to skip characters while typing. This can be fixed by increasing the delays between each typed character, but it is hard to predict how much delay is needed. Above code uses a delay of 200ms for filenames with multibyte characters and the default 12ms for ASCII characters. In my tests 200ms for Greek and Japanese characters were seldom enough but were sufficient for Slovene and French. Eventually any filename can be correctly typed given enough delay, but too much delay can stretch the patience of the user :wink: .
I also added a small sleep of 0.2sec. When gtkdialog receives the "map-event" signal the dialog window is not yet displayed, so there is a danger that typing starts before the window is ready. Increasing the sleep may help to make typing more reliable.

No harm is done when xdotool is not installed. MMview will work as before. The line is processed only once at startup and only when a filename was passed. Has practically zero impact on performance.

If this change works reasonably well for most users I see very interesting implications. You can try this by changing line 1193 to
  • <action>lastrites_save;exec "$APP_PATH" "$vCHOOSER" &</action>
Switching between vertical and horizontal layout (Menu > File > Vertical layout) requires a restart and currently it will take the user only to the same directory but not the same file. With the change MMview will "land" on the same file that was selected before the switch, and this nice effect will be possible for any other feature that requires a restart.

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

#267 Post by MochiMoppel »

Update 2019-07-02 (see also initial post)
Some small changes and fixes.

UTF-16 codepoints
"Convert text string" dialog now also generates each character's Unicode UTF-16 codepoint

Knowing a character's codepoint makes it possible to
1) find the name/meaning/pronunciation of this character and many more characteristics. Just input the codepoint in its usual notation U+nnnn into any internet search engine.
2) type the character on the keyboard. E.g. to produce the first letter in the screenshot type Ctrl+Shift+U223c

Note that a Unicode character's bytestring (e.g \xe2\x8b\x83) is also important because it makes it possible to
1) count a character's bytes
2) search/replace this character with command line tools like sed
3) print this character (e.g. using echo command: echo -e '\xe2\x8b\x83') even in older bash versions

File selection with xdotool
Explained in previous post. I didn't receive any complaints and take it as an indication that I can savely add it to the code.

Tooltip bug
Seems to be yet another bug in JWM2.3. The "tooltip" in text fullscreen mode is actually a gtkdialog window. I invented this "fake" tooltip because I found the normal tooltip too annoying as there would be no way to make it disappear in fullscreen mode. The window is supposed to close when it loses focus, e.g. when user clicks anywhere outside the tooltip, latest when the user right-clicks to leave fullscreen mode. In JWM 2.3 it doesn't and the tooltip stays on while in older versions and perhaps in other window managers it works correctly. As a workaround the tooltip now appears under the mouse pointer and does not rely anymore on the "focus-out-event" signal

Other changes
- Fixed an issue with junk metadata in raw images produced by Canon EOS 750D
- Last used directory and window size now always and "officially" saved on exit (was supposed to be saved only when user closed with Ctrl+Q or Quit button and worked this way in earlier versions. A bug caused the current "always save" behavior and I figured that some users may like it this way).
Attachments
UTF-16_codepoints.png
(49.36 KiB) Downloaded 467 times

radky
Posts: 977
Joined: Mon 03 May 2010, 03:13

#268 Post by radky »

Thanks for the update to MMview.

For your consideration, it seems recent Woof-CE builds have Busybox v1.30.1 and the usage syntax has changed for the 'timeout' utility -- i.e., the -t switch is no longer supported (replaced by the standalone numerical value for seconds).

BusyBox v1.29.3 (2019-01-24 07:45:07 UTC) multi-call binary.
Usage: timeout [-t SECS] [-s SIG] PROG ARGS
MMview line #230: MESSAGE=$(busybox timeout -t1 du -hs "$vCHOOSER")

BusyBox v1.30.1 (2019-04-24 21:49:26 UTC) multi-call binary.
Usage: timeout [-s SIG] SECS PROG ARGS
MMview line #230: MESSAGE=$(busybox timeout 1 du -hs "$vCHOOSER")

https://github.com/puppylinux-woof-CE/w ... 225a9415b8

Best Regards
[color=blue][b][url=http://www.smokey01.com/radky/PupMates.html]PupMates[/url][/b][/color]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#269 Post by greengeek »

I just downloaded version 20190702.gz but seem unable to find how/where to activate "view hidden files".

I am pretty sure I have used it in previous versions (within "view" menu i thought) but cannot see it now.

Any tips please?

cheers!

EDIT : Sorry - ignore that request. I had not maximised the mmview window so had no whitespace within the file list to rightclick anywhere.

:?

EDIT 2 : Actually - now that I have clicked "show hidden files" I now have no way to see any whitespace to turn "show hidden files" off.

Any way to include that option in the "View" menu?
Attachments
no_whitespace_in_filepane.jpg
(57.27 KiB) Downloaded 284 times

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

#270 Post by MochiMoppel »

@radky: Oh boy. That has the potential to break every existing script using the timeout command. In almost all Puppies timeout is symlinked to busybox, requiring the now defunct -t option.
I'll adjust MMview to make it compatible with whatever busybox version is used:

Code: Select all

[[ $(busybox timeout 2>&1)  = *-t* ]] && export TOPT=-t
.
.
MESSAGE=$(busybox timeout $TOPT 1 du -hs  "$vCHOOSER")
@greengeek: Why would you need whitespace? Just rightclick any item in the list.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#271 Post by greengeek »

MochiMoppel wrote:Why would you need whitespace? Just rightclick any item in the list.
Ahhh yes. My apologies. I had no idea that was possible. I thought rightclicking an item would only bring up an item-specific context but yes that gives me the "view hidden files" option.

many thanks!

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

#272 Post by MochiMoppel »

greengeek wrote:Ahhh yes. My apologies. I had no idea that was possible.
I bet hardly anybody has an idea what else is possible.

The GtkFileChooserDialog contains lots of built in but poorly documented keyboard shortcuts.
For example Ctrl+H toggles "View hidden files" on/off (this shortcut is now "taken" in MMview by the hexdump command, but I think I should restore it with the next update. You can still try it in older versions or in Geany's "Open" dialog).
Or try Alt+Home. Or avoid Alt+S (opens Search box... I should block it).

My favorite is F8, followed by any of keys Up,Down,Left,Right,Home,End,PageUp,PageDown. Neat, isn't it? Not extremely useful, but it shows how the developers of GTK -sometimes - care for details.

User avatar
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#273 Post by tallboy »

Uhh, what should happen when F8 is pressed, followed by an arrow key? I have the 2019-04-09 version, and nothing happens, and that's not neat.
True freedom is a live Puppy on a multisession CD/DVD.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#274 Post by greengeek »

I see the panel divisions move - expanding and contracting. (Xenial64). Clever way to make things more readable.

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

#275 Post by MochiMoppel »

tallboy wrote:Uhh, what should happen when F8 is pressed, followed by an arrow key?
With a properly designed GTK theme you would immediately see something just by pressing F8, without pressing some of the arrow keys I mentioned.

Your chooser would have a separator between the left "Places" pane and the file tree with a dotted handle in the middle. This separator would get focus and you should see it because its color changes. Figuring then out what the arrow keys are supposed to do is not difficult.

With an inferior theme you will see nothing.
Are you by any chance using the "Polished-Blue" theme? The author ("I don't know a ton about gtk themes") managed to eliminate the handle and the visible focus change indicator.

To get the handle back delete or comment out the lines

Code: Select all

image
{
function          = HANDLE
file              = "bump.png"
border            = { 2, 2, 2, 2 }
stretch           = TRUE
}
in the file /usr/share/themes/Polished-Blue/gtk-2.0/gtkrc. Or change to a better theme.

mfb

#276 Post by mfb »

Hi MochiMoppel,

The Polished-Blue gtkrc file has some major advantages as well as the defect referenced in your comment.

The attached screen shot shows some extra features at lines 29 and 30 enabling "steppers" see the bottom right corner of the screen shot.

There may well be other themes with such advantages, but, it seems to me, that although "The author of Polished-Blue wrote ("I don't know a ton about gtk themes") that overlooks its major contributions including the ease of making adjustments.
Attachments
shot.jpg
(86.58 KiB) Downloaded 723 times

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#277 Post by greengeek »

Not sure if I am using mmview correctly - but I would like to understand the following behaviour:

if I create a directory as follows:

/root/SoftwareTests_Pets_For_Slacko5.6_Only

the full name does not appear in the mmview left hand "Places" pane when I click "+". (It is truncated by the separator bar)

If I press F8 the separator bar is highlighted and I can press the right hand arrow (or grab the newly highlighted grab handle) to move the separator such that it displays the full directory name.

This is helpful - but it also shrinks that next pane.

Is there maybe some way to get the next pane to increase size using a similar method also??

User avatar
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#278 Post by tallboy »

MochiMoppel, regarding our conversation: I also use the 'Polished Blue' theme, it may be default in Dpup Stretch-75 RC4.
Commenting the lines in .../Polished-Blue/gtk-2.0/gtkrc did not change anything, switching to another theme did. :D
True freedom is a live Puppy on a multisession CD/DVD.

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

#279 Post by MochiMoppel »

greengeek wrote:If I press F8 the separator bar is highlighted and I can press the right hand arrow (or grab the newly highlighted grab handle) to move the separator such that it displays the full directory name.

This is helpful - but it also shrinks that next pane.

Is there maybe some way to get the next pane to increase size using a similar method also??
No. Because this is exactly how paned areas in GTK should work. When size of one pane increases, the adjacent pane shrinks. The left Places pane and the adjacent file tree pane are "glued" with a GtkPane widget, and the overall size of this widget does not change. All hardwired in the chooser widget. No way (and no reason) to change it. And here is more bad news for you: There is no way to add a similar separator between the file tree pane and the right viewer pane. The GtkPane widget is implemented in yad, but not in gtkdialog.

But coming back to your problem: Your idea to solve it is strange. Instead of trying to accommodate the Places pane to the length of your bookmarks, thus wasting valuable real estate, why don't you simply make your bookmarks shorter? Right-click -> Rename and then change "SoftwareTests_Pets_For_Slacko5.6_Only" to something like "SWtests5.6". All bookmarks in the list come with tooltips that display the full paths, so you are never left in doubt what even a cryptic bookmark is linked to.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#280 Post by greengeek »

MochiMoppel wrote:why don't you simply make your bookmarks shorter? Right-click -> Rename and then change "SoftwareTests_Pets_For_Slacko5.6_Only" to something like "SWtests5.6". All bookmarks in the list come with tooltips that display the full paths, so you are never left in doubt what even a cryptic bookmark is linked to.
Ahhh yes - it seems that renaming a "Places" bookmark does not rename the target directory. Nice to know. Thank you!

Post Reply