Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 18 Nov 2018, 21:02
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Building a universal file viewer
Post new topic   Reply to topic View previous topic :: View next topic
Page 15 of 18 [256 Posts]   Goto page: Previous 1, 2, 3, ..., 13, 14, 15, 16, 17, 18 Next
Author Message
MochiMoppel


Joined: 26 Jan 2011
Posts: 1679
Location: Japan

PostPosted: Sat 30 Jun 2018, 03:33    Post subject:  

I intend to add "Run action" to the MMview Properties display and mimic the Properties dialog of ROX-Filer

ROX-Filer determines the "run action" by the MIME type.
So the question is: How does ROX-Filer determine the MIME type?

MMview uses the file command to retrieve the MIME type and displays it in the statusbar. ROX-Filer often disagrees.

While file looks into a file and determines MIME types primarily by magic numbers, ROX-Filer firstly tries to determine MIME by the file extension (as defined in /usr/share/mime/globs). Consequently ROX-Filer is easily fooled by a fake extension. Add a .jpg extension to any file and ROX-Filer "sees" an image file.

It would be not my job to correct ROX. If ROX produces nonsense MMview would have to faithfully reproduce the nonsense.
I thought that this would be easy with the -m option of the rox command:
Code:
-m, --mime-type=FILE   print MIME type of FILE and exit

Two surprises:
1) The MIME type rox -m outputs may depend on the state of the executable file attribute. For files on a FAT file system, where the executable attribute is automatically set for all files, this may lead to funny results.

2) ROX-Filer's properties dialog may not agree with the output of rox -m. With ROX-Filer having its own method of MIME sniffing the prediction of the run action becomes difficult.

In order to sort out this mess I have listed MIME types produced by different commands and for different filenames and attributes. I marked results which I find plain wrong red, those acceptable yellow and the "good" ones green.

Based on this table I will have to come up with a formula for MMview.
mime_types.png
 Description   
 Filesize   55.69 KB
 Viewed   734 Time(s)

mime_types.png

Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1679
Location: Japan

PostPosted: Wed 04 Jul 2018, 23:33    Post subject:  

Another day, another ROX oddity.

I stumbled upon the "Count" dialog. This dialog is very impressive and I would like to copy the functionality for MMview. It is very fast. E.g. after selecting the /usr directory the "Count" dialog tells me in the blink of an eye that this directory contains 369 M, in total 13226 files in 1191 directories.
Good. But this isn't "disk usage" as it claims. 369 M is the sum of 13226 single file sizes.

On the other hand the "Properties" dialog shows disk usage - sometimes. It does it only for directories. For single files it shows filesize in byte units. ROX does never show disk usage of a single file.
rox-directory-sizes.png
 Description   
 Filesize   78.67 KB
 Viewed   698 Time(s)

rox-directory-sizes.png

Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1679
Location: Japan

PostPosted: Fri 03 Aug 2018, 04:09    Post subject:  

Update 2018-08-03 (see also initial post)

Completed "Properties" view, new additional infos for directories and a new menu item to compress/decompress files.

Properties
The Properties view now includes (almost) all features of the ROX properties dialog - only better.

My problem with ROX-Filer's "Run action" item: Most of the time only something feeble like "defaultviewer $@" is displayed.
That's not good enough. Knowing the code that is executed when the user clicks on a file in ROX-Filer is OK, but I also need to know the name of the script which contains the code, otherwise I can't change it.

Guessing the script name does not help here as ROX may store the code in up to 6 different files. E.g. for a PNG file this could be
/root/.config/rox.sourceforge.net/MIME-types/image_png
/root/.config/rox.sourceforge.net/MIME-types/image
/etc/xdg/rox.sourceforge.net/MIME-types/image_png
/etc/xdg/rox.sourceforge.net/MIME-types/image
/root/Choices/MIME-types/image_png
/root/Choices/MIME-types/image

Though ROX will display the script name if it can't figure out the code, it would then not display the code
For ROX it is script name or code, for MMview it's script name and complete code.
As a bonus MMview checks and displays the real application behind default<whatever>.

Count
Pressing F1 after selecting a directory now displays a count of all files in this directory and the accumulated size of all files. See previous post for details.

Compress/decompress file
A new menu item in the File menu. Nothing spectacular, just a toggle to gzip/unzip a file.
Note that this adds/removes a .gz extension.

Other changes
- Permanent settings are now saved to $HOME/.config/mm_view
- Improved support for multiple instances. No clean-up if another instance of MMview still runnung
- Improved running/terminating of audio/video play. No more PID temporary file
- Applying F1 on directory with hundreds of subdirectories displays result dramatically faster (<1sec vs. former 1min)
- Find (Ctrl+F) now faster (redundant function call removed)
properties_rox_vs_mmview.jpg
 Description   
 Filesize   101.08 KB
 Viewed   655 Time(s)

properties_rox_vs_mmview.jpg

new_features.jpg
 Description   
 Filesize   83.27 KB
 Viewed   658 Time(s)

new_features.jpg

Back to top
View user's profile Send private message 
mfb

Joined: 22 Mar 2016
Posts: 60

PostPosted: Fri 03 Aug 2018, 05:47    Post subject:  

Hi MochiMoppel,

Thank you very much for your update.

An immediate favourite, for me, is your new feature whereby

- Permanent settings are now saved to $HOME/.config/mm_view

so that mm_view

starts with last used directory and last used window size.

As a really minor point - I always toggle "Document Line Wrapping" to on - so I wonder if that might be easily saved, as well.

--------------------------------------

PS You've been a star help to me, but the Forum software is not always reliable and both of my most recent PMs to you remained in my Outbox for weeks.
Back to top
View user's profile Send private message 
vovchik


Joined: 23 Oct 2006
Posts: 1469
Location: Ukraine

PostPosted: Fri 03 Aug 2018, 05:50    Post subject:  

Dear MochiMoppel,

Thanks. Very nice improvements - and useful. All working for me.

With kind regards,
vovchik
Back to top
View user's profile Send private message 
perdido


Joined: 09 Dec 2013
Posts: 1049
Location: ¿Altair IV , Just north of Eeyore Junction.?

PostPosted: Sat 04 Aug 2018, 11:31    Post subject:  

Once again, thank you MochiMoppel!

It was a nice suprise to see MMview included in upup bionic beaver.

One of my "would like to see" things, not urgent Smile

I like how ROX lets me go deeper into the directory tree with a single mouse click. Is something like that planned for MMview?

.

_________________
Giving with an expectation for return brings misery.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1679
Location: Japan

PostPosted: Sat 04 Aug 2018, 22:40    Post subject:  

mfb wrote:
As a really minor point - I always toggle "Document Line Wrapping" to on - so I wonder if that might be easily saved, as well.

Relatively easy, but may I ask why you need line wrapping so often? For my decision not to save this setting I took Geany as a model. Geany saves almost everything - except line wrapping. It always reverts to no wrap, and for an editor I consider this a good design. Have you tried fullscreen mode? I use this a lot when the viewer pane is not wide enough. Documents in EPUB format MMview already display in line wrap mode by default.

vovchik wrote:
Very nice improvements - and useful. All working for me.

Glad to hear that. In order to find out which Puppy you are using I checked your posting history and stumbled on your gxlat project. Very impressive. I would like to play with the massive gawk command of the trans script in MMview , but first I have to get it to work and then - the more daunting task - I have to understand it.

perdido wrote:
I like how ROX lets me go deeper into the directory tree with a single mouse click. Is something like that planned for MMview?

Quick answer: no.
Technically it is not possible. The GtkFileChooserDialog, the "father" of gtkdialog's chooser widget, does not allow this selection mode - for very good reasons.
Back to top
View user's profile Send private message 
slavvo67

Joined: 12 Oct 2012
Posts: 1570
Location: The other Mr. 305

PostPosted: Sat 04 Aug 2018, 23:58    Post subject:  

Mochi:

I haven't looked at this in quite sometime. Congratulations, your file viewer has come along nicely. Can I ask you to consider a few things?

In viewing .jpg files, you have an option under preferences to fit image in viewer size. When using that option, it reflects the % of the original size and the actual size, For example, "Scaled at 30% of 1080x1350." When an image isn't scaled to fit the image viewer, it solely states, "Original Size". Would you consider reflecting the size of the original image next to the "Original Size" wording, such as, "Original Size 600x800?"

Secondly, the .rtf preview window shows the hidden code instead of just the typed letter. Is there a way to fix that?

Either way, it's a great file viewer! - Thanks. Slavvo67
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1679
Location: Japan

PostPosted: Tue 07 Aug 2018, 05:18    Post subject:  

slavvo67 wrote:
When an image isn't scaled to fit the image viewer, it solely states, "Original Size". Would you consider reflecting the size of the original image next to the "Original Size" wording, such as, "Original Size 600x800?"

The header text is just a hint to distinguish original sized from scaled images. Even in scale mode an image would be labeled as "Original Size" when the image fits into the viewer pane without scaling, so the header is there to avoid ambiguities. In scale mode the dimension has to be calculated and the width/height values in the header are a by-product of this calculation.

Currently In original size mode no calculation is taking place. That's good for performance. Would I add a calculation just to add the image size to the header, I would not only worsen performance but I would also have to deal with the problem of fetching dimension values for all supported image formats. There is simply no single tool that would give me this information and for some formats there is no tool at all.

slavvo67 wrote:
Secondly, the .rtf preview window shows the hidden code instead of just the typed letter. Is there a way to fix that?
There is nothing broken so there is nothing to "fix". What you see is not hidden code but the content of the RTF file. It's the same as with your earlier request for PDF: If you want to see the source data of the file converted into a styled document you will need to open it with a dedicated program. If you expect MMview to convert RTF into plain text I have to disappoint you:
- Puppy does not ship with tools that could convert them
- RTF is dead. Microsoft practically abandoned it.
- And writing a conversion routine from scratch? Take a look at the function view_htm2txt to get an idea what it takes to (very insufficiently!) convert HTML.
RTF is much more difficult than that. For me a waste of time, but if anyone volunteers I will gladly incorporate the result into MMview.
Back to top
View user's profile Send private message 
Argolance


Joined: 06 Jan 2008
Posts: 3460
Location: PORT-BRILLET (Mayenne - France)

PostPosted: Thu 09 Aug 2018, 04:35    Post subject:  

Bonjour,
Thanks for this great and so useful application that was missing from Puppy's panoply! Cool
May I say that it is a pity that the GUI was not built to allow internationalization? Sad

Cordialement.
mmv.png
 Description   For those who need the icon to build a desktop file...
 Filesize   1.92 KB
 Viewed   317 Time(s)

mmv.png


_________________


Last edited by Argolance on Fri 10 Aug 2018, 09:22; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
slavvo67

Joined: 12 Oct 2012
Posts: 1570
Location: The other Mr. 305

PostPosted: Thu 09 Aug 2018, 18:12    Post subject:  

Any puppy with LibreOffice or OpenOffice will convert .rtf files. MS abandons anything that doesn't make them money so I'm not surprised.

Anyway, thanks for the clarification. I already packaged the Universal File Viewer and hope to add it to a new version of RU Xerus. Good stuff.
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1679
Location: Japan

PostPosted: Thu 16 Aug 2018, 22:40    Post subject:  

@slavvo67: Coming back to your request for displaying image size: Though I don't think that this information should be part of the on-the-fly view I agree that it should be made available somehow as an on-demand view (F1).
I checked the possibilities and summarized them in below chart. I can't see a 100% perfect solution but I'll try to address your request in future updates.

Code:
        Ability to display image size
Format  exiv2   file    identify    xprop
ANI     -       -           -       ok
BMP     ok      ok          ok      ok
GIF     ok      ok          ok      ok
ICO     -       ok          -       ok
JPEG    ok      -           ok      ok
PCX     -       ok          ok      ok
PNG     ok      ok          ok      ok
SVG     -       -           ok      ok
TIFF    ok      -           ok      ok
XPM     -       -           ok      ok


exiv2
MMview uses exiv2 for scaling images. So far nobody reported that scaling fails. I therefore assume that exiv2 is present in all current Puppies. It also means that according to above chart scaling is possible for images of type BMP, GIF, JPEG, PNG and TIFF. SVG is scalable by design and doesn't require exiv2.
Displaying image sizes is possible for the listed formats.

file
MMview uses file for the Properties dialog. For formats BMP, GIF, ICO, PCX and PNG image sizes are already displayed when the user pushes the Properties button or Ctrl+P.
Allegedly newer versions of file can also display JPEG size (haven't tested)

identify
identify is part of the ImageMagick suite, not commonly preinstalled in Puppy, therefore I can't rely on it in MMview (though, of course, if installed it can be used via the CommandBox )

xprop
Looks like a winner but is more a work around.
Among many other data xprop can display the requested minimum window size, which is identical with the image size if the window displays just the image without any window decoration or border.
Just for fun I integrated a function into MMview which
- creates a new window for the displayed image
- calls xprop to read the image size (not actual window size!)
- closes the window
Works well and so fast that the user may notice only a flicker, and for small images not even that.
Still I find this solution odd and don't intend to keep it. The only formats for which such work around would be needed are ANI, SVG and XPM. Shouldn't be too hard to doubleclick and get the required information from the default viewer.
Back to top
View user's profile Send private message 
slavvo67

Joined: 12 Oct 2012
Posts: 1570
Location: The other Mr. 305

PostPosted: Fri 17 Aug 2018, 14:06    Post subject:  

Hi Mochi:

Thanks but after I posted, I realized you have an icon on the top right for view file properties. That gives me the info I need. Very happy with the MM File Viewer.

Thanks again!

Slavvo67
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1679
Location: Japan

PostPosted: Fri 24 Aug 2018, 08:59    Post subject:  

slavvo67 wrote:
I realized you have an icon on the top right for view file properties. That gives me the info I need

Are you saying that you can see JPG sizes in the Properties display? I can't. How does the output look?


RAW formats
For fun I fed MMview some digicam RAW images. I didn't expect to see anything but to my surprise some camera maker's formats can be displayed. Of course the main image is not viewable but the embedded thumbnails are. How many thumbnails are contained and how big they are depends on the maker. "Thumbnail" can be a gross understatement. In case of an iPhone test image the size was 852 x 640.

Another good news: Though RAW files are huge, seldom less than 10MB and sometimes as big as a Puppy distro, scrolling through the file list is smooth. Obviously gtkdialog stops reading the file when it finds the thumbnail

Adobe's DNG format is used by many makers but there seem to be variations that explain the mixed results in my small test.

"Not yet supported" in below list means that MMview can't view the thumbnail directly. I will have to extract it first and then create a symlink. Shouldn't be too difficult. If anyone has tested other formats I would appreciate feedback.

Code:
MMview support for thumbnail display of some Camera maker's RAW formats

Already supported
.DNG        Apple (iPhone); Leica
.ERF        Epson
.3FR        Hasselblad
.MEF        Mamiya
.NEF        Nikon

Not yet supported but planned
.CR2        Canon
.DNG        Canon
.RAF        FujiFilm
.MRW        Minolta
.ORF        Olympus
.RW2        Panasonic
.PEF        Pentax
.SRW        Samsung
.ARW        Sony

Probably impossible
.MDC        Minolta
.X3F        Sigma
.DNG        Google (Pixel 2 XL). Gtkdialog crashed
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1679
Location: Japan

PostPosted: Sat 08 Sep 2018, 21:16    Post subject:  

Recently I've received some digicam JPGs, each about 3.5M with a resolution of 3456 x 4608 px.
Scrolling through these pictures in MMview was *very* slow. Each picture needed 3sec before it was displayed. That's unacceptable.

I then switched preferences to "Fit images to viewer size" - and the pictures were rendered in less than a second. I never anticipated such a huge difference. I always thought that scaled images would result in slower, not faster rendering. After all GTK has to calculate the new dimension and also MMview has to go through a couple of routines to determine size of viewer pane and scaling factor. Anyway, despite all these additional procedures scaled down pictures display faster.

For comparison I viewed the pictures with Viewnior to see if I can see the same effect. To my surprise in Viewnior the pictures always loaded slowly, scaled or not.

First idea that came to mind: Make "Fit images to viewer size" the default.
On a second thought I figured that the current "Original size" mode isn't of much use anyway, so I decided to scrap this option in the next update. This still leaves 3 different display options, which I think is sufficient and covers all useful display modes.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 15 of 18 [256 Posts]   Goto page: Previous 1, 2, 3, ..., 13, 14, 15, 16, 17, 18 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1008s ][ Queries: 13 (0.0303s) ][ GZIP on ]