Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More Type Changes #1779

Merged
merged 6 commits into from Feb 28, 2014
Merged

More Type Changes #1779

merged 6 commits into from Feb 28, 2014

Conversation

skurfer
Copy link
Member

@skurfer skurfer commented Feb 13, 2014

Following from #1740

While looking at another issue, I ran across some places where it looked like the pasteboard types and QS types were still assumed to be the same thing.

If it looked like a type for the pasteboard or drag & drop, I left it alone. If it dealt with keys in QSObject data dictionary, I changed it.

Other small things:

  • use string value in the Type Text action
  • use display name in the descriptive string for commands
  • if no actions are found, log the object we were checking, not the list of all actions

skurfer added 2 commits Feb 13, 2014
Allows it to work with contact phone numbers, and many other types.
@skurfer
Copy link
Member Author

@skurfer skurfer commented Feb 13, 2014

There was one other place in QSGlobalSelectionProvider that needs fixing, but it conflicted with the Finder proxy branch, so I took it out and rebased this. That instance is already fixed over there.

@skurfer
Copy link
Member Author

@skurfer skurfer commented Feb 23, 2014

Added another commit to address #1777. I think * deserves to be a special case. (Maybe an empty string should be too? I saw some actions being added for the type "").

In the end, this should probably return the UTI public.item, but I don’t know if we’re quite there yet. We’d probably have to do something similar to what we did for files and text. That is, convert * to public.item when reading in property lists.

pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented on 351c87a Feb 28, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see this is where things get horrible. The 'old' way of doing pasteboard stuff (which we're still using) uses the NSStringPboardType things. The 'new' way (which I was trying to convert to) uses UTIs exclusively (trying to use a non-UTI (a.k.a. NSStringPboardType breaks things)

I'm not sure what the repercussions of using a UTI with the 'old' way is, but if it works, then it's a step in the right direction. I'll take a look

pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented on 351c87a Feb 28, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, this will all be irrelevant when I get my fancy 10.6+ pasteboard stuff out. Since initWithPasteboard... a few lines above is using QSTextType then you've done the right thing here :)

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 28, 2014

Looks fine by me. Will run with it for a bit

@skurfer
Copy link
Member Author

@skurfer skurfer commented Feb 28, 2014

I think this will conflict with your fixes in QSObject_Pasteboard.m, but it’s easy to fix. (Just take the changes from the other branch.)

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 28, 2014

yeah, I've just merged everything into one nice branch, along with my 10.6+ pasteboard stuff (so all this is obsolete now) and I saw that one. Only a minor thing on NSStringPboardType

Conflicts:
	Quicksilver/Code-QuickStepCore/QSObject_Pasteboard.m
skurfer added a commit that referenced this issue Feb 28, 2014
@skurfer skurfer merged commit f1f6949 into master Feb 28, 2014
1 check passed
@skurfer skurfer deleted the moretypes branch Feb 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants