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

#151 Post by MochiMoppel »

stemsee wrote:When previewing images/text/pdf etc what would it take to implement pinch to zoom in the preview window?..
1) Installing at least GTK 3.14 (introduced the GtkGesture object)
2) Modifying the gtkdialog source code to support it. Good luck! :lol:

stemsee

#152 Post by stemsee »

MochiMoppel wrote:1) Installing at least GTK 3.14 (introduced the GtkGesture object)
2) Modifying the gtkdialog source code to support it. Good luck! :lol:
Pinch to zoom in/out works in geany and viewnior and browsers so teir gtkdialog source code must already be modified, right?

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

#153 Post by MochiMoppel »

Some unfinished business:
stemsee wrote:Pinch to zoom in/out works in geany and viewnior and browsers so teir gtkdialog source code must already be modified, right?
Wrong. None of them uses gtkdialog.

mime-types
some1 wrote:There are ways to update the mime-database -
and for USER to apply his/her own types.
For Lucid users this would be close to impossible as neither the update utility nor the database are included. And for updating the mime-types of directories and symlinks this may not even be sufficient. File must be clever enough to know what a directory is. No need for a database but maybe a recompilation as musher0 suggested? Who knows. Bottomline: this mime stuff is not trivial and I don't expect users to tinker with these files. If Lucid can't be changed, then MMview must change. I like Lucid and I'm pretty confident that I can adapt the script to Lucid's quirks, maybe not 100% but almost. If the changes don't affect overall performance I will do it. A new challenge :lol:

contrast
musher0 wrote:About the lack of contrast of a particular GTK2 theme, you could leave your general GTK2 theme alone and use a second GTK2 theme that has the contrast you want, expressly for Mochi's MMView
The easiest solution with the best performance possible is no theme at all. Either calling MMview with a small script

Code: Select all

#!/bin/bash
export GTK2_RC_FILES=
/path/to/mm_view
or inserting export GTK2_RC_FILES= at the beginning of the mm_view script. The result is a well balanced, no-nonsense, retro-style look from the 90s (see screenshot). I'm inclined to do that and give MMview a distinctive look, but I'm afraid users would kill me.

It is also possible to style only the leftmost "Places" pane and the main file list. Zigbert's GtkDialog - tips tread has an example how to enforce monospace text. Similar approach is possible for the chooser widget. This could be placed somewhere at the beginning of the script:

Code: Select all

MMSTYLE=/tmp/mm_view/mmstyle.txt
echo '
style "MMV" {
base[SELECTED]="Navy"                    # background of selected and focussed item
text[SELECTED]="white"                   # text color of selected and focussed item
base[ACTIVE]="LightSteelBlue"            # background of marked but unfocussed item
text[ACTIVE]="black"                     # text color of marked but unfocussed item
} class "GtkTreeView" style "MMV"
' > $MMSTYLE
export GTK2_RC_FILES=$MMSTYLE:/root/.gtkrc-2.0
I prefer to make no changes to MMview and count on the users to use a suitable theme that suits their taste and needs.
Attachments
mm_view_themeless.png
(50.67 KiB) Downloaded 834 times

dancytron
Posts: 1519
Joined: Wed 18 Jul 2012, 19:20

#154 Post by dancytron »

Nothing worthwhile to add, other than I just tried this out and it is really good.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

possible universal 'playlist' manager

#155 Post by wiak »

Nice project - I really like it.

I've also found something extra you might find useful to handle right-click options in any file manager. It's xhplay (by mcewanw) which in conjunction with his modified xhippo can be used as a kind of universal 'playlist' manager, with which you can select from list of files what to play or view or edit or work on generally. It's not perfect as it stands, but works quite well, and I'm using it to make playlists of Audio files/video files and/or image files (jpg, animated gif, whatever...) but with slight mod of xhplay I've discovered you can also use any kind of file in a playlist (html, pdf, rtf, doc - again whatever. mcewanw probably already knew that...).

Overall I use the combination of file manager and xhippo/modded-xhplay as a rudimentary, easy to understand document management system - just calling up previously constructed playlists whenever wanted and using xhippo to control what to play/view/edit. To load files into xhippo you just highlight them in a filemanager and drag them into xhippo window (or use file manager right-click command Open-with for those filemanagers that provide that facility). You can also load any pre-made playlists (of any mixed file types) directly using xhippo load playlist command in xhippo itself.

I've recently posted in mcewanw's xhippo thread (link below) with details in the hope that he'll improve on my rough idea and supply a dotpet (since I can't do that). Also hoping he'll modify xhippo itself (or similar program 'potamus') to allow passing new file items into an already active playlist, but I he hasn't responded to my post yet. Though I'm no programmer myself I used to manage a small programming team that mcewanw helped me with in the past, and he had a virtual network with programming resources on it, which I still login to. However I haven't been in touch with him personally for a long time cos I've not been active in computing world - hopefully he'll get back to me on this if not via the forum.

I'm sure he'd like your universal file viewer program and maybe contribute.

It's nice.

Here is the xhplay/xhippo link (to my post on mcewanw xhippo thread):

http://www.murga-linux.com/puppy/viewto ... 816#960816

wiak

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

#156 Post by MochiMoppel »

@dancytron, wiak: Thanks for your feedback. Good to know that some people find this endeavour useful.

@wiak: xhippo and MMview follow different concepts and have not much in common. One interesting aspect is the concept of "playlists". In case of documents there should be a better word ("project files"?). The closest you can get in MMview would be a set of files/folders in the bookmarks area. I assume that many people haven't yet discovered how useful GTK bookmarks can be. From a programming point of view they are easy to maintain and - that's their beauty - they can be changed on-the-fly, so you could have different, predefined bookmark sets (call them "playlists") and display them in the bookmarks area as needed. I've experimented with this feature to automatically display the last used directories as a kind of view history. I'm undecided if anything of this is really needed. I suggest that for the time being you make good use of bookmarks. The area is already prepared and it's a waste of space not to use it.

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

#157 Post by MochiMoppel »

Update 2017-08-07 (see also initial post)

MMview now supports Lucid 5.2.8 and provides basic file management functions rename/move/duplicate/delete.

Though in theory with the versatile Commandbox/Terminal combo all file management operations can be performed, I often wished simpler access to basic functions. And then there are many users with an anaemic, VTE-less gtkdialog for whom the Commandbox is not an option.

Speaking of VTE: I will remove the Terminal from MMview. Works great, but few Puppies support it. Scheduled for next update.

MIME type recognition
Strange MIME type definitions were the root cause of MMview's poor performance under Lucid 5.2.8.
I reduced the dependence on the file command and rewrote the fill_statusbar function. Newly defined patterns in other functions are designed to make file type detection more robust.

Rename (move)
Menu File > Rename displays a Rename dialog similar to ROX-Filer. Unlike ROX-Filer it does not display the full path but only the basename, which I hope makes renaming a bit easier. Moving the file by adding the full path of its target location is still supported though.

Duplicate (copy)
This does basically the same as the irritating ROX-Filer "Copy" command - hopefully a bit better.
The Ctrl+C shortcut is normally associated with the "copy to holding space" kind of copy, the one that always comes in tandem with the "Paste" command. What ROX means is the "copy source file to target file" kind of copy. I prefer to call it "Duplicate". In its simplest form it creates a duplicate of the selected file in the same folder (requires a different name). When adding a full (absolute or relative) path the file can be copied to a different directory. Calling it "Duplicate" is also a good excuse for assigning the Ctrl+D shortcut, thus leaving the Ctrl+C shortcut intact for clipboard copies.

Delete
Does pretty much what one would expect, with an important extra feature: Wildcard characters are supported. As MMview does not support multiple selections, deleting multiple files could become tedious. WIldcard can make this job easier, e.g. '*.mp3' would wipe all mp3 files of the current directory. Be careful.

Other changes
- added support for .mpg videos
- added support for wmctrl (if installed will cause dialogs Find/Rename/Duplicate/Delete to stay on top)


Issues
An unresolved issue in Lucid 5.2.8: Viewing size of subfolders (F1 pressed after selecting folder) does not work due to an outdated sort command used in Lucid. I consider this feature (and Lucid) unimportant enough not to search for a fix.

General Gtk-filechooser issue: Chooser permanently scans the displayed file list and immediately updates the display when a file/folder is renamed or removed. This is not true for files/folders at the root level '/'. It's a bit irritating when nothing seems to have changed after a rename/delete operation but maybe this behavior is intentional (root level practically newer changes => no scan?).
Attachments
mmview_new_menuitems.png
(58.8 KiB) Downloaded 547 times

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#158 Post by smokey01 »

Nice.

The new functions Copy, Rename and Delete would be nice on a right click.

Thanks

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

#159 Post by perdido »

I have seven different versions of MMview on my desktop :)

When I open two different versions at same time there is no way to tell them apart except by looking at the MMview icon eyes that have changed color.
I am having a staring contest with icon eyes :shock:

Maybe an "About" on menu task bar somewhere with version number and author name could keep me from wondering which version I have open :)

Thank You Mochimoppel!

.

User avatar
misko_2083
Posts: 114
Joined: Tue 08 Nov 2016, 13:42

#160 Post by misko_2083 »

Mochi have you considered displaying file and folder metadata?
You can format the output of the stat command to be more human readable. Here's an example

If it's too slow maybe it could show up with F1.
Image
Attachments
mm_view_example.gz
(40.3 KiB) Downloaded 138 times

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#161 Post by technosaurus »

misko_2083 wrote:Mochi have you considered displaying file and folder metadata?
You can format the output of the stat command to be more human readable. Here's an example

If it's too slow maybe it could show up with F1.
If you use stat, (or other core utils), please use the busybox compatible variants ... usually short options vs. long options
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
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#162 Post by tallboy »

MMview now supports Lucid 5.2.8 and provides basic file management functions rename/move/duplicate/delete.

Very nice, Mochi!

Code: Select all

### Universal file viewer
### MochiMoppel 2017-08-07
{ ###HEADER
TEMPDIR=/tmp/mm_view				# For temp files
CNFGDIR=$HOME/tmp/mm_view			# For user settings. ($HOME/tmp not saved to savefile. Eventually should be $HOME/.config/<appname>
[[ -d $TEMPDIR ]] || mkdir -p $TEMPDIR
[[ -d $CNFGDIR ]] || mkdir -p $CNFGDIR
I would presume that $HOME is for those who run a frugal Puppy, and use a savefile. I run live Puppys only, no savefiles. Can you please suggest a modification to your code to be used without a savefile? I know I can set it to whatever I prefer, but I would be more comfortable if I could follow your advice. My choice in Lucid 5.2.8.7 would be /root/.config/mm_view.

tallboy
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

#163 Post by MochiMoppel »

@smokey01: Maybe it would be nice, but the existing built-in right-click menu can't be altered.

@perdido: :lol: A collector? Be happy and use only the latest. And if you can't tell them apart anyway, what does it matter if you don't see the version number...or the author name? BTW: I never thought that someone would take my fashion glasses for eyes. I wish I had such impressive eyes :lol:

@misko_2083:Thanks. I have contemplated already many times to use stat in some form, but I always come to the same conclusion: The basic info like filename, date, size is already viewable and most of the remaining info like blocks and inode is too geeky for a normal user. Those who need it can always use the codebox, type stat $@, and enjoy the output for any file. This is why I find the codebox so useful. But your remark reminds me that we might need a "Properties" view (Ctrl+P ?), which could be a clone of the properties menu in ROX-Filer. I'll add it to my to-do-list but I can't promise anything.

@technosaurus:I've checked misko_2083's and my code and don't find anything that might have sparked your comment, so I file it under "General coding advice". Thanks.

@tallboy: Normally $HOME refers to /root. When you use no save file and save config settings to /root/.config/mm_view, those settings will be lost when you exit Puppy. If you want to keep them you should save them outside of Puppy, somewhere in /mnt/home or /mnt/sda1 or whatever your drive is named.

.
Last edited by MochiMoppel on Tue 15 Aug 2017, 13:28, edited 1 time in total.

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

#164 Post by tallboy »

Thank you, mochi. I run my CD as multisession, so I can save the session and keep the setup.

tallboy
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

#165 Post by MochiMoppel »

- double post removed -
Last edited by MochiMoppel on Wed 13 Sep 2017, 13:04, edited 1 time in total.

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

#166 Post by MochiMoppel »

Update 2017-09-13 (see also initial post)

Command line should now work with every Puppy. VTE support has been removed.
This has some advantages:
- Command output in normal text viewer pane often easier to read
- No cutting of output when maximum history lines reached
- Copy & Paste works with familiar shortcuts

Open with last command
That's an option I miss in ROX-Filer. Opens the Commandbox with the last used command instead the default ' $@ '

Command history
ROX-Filer (and every terminal) lets the user scroll through the command history with the Up arrow key.
Theoretically this could be implemented in MMview but would require elaborate code as gtkdialog does not support such behavior. Instead I opted for a lighter and IMO better solution: When the commandbox has focus, pressing Up arrow key will display the command history in the viewer pane. Picking a command from the history involves
- Triple click on command (selects whole line)
- Clean commandbox (by clicking on Clean button at right end of commandbox)
- Middle click in commandbox (pasting selection)

Command templates
I tried to create a user configurable "Frequently Used Commands" menu. Can be done but lacks simplicity. Instead I recommend to create a text file with useful commands, put this file into its own directory and then bookmark this directory. The screenshot shows my oneliners directory as first in the bookmarks list. Clicking on the bookmark will show the contents of the first (= only) file of this directory in the viewer pane. From there I can pick a command just like picking from the command history. Very low-tech but efficient.

As an example the screenshot shows the output of the command

Code: Select all

stat -c $'CHANGED:\t%z\nMODIFIED:\t%y\nACCESSED:\t%x\n' "$@" | sed "s/\..*$//; s/$(date +%Y-%m-%d)/today_____/"
Executing this command with F4 key allows to view comprehensive filedate info for any selected file/directory, much better than chooser's dismal "Modified" column.
Many more oneliners and of course scripts are possible, eventually turning MMview into a customized file manager.

Of course the commandbox can execute any command, not just those related to the selected file. It's very useful for testing and fine-tuning commands since the commands don't scroll away in a convoluted mix of command input and output like in a conventional terminal emulator.
Attachments
commandbox.png
(80.22 KiB) Downloaded 1134 times
Last edited by MochiMoppel on Tue 19 Dec 2017, 01:46, edited 1 time in total.

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

#167 Post by MochiMoppel »

Update 2017-10-20 (see also initial post)

At the start of this thread I was a bit reluctant to implement image scaling. Now I find the 2 available image modes not sufficient. For serious image examination the viewer pane is too small. With this update I introduce quick access to fullscreen display.

Fullscreen modes
A single click on the viewer pane is all it takes to view an image fullscreen (and another click closes fullscreen). Leftclick displays the image in its original size, rightclick fits the image to the screen. Beware that fit-to-screen always tries to fill the screen, i.e. small images will be enlarged.

It is possible to switch between 100% size and fit-to-screen size while in fullscreen mode. Tooltips explain the options.
Attachments
four_image_modes.jpg
(43.36 KiB) Downloaded 1011 times
Last edited by MochiMoppel on Tue 19 Dec 2017, 01:43, edited 2 times in total.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#168 Post by SFR »

Hey Mochi

Just tried the new version in FD and there's a couple of minor issues.

1. The fullscreen doesn't work for me with Compiz.
Compiz Error
Exceeded max texture size
Can be fixed by using the actual dimensions (SCREEN_W & SCREEN_H), instead of 9999x9999.

As for the panel being visible in fullscreen, it's actually not visible in Compiz and Openbox, so far only JWM resists.
But it also can be fixed without the need of wmctrl, by using:

Code: Select all

<window type-hint="6"
https://developer.gnome.org/gdk3/stable ... owTypeHint


2. When I was playing with the above, I switched to another VT and logged-in as a regular user, and noticed that there's still a problem with multiuser-friendliness.
When I launch MM as root, it creates a temp directory /tmp/mm_view with write permissions only for root, so when I run it as a regular user (later or simultaneously), mm_view can't write to that dir.
What about, e.g.:

Code: Select all

TEMPDIR=/tmp/mm_view.${USER}
?

Thanks &
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

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

#169 Post by MochiMoppel »

@SFR: Thanks for your feedback. Very much appreciated.
1. The fullscreen doesn't work for me with Compiz .... Can be fixed by using the actual dimensions (SCREEN_W & SCREEN_H), instead of 9999x9999.
My reason for using 9999: Setting default-height to exact screen height will place bottom part, incl. any horiz. scrollbar, *under* JWM tray, making scrollbar inaccessible. Increasing default-height by only 1 px will put scrollbar above tray, thus value 9999 should be a safe bet until wall size monitors become affordable. JWM is prepared, Compiz is not :lol:
Fortunately type-hint="6" makes these deliberations obsolete. I've never had much luck with type-hint since most values change nothing (in JWM) and I had given up trying to get any use out of this attribute. Good to hear that setting the window's property to _NET_WM_WINDOW_TYPE_DOCK works in JWM, Compiz and Openbox. This means that I can remove not only wmctrl support but also the decorated="false" attribute, right?

One annoyance remains: With <vbox scrollable="true"> gtkdialog adds scrollbars even for images that would perfectly fit on the screen without them. If image's size is within 16px of the screen size (= double scrollbar width), scrollbars appear, and their only purpose is to make the image portion viewable that is covered by the scrollbar... :evil: Is there any workaround for that?
When I launch MM as root, it creates a temp directory /tmp/mm_view with write permissions only for root, so when I run it as a regular user (later or simultaneously), mm_view can't write to that dir
Would it help to create the directory with world write permission? And would there be a way to let any file newly created in that directory inherit this permission? In principle I have no objection to add the user name but I would find it neater to avoid multiple directories.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#170 Post by SFR »

I can remove not only wmctrl support but also the decorated="false" attribute, right?
Yep.
Is there any workaround for that?
Here's what I came up with so far. Comments explain everything, I hope:

Code: Select all

#!/bin/sh

# path to a "fullscreen" image
IMG=

read W H <<< `xwininfo -root | awk 'NR>=8&&NR<=9 {print $2}'`


# works with & without geometry (see below) if we invoke it as a separate instance instead of using 'launch' command
#	<action>gtkdialog -p IMAGE_WINDOW_NORMALSIZE</action>
export MAIN='
<button>
	<label>Show image</label>
	<action>launch:IMAGE_WINDOW_NORMALSIZE</action>
</button>'

export IMAGE_WINDOW_NORMALSIZE='
<window type-hint="6" border-width="0" width-request="'${W}'" height-request="'${H}'">
	<eventbox>
		<vbox scrollable="true" shadow-type="0" width="'${W}'" height="'${H}'">
			<pixmap space-expand="true" space-fill="true">
				<input file>'${IMG}'</input>
			</pixmap>
		</vbox>
	</eventbox>
	<variable>IMAGE_WINDOW_NORMALSIZE</variable>
	<action signal="button-press-event" condition="command_is_true( [[ $PTR_BTN == [12] ]] && echo true )">closewindow:IMAGE_WINDOW_NORMALSIZE</action>
</window>
'

# doesn't work with geometry, but works without it:
gtkdialog -p MAIN
#gtkdialog -p MAIN -G 100x100+0+0
Would it help to create the directory with world write permission? And would there be a way to let any file newly created in that directory inherit this permission?
Theoretically using ACL:
https://unix.stackexchange.com/question ... -directory
but the '-d' (default) option gives 'operation not supported' in FD...
In principle I have no objection to add the user name but I would find it neater to avoid multiple directories.
You can always have one main dir (/tmp/mm_view) that has 777 and then one subdir per user. :wink:

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

Post Reply