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

Label is never displayed #405

Closed
skurfer opened this issue Jun 30, 2011 · 5 comments
Closed

Label is never displayed #405

skurfer opened this issue Jun 30, 2011 · 5 comments
Assignees
Labels

Comments

@skurfer
Copy link
Member

@skurfer skurfer commented Jun 30, 2011

As far as I can tell, the label is being ignored. (This is the value set using [someObject setLabel:@“String Value”].)

I see only the name. Most of the time, the name and label are the same, but not always. If they deviate, there’s probably a good reason. The label should always be displayed, with the name as a fallback, but that doesn’t seem to be happening.

This wasn’t the case in B54, but since I just noticed it, I have no idea when it was introduced.

@HenningJ
Copy link
Contributor

@HenningJ HenningJ commented Jul 1, 2011

Actually, I like how it works right now.
The name is the thing that is displayed by default.
But your search string is also matched against the label. And if an object is selected because of a match between search string and label, the label is displayed in the main part of the interface (the first pane), but not in the result list.
If the object is selected because of a match between search string and name, the name is displayed.

I think that's pretty good, you just have to be aware of how it works when developing plugins. :-)

@skurfer
Copy link
Member Author

@skurfer skurfer commented Jul 6, 2011

I always wondered how the Address Book module allowed searching on both real name and nickname. That explains it.

But your search string is also matched against the label. And if an object is selected because of a match between search string and label, the label is displayed in the main part of the interface (the first pane), but not in the result list.

I like this feature too, but it’s currently backwards. Label should show by default. Name should also be searchable and appear when matched. Right now, all of my Address Book contacts are showing nicknames.

I think that's pretty good, you just have to be aware of how it works when developing plugins.

You’re going to have a hard time convincing me that Alcor didn’t know how it was supposed to work when he wrote the Address Book plug-in. ;)

@HenningJ
Copy link
Contributor

@HenningJ HenningJ commented Jul 6, 2011

I like this feature too, but it’s currently backwards. Label should show by default. Name
should also be searchable and appear when matched. Right now, all of my Address Book
contacts are showing nicknames.

I don't really care if the name or the label is displayed by default. We just have to be aware that for some plugins it would be better if we changed it (like the Address Book plugin), but for others it's better as it is right now (like the Mail.app plugin I've rewritten).

You’re going to have a hard time convincing me that Alcor didn’t know how it was
supposed to work when he wrote the Address Book plug-in. ;)

Oh, I'm not so sure. What makes you think that if we can't understand his code that he could? ;)
But then again, maybe it changed somewhere along the way.

@skurfer
Copy link
Member Author

@skurfer skurfer commented Jul 6, 2011

Like I said, it was definitely the reverse in B54, which is what I was using when I wrote the documentation.

http://projects.skurfer.com/QuicksilverPlug-inReference.mdown#label

That second paragraph needs to be adjusted, since you can apparently still search on the name.

@skurfer
Copy link
Member Author

@skurfer skurfer commented Jul 8, 2011

Here's some justification for my belief that the label should be primary. This method from QSObject.m is unchanged from the earliest code we have (which I assume is B54).

- (NSString *)displayName {
    if (![self label]) return [self name];
    return [self label];
}

Now, to figure out why it isn’t doing its job.

@ghost ghost assigned skurfer Jul 8, 2011
@skurfer skurfer closed this as completed in 05c7617 Jul 8, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants