-
Notifications
You must be signed in to change notification settings - Fork 285
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
Synonyms #1325
Synonyms #1325
Conversation
Nice, all squished into one commit :) I've got my notes out, and you've fixed two out of the 3 bugs ;-) Here's the last straggler I had written down. I'll look for more as well :)
A few more things:
Sorry for the long list, lots of them are just me being pedantic and OTT ;-) |
Yeah, I got everything right on the first try, of course. ;-)
Nothing has changed from the other branch I shared. I suspect these problems went away when master and release were merged (which is why I was waiting for that to happen before submitting this).
Yeah, it refers to
I'd prefer to make it → instead of >. Forgot to go change that. It usually takes a relaunch (or a long wait) before the UI shows the right name. I was hoping one of your catalog UI refreshing changes would make it appear correctly right away, but it clearly hasn't. Not sure what the right thing to do is here. Leave the name alone and let users set it?
Well, don't do that. :-) I'm not sure how we could prevent it. There's no real way to tell a Synonym apart from any other proxy. We could add some metadata to each one I guess, but is it worth it?
Known problem. There are probably some messages in your console about it. I was thinking of making a change here that would allow it to eventually work, but I don't know what our eventual approach (to resolve #1277) is going to be. Actually, looking at that issue, I actually said "This has been a problem with triggers for a long time, and will soon be a problem for Synonyms." :-) Anyway, that's a larger issue. I'll comment over there.
True. I'll see if there's a way.
I thought I had. Must have gotten removed during some trial and error …except that I did it all in one commit, remember?
Can we prevent that? Should we?
Makes sense. No idea how to do it. :-) |
The new commits should fix everything but dragging out of the target picker. And I still can't get it to center over the button. The red and green lines shown here are the same, in other words. |
I've done the following:
|
another commit to fix selecting the right object. Note to self:
which one's the right one? Who knows ;-) |
Oh, and you probably want to see my commits. Sorry they're not as tidy as your 'one commit' ;-) |
...and finally one more commit to correctly update the listing in the Catalog prefs :) |
Looks good. Thanks! So we need two classes dedicated exclusively to that stupid target picker window? Annoying. Just a couple of small things I want to change and I'll push some more commits.
|
Did you not want it to zoom to the middle? Oh, I misunderstood. Just fiddle with my code in
Aah so is that why you were updating the name of the item only if it hadn't previously been set. It meant it was just never updating. What's the point of editing the catalog entry name anyway? What benefits does it have? I'd say that seeing the correct name (less confusing) is far more important than allowing people to update the name |
I wanted it to appear directly above the target in the info panel. I've got that working now thanks to your enormous head start. I would also like to match the color of the info panel, but the standard-issue light gray doesn't appear to be one of NSColor's presets, so I went with the colors from the prefs.
Well, mostly just because you've always been able to do it in the past. But given the difficulty of detecting a user defined name vs. an older preset, I think I'm going to agree with you and just force a nice name. :-) |
Just rebased against the latest |
Added that method to
|
All looks good. I've tweaked the target picker window a little further so it blends in better with the sidepanel, and keeps it's size relative to the sidebar size better. Feel free to cherry-pick or ignore. |
OK, more commits. |
Almost there, just noticed a funny thing:
|
To fix that ^, just add this to QSTargetPickerPanel.m -(void)resignMainWindow {
[self orderOut:nil];
} |
Fixed. Oh, and just use both sides to resolve the conflict. |
Oh yeah, there's one last thing (as always!). Once that's done, merge away into maser as you see fit! :) |
I thought of one more thing too. I'd like to have some idea where we're going with #1277 before finalizing this. In other words, I want to decide on a format for storing the target so, long term, we can create synonyms for things outside the catalog. |
These will appear to the user as "Synonyms". It's a way to assign an alternate name (and by extenstion, abbreviation) to an object.
* use → instead of > * only set the name if necessary info is available
Also: Move existing files to QSInterface
This will allow you to change the target without losing old mnemonics.
This will allow us to recreate a target that isn't in the catalog some day.
OK, rewrote history here to change the last commit from handler to type. And since I was rewriting history anyway, I rebased this against |
Not sure if you saw, but I fixed the deployment for the NIB. I want to have this merged in so I can include it in the proof-of-concept for recreating objects. |
Fine by me. I only left it unmerged because I wasn't sure if your change was enough for
On 31 January 2013 13:46, Rob McBroom notifications@github.com wrote:
|
Yes and no. It was part of it, but other changes were needed (just to make sure the type was propagated from the plist down to the place where it's needed). You'll see. |
This works great! Like the way the object field in Catalog Prefs acts like QS pane 1. |
It basically is the QS pane 1! Indeed Rob's done an awesome job :) On 10 February 2013 11:34, philostein notifications@github.com wrote:
|
I had help, but thanks. :-) |
Expansion idea: For folders, have the synonym work in pane 3 also. Dunno if it's possible seeing as they're really proxies. |
I knew that would be a limitation, but I think we need to fix the more general problem of allowing proxies in the third pane. (That will automatically take care of synonyms.) |
This is slightly off-topic, but thank you for this: the ability to 'rename' items is the single function that has been missing from my OSX experience. I even installed Alfred 2, thinking that this single feature would be the reason I switched. Happy to be proven wrong! |
It's something new users have asked about since I was a new user. I'm glad people find it useful. |
Here's an official implementation of a long sought-after feature. This allows users to give something an additional name. For example, you could:
Under the hood, these are proxy objects. While long-time Quicksilver users are familiar with that term, I chose to obscure the implementation details here because:
Note that I've altered some of the typical proxy object behavior to make synonyms act more like the thing they refer to. (Right-arrowing, for example.)
There might be some visual tweaks we want to make here and there, but as far as functionality goes, I don't know of any problems.