Fixes for details #1151

Closed
wants to merge 8 commits into from

2 participants

@skurfer
Quicksilver OS X member

This takes care of the problems described by #1148 as well as some other small things.

The first couple of commits arose from the question “Why is details being called so many times?” and had nothing to do with the original issue. The rest were about getting the correct details to show up in the correct places.

One thing I’m still seeing, but haven’t investigated: The details for actions aren’t returned from the cache in a lot of cases. I’m wondering if this could be by design. Are there situations where the action’s details can change based on the direct/indirect objects?

@skurfer
Quicksilver OS X member

Something to keep an eye on before you merge this: I've started to see intermittent freezing as soon as I invoke QS. It'll display, then sit unresponsive for a few seconds. It might be more likely if the last thing selected was a Web Search or with a Web Search in the 3rd pane, but that's not certain. If anything, these changes should make it more responsive so I don't think this is the cause, but I first noticed the problem right after, so…

@skurfer
Quicksilver OS X member

On the mystery freezes, I've also noticed that the action's icon is faded (and it's the default gear, even when it shouldn't be), so it's almost certainly something with the icon loading branch.

As mentioned on IRC, the whole process of "displaying" the object is repeated when you dismiss QS:

Dismiss QS Trace

My first thought was that the animation needed to redraw everything first, but disabling "superfluous effects" doesn't seem to make a difference.

skurfer added some commits Oct 2, 2012
@skurfer skurfer remove a redundant(?) call to `display`
This was getting called immediately after `makeKeyAndOrderFront:`, causing a lot of code to be run twice. The documentation says it generally shouldn't be necessary and I don't see any difference without it.
8f8e224
@skurfer skurfer remove a delay in processing keystrokes
The call to `nextEventMatchingMask:` seemed to be "replaying" the event, causing a lot of code to be run again.
d3f7485
@skurfer skurfer show details for the currently selected item in the results gutter
The details were being appended to the `status` string *before* figuring out which result was currently selected.
15808ef
@skurfer skurfer return the computed details the first time
Previously, the `details` method would need to be invoked *twice* to yield the correct result. (The first invocation would cache the details, and the second would return it from the cache.)

close #1148
c2042aa
@skurfer skurfer always show details if the current interface supports them
Whether or not the details can fit in the results list has nothing to do with whether or not they can fit in the main interface. In the context of the results list, the details string is already being handled appropriately by `QSResultController`.
b0a31c1
@skurfer skurfer rearrange things to avoid some unnecessary tests and assignments f0745ab
@skurfer skurfer Truncate details using NSLineBreakByTruncatingMiddle
reproduces work done by @pjroberston - fixes #525
e28c55d
@skurfer
Quicksilver OS X member

I had to commit evil and rebase this. The changes to Bezel conflict with the new Bezel that's been merged to master. Conflicts in a NIB are basically impossible to deal with, so I started over.

@pjrobertson
Quicksilver OS X member

Where are all my lovely comments?! 😒

P.S. GH supports fancy smilies now if you're MSN messenger inclined... just type a colon ':' to see the list

@skurfer skurfer only check primary type if no details were found
I think this was meant to be a fallback value, but since primaryType is *always* a string, it was returning the fallback the first time this method was run. After that, the cached value would be returned.
b68fc4b
@skurfer
Quicksilver OS X member

Found (and fixed) another small bug while messing with the Contacts plug-in. This should be ready now.

@skurfer
Quicksilver OS X member

All of these changes are included in #1163 now.

@skurfer skurfer closed this Oct 26, 2012
@pjrobertson
Quicksilver OS X member

@skurfer
I think the reasoning behind doing this was so that when the line height is < 34, the details aren't shown at all in the results list.

If you change the results list height to say 26 you'll notice that the details still show, even though they're half chopped off. But for some reason this happens in ß70 so I don't think it was something you added. Still something we should fix.

Also - BezelHUD never shows details in the results list (no matter what the line height) so really details should always show in the gutter, not just when lineHeight < 34... but this is an anomaly which I don't think we should bother working around

Quicksilver OS X member

I think the reasoning behind doing this was so that when the line height is < 34, the details aren't shown at all in the results list.

But this isn't the results list, so it shouldn't be checked here.

If you change the results list height to say 26 you'll notice that the details still show, even though they're half chopped off.

What the…? I've never seen that with any version, and I played with the setting a lot when working on this. But it definitely happens. Anyway, that's a bug in the results list, not here.

Quicksilver OS X member
Quicksilver OS X member

The results list uses QSObjectCells to display the object

Oh, well that explains a lot. I'll look into it.

@pjrobertson
Quicksilver OS X member

Seems a bit strange. In what situations will -(NSString *)details get called when the details haven't been set?

Surely we should try and pinpoint the method where the details are actually set, and just call it in this method

if(!details) {
     details = [self someMethodThatWillEventuallySetTheDetails];
}

Also: I know it's not your doing, but the comment on line 402 bugs me a bit :)
Can we somehow use the handler (it's a class, right?) to get the actual bundle?
Or better still, edit the - (NSBundle *)bundle in QSBasicObject.m to get the object's handler, then from that the bundle.

I'm just thinking... it'd make localisation nicer :D

Quicksilver OS X member

Was this comment meant for c2042aa maybe? Because the class will always be a string, like I said.

Seems a bit strange. In what situations will -(NSString *)details get called when the details haven't been set?

Well, in general, this method gets called any time an object needs to be displayed to the user. There's no telling whether or not details have been set at that point, but it gets tested inside this method.

Surely we should try and pinpoint the method where the details are actually set, and just call it in this method

There are two places details typically get set that I know of:

  1. Inside objectsForEntry and/or loadChildrenForObject in various plug-ins
  2. By calling detailsOfObject on the handler for the object type

We don't want to mess with the first way, and this is the method that takes care of the second. However the details are determined, they get cached and this method just returns the cached value in most cases.

Although, now that I think about it, if a plug-in went to the trouble to implement detailsOfObject, it probably shouldn't be cached. Otherwise, why not just set it up front for all objects? For example, playlist details show the number of items. Without testing it, I'm guessing that number never changes once we set it.

So I think I'll change this to not cache details in that case, though I'm concerned about the way this method gets called rapid-fire sometimes.

Also: I know it's not your doing, but the comment on line 402 bugs me a bit :)

Yes and no. I put in the comment and the test, but only because details were always getting set to nil without it. If you can figure out what it was supposed to do, feel free to get it working. :-) Maybe wait though because I might be changing this method around a lot to avoid caching "dynamic" details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment