fix action names in the interface

[skurfer]

Found a small problem, which is fortunate, because now I can make a pull request out of it.

But as I’m sure you know, the entire plug-in is new. I was hoping to have it out prior to 10.9, but that clearly didn’t happen.

After reading the review, I’m not sure how this will play with colored labels, but it should work anyway.

[pjrobertson]

Localisation...? ;-) Hehe

I'm a bit confused on the documentation with "plus every other tab belonging to these files"... do you mean"

If "file.txt" is tagged as "text" and "draft", then → into the "text" tag will show "file.txt" and the "draft" tag?
(OK reading on leads me to believe this is right - under searching - but I still think it's a bit confusing :/)
OK no - you give a pretty damn good example after that ;-)

It'd be nice to have an example though of where "tags in the 3rd pane" are used (I can guess for the "add tag..." action, but I don't see anywhere to see the actual actions (except the Actions prefs of course)

I think the xib should be changed so it's Xcode 4.6 compatible (change "Opens in:" in the file inspector - 1st tab)
Also I don't know what the silly warnings are with the xib, but unticking the "Use First Layout Width..." option for the text field makes them go away.

Oh and one final thing: maybe setting up alternate actions would be nice? :D

A couple of things relating to the actual plugin and how it works... :P

• It would be nice if the file tag icon was colour specific. Not a biggy though since I think it might be annoying to implement (seeing that review you linked to)
• If I do "File.txt ⇥ Add Tags... ⇥" The 3rd pane doesn't contain any of the default tags (Red, Green... etc). Only the new ones I've created
• That one above means that if I add say the "Red" tag to a file, I can't remove it using the "Remove Tags..." action (it doesn't show in the 3rd pane)
• If I try and add the same tag to a file (e.g. add the "Home" tag to a file which already has the "Home" tag set) it adds it twice. That's pretty funny that OS X is so hopeless at dealing with this. Surely it should be the tag system's job of not duplicating tags (Finder even shows the same tag twice in the icon. Stupid!) I guess we have to do a check...
• Remove Tags... doesn't seem to work with the comma trick. Maybe it's because

Sorry for being picky, and sorry it's taken me so long to review this :'(

[skurfer]

It'd be nice to have an example though of where "tags in the 3rd pane" are used (I can guess for the "add tag..." action, but I don't see anywhere to see the actual actions (except the Actions prefs of course)

True. I should list out the actions in the documentation.

I think the xib should be changed so it's Xcode 4.6 compatible

OK.

It would be nice if the file tag icon was color specific

Maybe some day.

If I do "File.txt ⇥ Add Tags... ⇥" The 3rd pane doesn't contain any of the default tags (Red, Green... etc). Only the new ones I've created

This is just the OpenMeta plug-in, modified slightly. It only shows tags that have been applied to one or more files. I’m not sure if “all possible tags” is stored anywhere, now that they’re official.

That one above means that if I add say the "Red" tag to a file, I can't remove it using the "Remove Tags..." action (it doesn't show in the 3rd pane)

True. If you add a tag via Finder, it won’t be in the third pane until the next catalog scan. However, if you add or remove tags using Quicksilver, that catalog entry will be updated immediately. Even if we solve the problem for “built in” tags, the user could create a new one outside Quicksilver at any time.

If I try and add the same tag to a file (e.g. add the "Home" tag to a file which already has the "Home" tag set) it adds it twice.

Hmmm. How are you doing that? The third pane won’t contain tags that a file already has. Of course you can use text-entry mode to manually duplicate it, but would you?

Remove Tags... doesn't seem to work with the comma trick.

I’ll look at that.

I think I also need to adjust the code to actually write the tags in a property list, the way Finder does. Things mostly seem to work, but this is bad…

% mdls some_file.txt
2013-10-30 08:56:53.592 mdls[12429:507] Metadata.framework [Error]: CFTypeRef copyObject(_MDPlistBytes *, int *, CFTypeRef *, const MDPlistBytesDeserializationCallbacks *, void *, CFAllocatorRef): Invalid plist bytes descriptor: 0x0000000088000010
2013-10-30 08:56:53.593 mdls[12429:507] Metadata.framework [Error]: CFTypeRef MDPlistBytesCopyPlistAtIndexWithCallbacksAndAllocator(CFAllocatorRef, MDPlistBytesRef, CFIndex, const MDPlistBytesDeserializationCallbacks *, void *): plist copy bad (line 1198); idx = 0; quadIdx = 144; ctx = 0x0

[pjrobertson]

Hmmm. How are you doing that? The third pane won’t contain tags that a file already has. Of course you can use text-entry mode to manually duplicate it, but would you?

Tags that already exist for a file are showing up in the 3rd pane.

File.txt (already has “Home” tag set) ⇥ Add Tags… ⇥ # Third pane options: [Home Tag, Work Tag, …]

OK, I did some debugging:
Debugger stopped at
QSFileTagginingAction.m:L128

(lldb) po allTagNames
{(
    home
)}
(lldb) po tagsInCommon
{(
    "Home\n5"
)}
(lldb) 

There’s your reason why. Seems like getting the tags from the file (ones added by Finder) is including the newline and colour, as mentioned in your Mavericks review. I guess if you update the property list stuff to do the same thing, and things are consistent across the board this’ll iron itself out.
(Just to reiterate. Reproduce:

• Add tag ‘Example’ with finder
• Try to ‘add tag’ with Quicksilver, you’ll see ‘Example’ in the 3rd pane
  )

As an Aside: I’m confused as to what the difference is between “Add Tags…” and “Set Tags…”?

And here's a nice image just to keep you happy ;-)

[skurfer]

I don’t want to do anything with the stupid colors at all, but it looks like they’ve left us no choice. Might not be that hard. I have at least found that changing or setting the color for a tag via Finder updates all the tags, including those written via Quicksilver.

[tiennou]

As an Aside: I’m confused as to what the difference is between “Add Tags…” and “Set Tags…”?

IIRC "Add Tags” appends new tags, while “Set Tags” clear the list before setting it.

[skurfer]

OK, that should be more reliable. It now deals mostly with the raw tag data (name+color) behind the scenes. Only if you type an existing tag by hand will this get screwed up.

We should probably remove labels from the File Attributes plug-in since they’re not part of the UI. Which makes me wonder, should this entire plug-in just be rolled into the File Attributes one? That would allow us to add tags and remove labels in one bundle. More work though.

[skurfer]

Hold off. There are some small things I knew would break, but I forgot to take care of them.

[skurfer]

OK, give that a look.

[skurfer]

We’re now using the official API for managing tags. Seems like a much better idea. We no longer have to manage color labels, and nothing goes wrong if you type an existing tag by hand in text-entry mode.

I don’t like that “clearing” all tags leaves behind an empty extended attribute for com.apple.metadata:_kMDItemUserTags, but Finder does the same thing, so I’m not going to code around it.

I’d like to customize the icon based on color, but don’t wait on that. Let’s get this out. (And I’ll repeat my earlier question: Should it just be merged into the File Attributes plug-in?)

[fly2never]

hi @skurfer , just ship this plugin, no need merged into File Attributes, Because this plugin can only run on 10.9, right? Maybe it's time to set up a new attribute for plugin's OS compatibility.

[skurfer]

no need merged into File Attributes, Because this plugin can only run on 10.9, right?

If we merged them, the File Attributes plug-in would then require 10.9. One reason to do this is that the File Attributes plug-in still allows you to set colored labels, while Finder no longer does. (I haven’t actually tried it to see what will happen.) So we should really release a 10.9 version of that plug-in anyway just to remove that potentially problematic feature.

[skurfer]

Obsolete. See quicksilver/elements.hfsattributes-qsplugin#3

I’ll remove this repo once that’s merged.