Plugin info #697
Plugin info #697
Conversation
* change the “Updated” date for plug-ins in the UI to prefer the local filesystem date * add new methods to return the filesystem date and the latest available on-line date independently
…ble version independently
* plug-in name is larger (Regular instead of Small) * byline is under the name * status is at the bottom
|
Unrelated to this pull request, but I just built QS for the first time on my system. And it started just fine. But it did not work. It took me a while to figure out that it didn't work because I did build the But now, on to your pull request...This is really great. Especially the thing about the dates. :-)
|
The instructions in the wiki mention that, but you probably don’t need them so I can see how you missed it. :-)
Wouldn’t be a bad idea. I can recognize the problem instantly now I’m so used to it, but it would be nice for newer devs.
I saw that too, but only with
It would, but I wonder how useful it would be in practice. The date shown for the latest version is fetched by the update system, isn’t it? So if an update was there, a pop-up already would have notified the user. Maybe it would be better to show three states: Update Available/Up to Date/Newer than the latest (as a few of mine are).
Clearer, but there’s not much width to work with. I could move the data below the label, but I want it to be easy to compare the two. I’ll try some different things.
Good idea. Same for description. I’ll add them.
I didn’t change it at all. I just moved it to what I thought was a less prominent spot. I suppose it doesn’t tell you much you don’t already know (and it’s not always right for plug-ins you can install without relaunch). But then it isn’t hurting anything, so I don’t know if we should get rid of it. |
Exactly. New devs and confused old ones like me. :-)
Oh, right. Makes sense.
I think there are two ways to retrieve the plugin list: 1. The update system with the "new stuff available" popup. 2. the little refresh button on the bottom of the l plugin list. I think when you use that, you don't get a popup. Or do you?
You're right, the data should be aligned, so you can compare them easily. Maybe you could put a headline or something above both display, "Versions" or something.
I know. I was suggesting you do change it. It doesn't add anything useful and might be a little confusing on first look. So remove it. Simplify. :-) |
|
Rather than commit and make you build, etc. when we don’t even know what we want, how about some images? Here are some samples from a reworked info panel. I didn’t remove “Status” yet.
I’m pretty sure you don’t.
And you just happen to be looking through the plug-ins list and opening the info panel during the week between the last pop-up and the next? :-) I thought of that, but it seems like a rare combination of circumstances. Not that I’m ruling it out.
OK, but now you’re talking about displaying things conditionally. I’m barely keeping my head above water in Interface Builder as it is. :-) Another thing I thought of was changing the appearance of the text, rather than adding more text. Maybe a red tint for out-of-date plug-ins or something. Maybe a tooltip to explain the color as well? But again, I wouldn’t know right off how to accomplish that. |
|
Oh, and any ideas on the tiny icons? It looks like the plug-in provides |
also changes the layout and makes the icon appear 32x32
Nice.
Well, actually I think you can't do that in IB itself. But rather in the controller class for the plugins pref pane. Maybe with
I was wondering about that, too. I assumed the plugins provided just a small icon. |
|
The icon had a setting called Scaling. I changed it from “Proportionally Down” to “Proportionally Up or Down”. Seems to have worked.
I’ll probably leave it. Someone might care and it’s not hurting anything.
Yeah, I only did that so you’d know why there was so much blank space if the description was null. But since I’ve added a null placeholder, that shouldn’t be an issue.
I would prefer that as well and that’s what I did at first, but how can we get a decent layout not knowing how many we need to display? |
Great. :-)
Can't you link the elements below to the one above, so they automatically move down when there are more lines?
Same as above: If there's a description, display it. If not, collapse the text field and move the ones below up. I'm sure it possible with IB (and even pretty easy) but I also don't know how to do it off the top of my hat. But I can look into it if you want me to. |
|
Looks good all of this. I'll merge and use it as my main QS for a bit to see what I think. I agree with all of Henning's suggestions about simplifying the window (No 'Up to Date' string and no 'status' part) I need to play with it first hand to comment though. |
|
If the 'status' section was removed, then the 'installed' part could be shown conditionally if the plugin is installed or not. I think the N/A is a bit strange. Yeah I know, it means learning more about IB... :P Do we need the time string for the Latest/Installed version sections? Can the plugin documentation window close if the sys preferences close? |
What about when you’re clicking from one plug-in to another (or going down the list with arrow keys)? Do you think it would be better if the information was in a consistent location?
Well, I like having it there, but now that you mention it, I can’t say that it absolutely needs to be there. Maybe it could be in a tooltip for the version or something? Maybe the same tooltip could also contain the status (and the status could be modified to let you know there’s a newer version). But really, if we have enough space to just display these things, why make them hard to discover?
That was the original plan, but the way it works by default (hiding if anything other than the prefs has focus) wasn’t too bad, so I left it. But yeah, it should probably be changed. Speaking of, do you think the And any idea how we could make ⌘I trigger the info button? Assigning it as a keystroke doesn’t work. I’m guessing the view it’s in isn’t part of the chain that gets the keystroke when a plug-in/trigger/catalog item is selected. |
…t exist the `removeItemAtPath:` method returns YES when the path is nil, masking the failure
… installed - fixes #705
* add "Disabled" (installed, but not loaded) * rename "Uninstalled" to "Not Installed", which is clearer and closer to the truth
|
More commits to address some things discussed here and on #705. |
|
A few small things:
|
|
I meant to add to the end of that: Sorry for being pedantic. All these changes are really, really good and are going to make plugin reading much easier/better. But it's always the case that once you get started, you never know when to stop... as per you saying:
:) |
Those aren’t new problems, but I guess I can look at them. :-)
It refers to the categories you see to the left of the list of plug-ins. (The ones you could edit before #644.)
Good idea. The menu item, too. Easy enough.
No documentation has ever suggested that this will work. Not sure how we can enforce it, other than to let developers know when they do it.
Oh, the time. For some reason, I thought you wanted to remove the time and date that appear next to the version. You’re right. It’s distracting noise. I don’t even think they use the same time zone (for me anyway). |
How did I miss that! I like what you've done :)
Yep. We can leave it as is but ask Eric to remove it in a future plugin update.
Sorry, I should have been clearer. Glad you agree though :) |
Why display the file size at all? Is that really useful for anyone? I know, it used to be there before this. But maybe you should remove it.
I agree, HTML shouldn't be allowed there. But for now, you can just strip it out before displaying the description.
Totally agree. :-) |
* return right away if there's an error * remove the file size for loaded plug-ins * move things around to make it easier to understand (without altering the result)
…he pane loads Previously, you would see all plug-ins no matter what the initial selection was.
|
More commits.
I looked at this a bit, but I’m not sure what the solution is. The label is bound to the value returned by the
I looked into that. If there were a built-in method for NSString that did that (or one in the existing extensions) I’d probably use it, but there isn’t. So it seems like a lot of code to work around (rare) developer mistakes for this one value. |
|
Yum yum yum. How did users ever use Quicksilver without these changes in place? My god it must have been difficult to use!
I think you can solve this with KVO
Aye. I'll just inform Eric that HTML shouldn't be in the description. |
|
Yes. This is really nice. :-)
You're right. I thought as well that there was some easy method to do that. But if there isn't, it's all right to just leave it. |
I’ve done it recently …following an example in a book. :-) I don’t remember it all off the top of my head, but I can look into it. |
|
OK, I think this is ready now. Give it a final test. The KVO business with |
|
Looks great. One teeny thing. Should the '?' toggle the documentation window? so if I double click it it'll open/close the window? ... :) |
Eh, I don’t think so. :-) |
|
No? OK then! |
It started innocently enough with some tweaks to the stylesheet used for displaying the extended description. “What a stupid thing to be spending time on”, I thought. Then it exploded.
A summary of changes:
pre,code, andtable. The weird treatment ofh3was removed. (The iTunes and Remote Hosts plug-ins are some that showcase the changes well.)?button on the info panel now works (and performs the same function as the Plug-In Help menu item).As with anything visual, I expect people to have different opinions on what works best, so I’m open to suggestions and expect I’ll need to tweak things here and there.