Excellent! Thankyou Peter!

OK, I've done a little background reading and found some interesting and useful things about this.

First, we are in fact considering two different sort orders, not just differently implemented versions of the same sort order. The old order is called a literal sort where the new one is a numerical sort.

LITERAL SORT

• 1
• 11
• 111
• 2
• 21
• 3898
• 9
• 999

NUMERICAL SORT

• 1
• 2
• 9
• 11
• 21
• 111
• 999
• 3898

As we can see, they are very different!



Second, Windows allows the user to select which one is desired in either of two ways.

The easy way is to use the group policy editor (run gpedit.msc) and navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Explorer and ENABLE "Turn off numerical sorting in Windows Explorer".

For Windows systems which don't have the Group Policy Editor (Home Premium, for example), you need to use the Registry Ediotor. Run regedit to create a new entry in the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer Name it "NoStrCmpLogical" use the type "REG_DWORD" and give it the value "1".

Is it worth considering restoring the old PMView literal sort order as an option beside the existing sorts which are numeric ("name" on the menu), extension, image size, image depth, image orientation, file size, date modified and date created? Perhaps I am the only PMView user who would find it useful, perhaps not, but I imagine that the code to do the traditional PMView literal sort already exists and could be reinstated.

(While I'm on the topic, or at least close to it, a random sort order would also be very, very useful, for reasons I have mentioned in an older post.)

Anyway, perhaps this information will be of use to some other users.

Hi Peter,

I'm not sure how much help you can be with this one, so I'll just outline it as (if nothing else) a little cautionary tale about progress in general.

I am a photographer with roughly a million files archived. (That's not as many as it sounds: there are various generations of differently post-processed files in there, so often multiple files for each picture.)

Every file is named for the date and time - a picture taken right now at 11:30.05am on 21 Jan 2013 - would start with 130121-113005, for example. Various suffixes to that base filename indicate different things. An extra digit indicates multiple shots in the same second (pro cameras do 10 frames in a second); an added letter indicates what post-processing has been performed, and so on. The details of this system are not important here, the point is that (until recently!) PMView always sorted all these files in correct chronological order, including post-processed copies in their correct place, and everything was easy to find.

Alas, with the new alpha-numeric sorting algorithm since .. er .. since PMView 3.68, the files are mis-sorted! Like no longer sits next to like!

Secondly, there are the ordered selections of pictures I use to illustrate lectures: they are all long since sorted into the order I'm going to want them in when I speak (simple brute-force renaming has always perfect for this). By reviewing the pictures for a particular talk, seeing them in order again, I can quickly refresh my memory of a talk I have not delivered for a few years, and (if desired) slot in a few new pictures to update it (once again getting them in the right places by brute-force renaming). Now, of course, all my talks are semi-randomised!

Obviously, you are not going to reverse the recent change to PMView's sorting method, nor should you! In broad, it's a sensible and useful update.

But now I'm looking at hundreds of thousands of carefully archived photographs and thinking about the massive task of renaming them all simply because PMView switched to a different sort order system. I could probably automate a fair bit of it, but it will still take ... I don't know ... a LOT of work!

The alternative would be to downgrade back to old versions of PMView - not a sensible long-term policy.

Anyway, I'm not sure that there is anything you can do here, but I thought I'd spell out some major unintended consequences of an apparently trivial update!

Very happy with PMView 3.61 overall. It has introduced a couple of new bugs, however, one moderate, the other very minor. These are both new since v 3.5x.

1: Custom key weirdness. (MODERATE) The key mappings are now much, much fussier than they used to be. SHIFT is the culprit. As an example, for years past I have had [SPACE] mapped to file/next and [ALT/SPACE] to file/previous and it has worked flawlessly. Now, if I happen to have shift lock on, nothing happens! The same occurs with the factory-mappped [PAGEUP] and [PAGEDOWN] keys.

Sure, I have now become used to it and know that, if PMView seems to have stopped responding to the keyboard, changing the shift state will probably fix it, but less experienced users will struggle with it. (Actually, they won't, they will just decide there is something wrong with the program and stop using it in favour of something that does what they expect.)


2: (MINOR) Default location for the file copy/move folder browser. Prior to 3.6x it defaulted to the top of the directory tree. Now (on the Windows version) it defaults to My Documents and requires an extra click to open the computer and get to the drives. (This is probably a design decision, not a bug. Still a pity though.)

Everything else works beautifully!

Thanks Peter! Works a treat.

Thanks Peter.

Hi Peter,

My quick scripts work normally in every way except that every time I run one, they duplicate! An example might make this clear:

The quick script menu before I run any quick scripts looks like this:

• A quick script
• Another script
• Third script
• --------------
• Edit

After I run the first script, I get this:

• A quick script
• Another script
• Third script
• --------------
• A quick script
• Another script
• Third script
• --------------
• Edit

Run another one and this is the result:

• A quick script
• Another script
• Third script
• --------------
• A quick script
• Another script
• Third script
• --------------
• A quick script
• Another script
• Third script
• --------------
• Edit

And so on forever. After a small batch of scripts, it scrolls off the page at top and bottom. They work just fine, and it doesn't matter which of the many duplivcte scripts I click on.



Background: I recently upgraded to a new machine and installed PMView 3.51 from scratch. Like the old machine it's a Thinkpad running Windows XP SP3. I have not run 3.51 before as there didn't seem to be any new features or bugfixes in 3.51 that applied to my usage so, on the "if it ain't broke" theory, the old machine used to run a slightly older version of PMView(3.3x maybe?).

The scripts themselves were copied over onto the new machine from the old one. Thinking that this might be the problem, I deleted all my scripts just now, restarted PMView, and hand-entered them from scratch. Same problem!

Can you help?

Thanks,

Tony

I'm still jotting down ideas to further improve the excellent PMView user interface here whenever I think of one. Hope it's helpful! Here is another little touch:

Mouse wheel on slider bars (e.g., the RGB adjustment bars, but lots of other examples)

To make small, accurate adjustments to the slider bars without needing the keyboard, use the mouse wheel. Scoll down for less, scroll up for more.

Another very small one:

Context: In the File/Open box, you can select which sort of files you want to list: ALL FILES, ALL TYPES, BMP, JPG, and so on. The two most-used selections, naturally, are ALL FILES and ALL TYPES. These are both at the top, then the individual types listed below in a scroll box. The first visible item in the scroll box is the currently selected type (unless you manually scroll up).

Suggested change: Make the first visible item 1 or 2 items above the currently selected item.

Benefit Saves the user scrolling every time to change to an earlier-listed type. (E.g., switch from ALL TYPES to ALL FILES with a single click instead of click-and-hold-and-scroll > click.)

Cost: None to speak of, you get the following 15 types (after the presently selected type) listed instead of the following 17 types.

Another little one while I think of it:

The move file create new folder confirmation box: this requires a yes/no answer with the Y or N key. For consistency with many other things in PMView, make the ESCAPE key do the same thing as the N key.

Thanks Peter! I'll look forward to PMView getting even better.

2. File formats.
Less is more! Most of us use only a handful of the many file formats PMView can read and write. In particular, how often do most users want to write a file in anything other than their three or four most-used formats? (Example: I mostly use TIFF or BMP for lossless intermediate saves while I'm working on an image with PMView, Photoshop and Neat Image, then JPG or PNG for the final images - practically never any of the others. I bet that most other users do much the same.) But every time you need to switch formats (e.g., save this particular image as a TIFF because you need to do something to it in Photoshop and you shouldn't use JPG for intermediate saves) you have to scroll through a great long list of possible image formats looking for the one you need. OK, it's only a few extra seconds, but seconds count - and the reason we all use PMView in the first place is because it is so fast and easy. Let's make it even faster and easier: add a way to take out the file formats we are not interested in and just show (e.g.) JPG, TIFF, and PNG. Naturally, this needs to be reversable so for that once-a-year time when you need to save an OS/2 icon or a Compuserve RLE you still can. (I thought of trying to hack the PMView executable to do this, but decided that was too hard! Would it be practicable to extract the save-as file format list to a text file that the advanced user could edit?)


3: Resize.
The transform/resize feature is one of PMView's great strengths. Fast,, simple, flexible. One of its best features is that it offers single-click selection of common formats (800 x 600, 1280 x 1024, for example) and yet still allows the user to type in any other size. But it too could be even better. Assume, for example, that the user wants to make screensavers or wallpaper and has a laptop with a 1400 x 1050 native resolution. Or that you are working on a website where the site-wide policy is to use illustrations that are 328px wide. (Good webmasters tend to insist on this sort of thing as it ends up producing a site that looks uniform and professional, and also allows much simpler HTML code.) If you do a lot of this sort of work - producing images to a particular format that doesn't happen to be exactly the same as one of the pre-set formats - you wind up doing a heap of typing in the same number, over and over and over. The solution (it seems to me) is to provide either two or three user-pre-set transform/size resolutions, or to have the existing "custom" resolution default to whatever the last custom resolution was - i.e., make it remember your last custom size transform.

But come to think of it, what if you are doing something where you are creating a set of images in two or three different custom sizes - e.g., where you are making 200px clickable thumbnails and 660px main images for a website? That's a pretty common sort of task, after all. Then the neat and simple second solution above still doesn't help. Answer: either a scrollable "history" window below the last pre-set resolution, or two or three extra buttons (in the same place) that contain the last custom resize resolutions.


4: File sorting.
Scenario: you have a large folder full of image files you need to sort through and categorise (typically, you want to delete some and just keep the best ones - photographers do this all the time, and it takes hours). So you flick through the images, deleting, moving, sorting stuff out. But after a few runs through, you start having difficulty making decisions: you've already seen these images and you've already deleted or moved the ones that stand out as obvious choices, so now you are doing the hard yards - sorting the images that you couldn't decide on right away. One thing that makes this harder still is that you keep seeing them in the same order each time. Always seeing the pictures in the same sequence makes it difficult to judge each one on its merits. If only you could mix them up, you would be able to see them afresh and make better decisions. But in PMView, the only way to do this is with a slideshow - and with a slideshow you can't delete or move things! Adding functions to the slideshows would work, but an easier and neater way to achieve the same or greater benefit would be to add a sort by: random to the FOC. (You can already sort by name, extension, image size, and 6 other criteria, none of which help a great deal for this task - a random sort would help a great deal.)

Hi all. Most of us probably already know how efficient and time-effective PMView is. In my view, it's simply the best there is. But it could be even better. Here are some small changes that could make it even faster and easier to use PMView for productive work. In no particular order:

1: Cropping.
1a: Users often need to crop to a particular exact size. Currently to do this a tedious series of steps is required: (a) select an approximate area; (b) toggle view/show/selection info; © scroll the selection counters up and down - always getting the direction wrong at first because they are rather non-intuitive - or type in the required numbers to get the size you need (even in you move the selection to the extreme top left to save the mental addition required to calculate which coordinate will produce the desired final image size, you still have to remember to subtract 1 because the selection starts at 0 - i.e., type in 1024 and 768 and you get an image that is 1025 x 769!)

In short, where resizing to a particular image dimension in PMView is fast and easy, cropping to a particular dimension is tedious, error-prone, and slow. How difficult would it be to add a more efficient cropping method? There are probably about 6 good ways to do this, but here is one: add a crop-to-size item to the transform menu. (Is it really a transform? Technically, maybe not, but if it sits right below the "size" entry on the transform menu and works exactly the same way as transform/size, it would be easy for users to find it and learn how to use it.

The sequence would work like this: use the menus to select "transform/crop to size", then select the desired size (e.g., 800 x 600). This tells PMView to create a selection rectangle of that size and place it anywhere (top left is as good as any - PMView has no way of knowing yet where you want the selection made, only how big to make it). Use the mouse to position the selection rectangle as desired, then crop in the normal way.

(But why would a user want to do this instead of cropping to a rough size and then transforming to the exact size? Two good reasons: first, sometimes the aspect ratio of the image is important (especially when the image is one of several equal-size images on a single page layout). Second, where the size difference between the source image (or desired area of the source image) and the target image is small, resizing introduces unacceptable loss of image quality - you can resize from 2000px to 800px and with a little sharpening get an excelllent result, but if your source image is (e.g.) 930px, resizing it to 800px impacts on the final quality in a very visable way.)

1b: An option to grey-out the non-selected area (the part you are going to throw away when you crop the image) so that it is easier to see what the cropped image will look like - i.e., similar to the way Photoshop does it. This should be an option as there are advantages and disadvantages to both. Perhaps the best way to do this would be add a "grey-out/don't grey-out toggle" to the bottom of the right mouse pop-up menu whenever you have an area selected. But even if it were only switchable from the main view/preferences menu, the ability to grey out the area you are going to crop away, and thus see what your cropped image will look like would be an excellent addition.