I just tried XnViewMP on the mac. Once I figure out how to get it in an appropriate mode, it worked pretty well, until I got it into some mode where it wont display any pictures. I assume that I somehow set a filter, and it is not obvious how to unset it.
The keybinding say that ctrl-5 sets a 5-star rating but that does not work. cmd-5 set that rating, but I would prefer ctrl-5.
Often times on Mac, cmd is equal to what is Ctrl on every other platform. You should be able to change the hotkeys in the preferences.
Thank you, Mica, for the RAwTherapee hotkeys. That is helpful.
One of the reasons I like XnView is the metadata management, I hve set up a complex tree of categories that’s very useful for bulk metadata operations.
[quote=“jpoet, post:16, topic:2297”]
…until I got it into some mode where it wont display any pictures. I assume that I somehow set a filter, and it is not obvious how to unset it…[/quote]
XnViewMP in linux keeps the settings in a folder ~/.config/xnviewmp/
Do not know the equivalent in a mac. Delete it and XnViewMP will revert to default values and make a new one. Sometimes need to do this for an update as well.
I have ended up using darktable even for the initial culling step. Partially because I have been ending up there to do final editing anyway. Partially because darktable expects XMP files to be named differently than any other program I have tried. This means that if I use another program to go through an rate the images, darktable does not pick up those ratings because it wants the xmp file to be named basename.ext.xmp, instead of basename.xmp. It would be really nice if darktable was compatible, there, with other programs.
I really want to like Rawtherapee, but it is just less intuitive to use.
FastRawViewer is on sale right now: http://www.fastrawviewer.com/ and it is nice enough to justify the reduced price. Unfortunately, they don’t have a Linux version. Also, since it uses the (seems be standard) naming of basename.xmp, darktable does not pick up the ratings made with it.
Thanks again, to everyone for their suggestions and tips.
I’d personally like other programs to use basename.ext.xmp, since often times I will produce a tif file that I’d like to put some notes in the xmp aboutprinting that partulicilar file; in this case, basename.xmp fails miserably, as I do not want my tif and raw file to share a sidecar file.
Geeqie has indicated that basename.xmp is how adobe does it, but I don’t find that to be a valid justification.
The basename.xmp is a really bad idea. I often shot jpeg and raw and then this simply doesn’t work with basename.xmp, for this use-case I need basename.ext.xmp.
And that’s why we don’t follow the specs in this regard but added the extension in there. 
Darktable does pickup most of the metadata on the basename.xmp on the initial import, but not afterwards. I have to handle this between XnView and darktable and solved it by creating my own bash scripts based on exiftool to sync metadata to and from darktable xmp files. I have this streamlined in my workflow, so it isn’t a big hassle, but would still love that XnView to handle xmp file names a bit better.
I never tried what I am about to propose, but what might be worth a shot is symlinking one XMP file to the other.
Uncharted territory, i like it! 
Works great for everything except color labels, Darktable doesn’t write the xmp:Label attribute.
I had thought about writing a script to do this… But that’s so many symlinks.
That’s because Xmp.Label is not meant for color labels. Quote from exiv2 docs:
A word or short phrase that identifies a document as a member of a user-defined collection. Used to organize documents in a file browser.
Nevertheless Darktable only writes the color labels to its own schema tags and, please correct me if I’m wrong, there’s no standard way to set the Color labels into xmp tags.
You are correct, there is no standard way to do this. Several sites suggest that applications just write the color into the xmp label tag, then display the color label according to the tag, but this introduces some interesting parsing and presentation problems. Oh, and localization problems too, is it “blue” and not “blau” for the tag?
I think I may opt to introduce a workflow taxonomy for tags in my workflow, as I’m finding there are not enough color labels for me anyway.
As @paperdigits said, there is indeed no standard for color labels, which is strange, given how widely used they are. But there is also no standard how they are used in the programs. Some like darktable can toggle any of them on/off at random while other programs can only have at most one label assigned at a time. So while it might make sense to support using xmp:Label for them it would require a lot of thinking and code under the hood.
Being a programmer myself I understand your worries, coding something into a piece of software that really isn’t standard (so it might not even be so useful as expected) is a huge risk for something that’s community driven. In the end that “lot of thinking” shouldn’t be needed if there was a well defined convention.
Bringing this a bit more on topic, I rely heavily the color labels, because I use more than one program in my workflow, and have switched my preferred RAW developer a couple of times in the last years, I have felt this lack of portability of color labels more than once. Right now I’m at the point where I’m considering the same that @paperdigits wrote and removing color labels completely from my workflow.
Color labels have another problem in addition to not having a standard representation. You have to carry a cross-reference in your head as to what color has what meaning. Instead of your image having a tag that says “I selected this image for Raw processing”, it has, say, a blue tag, and you need to mentally translate blue to “do some raw work on this image”, and remember that’s what it meant if you are away for a while.
Or…invest in some Post-It pads.
Yes, that could be a problem. Therefore, with red, yellow and green, I represent the status of editing, which is easy to remember and did not change over years. But what the other colours meant two years ago, I cannot remember.
For a long time I have a feature in mind to solve this problem, but never posted somewhere: What about adding meaning to the colours, that show up as a tooltip when you hover the colours. Ideally, the meaning would be stored in an invisible file (.colour_meaning or similar) in the root directory of your photo collection and could be overwritten by such files in deeper directories (e.g. the global meaning of purple is “not a good photo but necessary to tell the story”, but in a directory with shots to create a panorama, it could mark the shots selected for further processing). It could be further overwritten in pp3/xmp/whatever sidecar, if a special meaning is needed for a single file. In parallel, the last inherited meaning could be carried in the sidecar as well, to ease moving such pictures around. Just an idea …