Totalfinder 1.5.29 update brings back true labels

Totalfinder 1.5.29 made my day, and week, bringing back the pre Mavericks labels. You should advertize it as such and not only in the release notes.


Yeah … it’s really great to see this almost back to normal!

A little tweak could be made to the height and roundness of the new rounded labels. For instance I think the selected item highlight already has the aesthetic proportions correct, and the right margin of the label color could be shifted slightly inward to hug the tag dot, as seen here:

I was excited until I discovered that the colorization only works on files and folders and not on shortcuts. Also does not work on Dropbox folders. Meh!

@Redpointrik Well, for me, colorations seems to be working on every file and folder, be it into Dropbox or others.

I am getting a very strange behavior. I can open one tab and display the Red Tag, and it looks fine, colorization is there. However, in my other tab, which shows a folder that contains the exact shortcut that is displayed on the left, it simply shows the red dot.

But now, Dropbox folders are working, and if I go to the original document or folder, tag that, then the shortcut is also tagged and colorized. A workaround I can live with!

@Redpointrik I would not know as I don’t use the tabs. But if you figured a way around this, good!

Actually I had to implement this feature independently for Icon, List and Column View modes (Cower Flow is the same as List View). It is perfectly possible that there are some other cases when Finder renders the items using different code path which I didn’t cover. I will investigate this and possibly fix it.

Any clues leading to exact pin-pointing of the problem are highly appreciated.

I found if you tag an alias but not the target, then you get only the dot for the alias.
If you tag the target and not the alias, then you get both the alias and the target colored.

(Symlinks cannot be tagged, tag options are greyed out. If you tag the target of a symlink you get the color on the symlink and the target. I think this is standard Finder.)

1 Like

I’m having strangeness with aliases as well. I’m finding that aliases show up with the color bar of the original file or folder, even if the alias isn’t tagged itself. If you tag the alias, you get the correctly colored dot but the label color stays as per the original file or folder.

In the screenshot above, Test 1 was tagged, then the alias was created. The new alias has the label color of the original even though it’s not tagged.

Test 2 had the alias created, then the original was tagged. The alias stayed unlabeled for a moment, then picked up the color of the original with no action on my part.

Test 3 had the alias created, then the original was tagged. When I tag the alias, the dot is applied correctly but the label color picks up the original color.

Thanks for your discoveries. I can confirm the problems with aliases. I’m going to look for solution.

Right now I’m using legacy system API to read label color of NSURL item, here is the code if you are curious:

This API seemed to work pretty well, except the problems you have discovered.

I will have to find some way how to hook into Finder’s internal tags sub-system and read last tag color directly, so it matches what Finder displays.

I have found the problem on my side. The API works well, I was using resolved symlink/alias paths instead of originals. This introduced the confusion.

This will be fixed in 1.5.33

1.5.33 is out:

I was curious about this too … works great now!