The next update to MultiViewer is now available to download from the AMIStore App Store.

Changes since 1.1 release
- Double Click Middle Mouse Button in zoom mode to rest to 100%
- GetPubScreen Arexx command
- Extended FileList saving system
- Always call ScreenToFront when opening wndow
- Doesn't attempt to cache any file greater than the CACHELIMIT
- Improved Install Script

New language support for:
- Czech
- Dutch
- French
- German
- Greek
- Italian
- Spanish
- Swedish

A special thank you to the translators for this!

_________________
Amiga Kit Amiga Store
Links: www.amigakit.com | New Products | A600GS

@amigakit
The update is appreciated but there are serious problems. I downloaded the update and tested it with the default settings (no tooltype changes). I'm using a 1280x1024x16 screenmode but found the same problems with 1280x1024x32 and 1024x768x32 screenmodes. Here is what I found in my initial tests:

1. I initially forgot to make the "Multiviewer:" assignment and when I opened a large image like a 943x825x24 ilbm image (or larger) the Multiviewer window opens full screen size and the image overwrites the right window border, covering the vertical dragbar. Creating the Multivier: assignment or changing the tooltypes to get the toolbar images from PROGDIR: or TBImages: does solve the problem. However, any anxious new user who downloads Multiviewer and immediately opens it to see how well it works (without reading the docs) will surely be disappointed when he/she sees the overwritten right window border. The problem needs to be fixed and not just worked around by changing the default toolbar image location in the tooltypes.

2. I have the jpeg2000 datatype installed (from OS4Depott) and Multiviewer freezes my system when I load some jpeg2000 samples like the one obtained here:
http://midas.kitware.com/bitstream/download/966
The system Multiview program displays all my jpeg2000 images with no problems.

_________________
X1000 with 2GB memory & OS4.1FE

@Xenic

Quote:

1. I initially forgot to make the "Multiviewer:" assignment and when I opened a large image like a 943x825x24 ilbm image (or larger) the Multiviewer window opens full screen size and the image overwrites the right window border, covering the vertical dragbar. Creating the Multivier: assignment or changing the tooltypes to get the toolbar images from PROGDIR: or TBImages: does solve the problem. However, any anxious new user who downloads Multiviewer and immediately opens it to see how well it works (without reading the docs) will surely be disappointed when he/she sees the overwritten right window border. The problem needs to be fixed and not just worked around by changing the default toolbar image location in the tooltypes.

I assume then that you don't have your "small font" set in GUI prefs, so that when the text based buttons don't fit the GUI automatically shrinks to use the smaller font.

It's never really occured to me before but I wonder why this isn't set by default any more as it was in the 3.x days.

The problem is not the size of the image but that the layout is too big for the screen, but window.class forces the initial window to fit n the display clip. If you resize the window it emediatly sorts it self out with the window being larger than the screen.

I guess the installer needs another iteration to make the MultiViewer: assign not just add it to the user startup.

Quote:

2. I have the jpeg2000 datatype installed (from OS4Depott) and Multiviewer freezes my system when I load some jpeg2000 samples like the one obtained here: http://midas.kitware.com/bitstream/download/966 The system Multiview program displays all my jpeg2000 images with no problems.

Installed and tested, didn't work at all for me, just reported unknown datatype.

After some fiddling arround I reliased that the jpeg2000.datatype, doesn't appear to support DTST_MEMORY so the nocaching is required, after that all worked fine.

No lockups on my SAM.

File a bug report with the datatypes author WRT DTST_MEMORY support.

Last edited by broadblues on 12-Jul-2015 at 12:02 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues
Quote:

I assume then that you don't have your "small font" set in GUI prefs, so that when the text based buttons don't fit the GUI automatically shrinks to use the smaller font. It's never really occured to me before but I wonder why this isn't set by default any more as it was in the 3.x days.

I temporarily set the "small font" in GUI prefs and that does resolve the problem. However, if I set the small font permanently, it would be the same as my screen font since that's about the smallest I can read at my age without eyestrain.

Quote:

The problem is not the size of the image but that the layout is too big for the screen, but window.class forces the initial window to fit n the display clip. If you resize the window it emediatly sorts it self out with the window being larger than the screen.

It sounds like window.class could use a little tweaking to avoid such situations. Either that or we need a toolbar gadget that can control the dimensions of the the gadgets like MUI TheBar that YAM uses. If you shrink the YAM window to the point where the toolbar gadgets don't all fit, they are truncated instead of overwriting the window border.

Quote:

I guess the installer needs another iteration to make the MultiViewer: assign not just add it to the user startup.

I don't think there is a foolproof way to be sure a program can find it's external files even if the binary isn't in it's home directory. If you add an assignment to the user startup and the user decides to move the Multiviewer directory to another directory or partition there will still be a problem requiring user intervention to change the assignment. Personally, I never move a binary out of it's home directory. If I want to start it from another location I'll use IconX to start it.

Quote:

After some fiddling arround I reliased that the jpeg2000.datatype, doesn't appear to support DTST_MEMORY so the nocaching is required, after that all worked fine.

I guess that explains why those jpeg2000 file all work with other viewers; they're not doing any caching.

If there will be another iteration (update) of Multiviewer, would it be possible to add an imagescaling option that will scale large images to fit the window but show small images that will already fit in the window at normal (100%) size? Scaled up images don't look so good.

_________________
X1000 with 2GB memory & OS4.1FE

Multiviewer 1.2. (OS4.1FE)

Try the following:
- open an image
- open pull down menu
- highligth save image as / windows bitmap...
- move the pointer back to the disk image of save image as menuitem
- release the menu

The file requester is opens while there was no filetype selected.

Not sure if it is a multiviewer or general menu problem.

Anyway for me bmp would be a better name than windows bitmap.

Thanks!

@Lazi

I can reproduce that.

I have sticky menus open and I close the menu by right clicking.

As as MultiViewer is concerened the windows bitmap (or which ever entry in that sub menu was last highlighted) appears to have been selected.

This might be a bug in menuclass, not sure, need to create a simpler test case to see what heppening with a menuclass menu or gadtools menu and compare.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Has any progress been made on eliminating the Grim Reaper when first loading Multiviewer? After clicking "ignore" Multiviewer 1.2 seems to be fine. But its still an annoyance. This is on an X1000 with OS4.1 FE

Thanks,

_________________
- BCP
AmigaOne X1000 & Amiga 4000

Amiga Response Crew Users Group
Indianapolis, IN USA

@amigakit & broadblues

Sorry if silly question...
But why MultiViewer dont have any option to display Exif Jpeg thumbs with exact orientation?
Was really too few elegant to see thumbs in "random" orientation in preview vindow...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.