All is implemented in the 2.0 version (OS4Depot) except the progress bar for effects. + Space bar to switch between screen-scaled / full size + Arrows keys to navigate between the pictures in the same drawer.
Hmm, FastView "PictureView" from the context menu isn't working here. It does.. nothing. And, despite asking it to replace my icons, it doesn't seem to have done that either (JPEGs still loading into MultiView)
Running it from the command line with Snoopy shows that the JPEG in question is being loaded, but I never see it on screen.
Phantom suggested me that too earlier and you were right, it's useful.
As it was not difficult to add, I have added the rotation in SinglePicture mode (with left-right arrow keys).
It doesn't display the EXIF rotation tag and it rotates directly the original picture.
But as I said in my FastView news, 2.0 should be the last version I want to make another project. Therefore, 2.2 will be the last version for sure ! ;)
I have sent it to you 2 by mail. If you could test it
new version available with your other keys rotation request (kicko and pvanni)
* Added the option at installation to rotate the original picture in SinglePicture mode with Up and Down arrow keys
* Fixed a wrong thumbnailed display of PNG with Alpha layer and GIF pictures
(forgot to add this in the ReadMe, thanks Kicko for the quick report ) * New CLI option to integrate this change FastView SinglePicture SWAP image.jpg to have the rotation with Up/Down FastView SinglePicture NOSWAP image.jpg to have the rotation with Left/Right
New RAMDock and GFXDock too : *Added tooltype to change the colors of the level and of the shadow text (deactivable)
could you maybe change the way the amiupdate autoinstall is handled? currently fastview and flippaper are calling the standard installer. but for autoinstall scripts i personally don't like this. they should update silently without user interaction and only copy the required stuff. just my 2ct...
sure. but imho autoupdate scripts should only do the absolutely necessary. this is copystore/copy. also the archive should be stripped to the neccessary - no full archive. using the installer there should be an exception.
It depends how much it has changed. If every file has been updated and you don't know which version the user is going to be updating from, there's no point in creating a mini update archive (as it'll be exactly the same size as the full one). It's a lot more work to create two archives for every update, and it's more work to write two installation scripts too.
If there's only one file to be copied, sure, just CopyStore it. But most full applications are more complicated than that (and FastView certainly is).
There's nothing wrong with using Installer for auto-updates, the only thing "wrong" here is that it asks some questions which it could store from the first full install and then bypass. Installer could perhaps benefit from a "hidden" mode where it isn't visible and aborts with an error if it has to prompt, but I don't see that being added any time soon.
My NetSurf auto-installer is just the full package install script running non-interactively. I wrote some notes on how to achieve this ages ago, you can read them here.
The installer is needed because there are question to ask to the user.
For example, for ContextualMenu integration, for the path of course, for deficons replacement...
I could store previous settings, of course, but sometime I add option, for example in FastView 2.0 I added the deficon function who needed a user interaction.
Honestly, it takes only few seconds to reply to few questions but for me it will take hours to implement a full automatic installer...
But I have to say I agree with Michael. I also get a slight Windowsy feeling from having to answer the same questions every time I install a new version (no, I still don't want you to mess with my context menu, no, I still don't want you to mess with my deficons ...). It's almost like having to untick the Ask bar every time I update Java on my wife's PC .
Maybe you could just (auto)install the program and let the user use the program's prefs to set up features like those - if they want? Then the settings could survive a program upgrade. And if a new feature is added, the user would just have to select it in the prefs and save them; of course you'd have to be able to load previous versions of prefs files, but that shouldn't be so hard to make work. That's how most others are handling it.
I will again release another version to handle Animated GIF In standard FastView and in SinglePicture mode (requested by a user).
I told you it will never stops :))
Btw, sorry i am a bit out of what you add to FastView lately, but what i found is that when i just rotate pictures its "auto-save" my files. Dunno if you already make it optional, but will be good to have by default no auto-save (as in all other viewers everywhere), and some tooltype/option like "do auto-save when rotate?"
For rotation : -in standard mode it creates another picture.ROTATE by default -In SinglePicture mode, it overwrites the picture to don't wast time and like on MacOS Apercu or Windows default viewer I think
@zzd10h don't wasting time on rotating it's very relative, with todays cameras and phones pictures, saving the rotated picture usually take long time, at least on many NG Amigas, so like I already said a +1 for kas1e request