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

obsolete plug-ins #764

Merged
merged 4 commits into from Apr 29, 2012
Merged

obsolete plug-ins #764

merged 4 commits into from Apr 29, 2012

Conversation

skurfer
Copy link
Member

@skurfer skurfer commented Mar 20, 2012

This allows a plug-in to identify one or more others as obsolete.

When such a plug-in is installed, the obsolete plug-ins will be removed. (Similar to the way plug-ins are removed when a new version appears.)

In addition, if a downloadable (but not currently installed) plug-in identifies one or more loaded plug-ins as obsolete, the downloadable plug-in will appear on the recommended list.

Besides the obvious application, there are some other potential uses.

  • We could “change” the bundle identifier for a plug-in in rare circumstances by providing a new one that makes the original obsolete. I say “rare” because this is not ideal. Users would not be notified of updates if the bundle ID were changed. They would have to see it listed under Recommended plug-ins.
  • We could remove problematic and/or known-to-be-useless plug-ins simply by adding a list of obsoletes to the Core Support plug-in.

We could potentially modify the update system to notify users of available plug-ins in addition to listing them as recommended, but that’s a separate project. :-)

Edit: As you’ll see below, I implemented the changes to the update system, so users can be notified of plug-ins that obsolete the ones they have. No need to check the Recommended list.

skurfer added 2 commits Mar 20, 2012
Plug-ins can now provide an array of bundle identifiers for obsolete
plug-ins under QSRequirements. Obsolete plug-ins will be removed.
@skurfer
Copy link
Member Author

@skurfer skurfer commented Mar 21, 2012

I’ve had a look at the update system and I don’t think it’ll be too hard to have Quicksilver replace installed plug-ins with newer ones that obsolete them. I should have the enhancement committed in a day or two, so hold off on looking at this.

* The list of obsolete plug-ins was changed from a set to a dictionary
to track which plug-in makes it obsolete. (Dictionary keys effectively
act like a set, so it still works.)
* Users will be alerted and asked to download a new plug-in if it makes
an installed plug-in obsolete. Plug-ins that will be replaced are also
identified.
* The list of updated plug-ins was changed to a set of IDs instead of
an array of full blown QSPlugIn objects.
@skurfer
Copy link
Member Author

@skurfer skurfer commented Mar 22, 2012

OK, now give it a try. To test the update portion, you need to fake out Quicksilver and make it think there’s a new plug-in on the web site that obsoletes an installed plug-in. You can do this by adding this to PlugIns.plist with a key of com.qsapp.Networking:

<key>CFBundleIdentifier</key>
<string>com.qsapp.Networking</string>
<key>CFBundleName</key>
<string>Networking</string>
<key>CFBundleVersion</key>
<string>5</string>
<key>QSModifiedDate</key>
<string>2012-01-29 01:01:03 +0000</string>
<key>QSRequirements</key>
<dict>
    <key>obsoletes</key>
    <array>
        <string>com.blacktree.Quicksilver.QSAirPortPlugIn</string>
        <string>com.blacktree.Quicksilver.QSNetworkLocationPlugIn</string>
    </array>
</dict>
<key>QSPlugIn</key>
<dict>
    <key>author</key>
    <string>Rob McBroom</string>
    <key>categories</key>
    <array>
        <string>System</string>
    </array>
    <key>description</key>
    <string>Manage wireless connections, locations, and get information</string>
    <key>icon</key>
    <string>GenericNetworkIcon</string>
    <key>recommended</key>
    <true/>
</dict>

With this change we’re no longer “married” to a plug-in’s bundle identifier forever. I’m not suggesting we start changing them just for kicks, but we will at least have the option now.

Also, I noticed QSPlugInManager never frees anything up with a dealloc method. As far as I know, there's only ever one instance of that class and it exists for the entire life of the application, so I guess we don't need to free the resources, but should we?

@skurfer
Copy link
Member Author

@skurfer skurfer commented Mar 28, 2012

Better yet, here’s a version with the fake entry already inserted.

http://dl.dropbox.com/u/2214419/Quicksilver/Catalog.plist

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Apr 25, 2012

Better yet, here’s a version with the fake entry already inserted.
http://dl.dropbox.com/u/2214419/Quicksilver/Catalog.plist

Should that be the catalog.plist or plugins.plist file?

Also, what does this do to the startup time?

@skurfer
Copy link
Member Author

@skurfer skurfer commented Apr 25, 2012

Should that be the catalog.plist or plugins.plist file?

PlugIns obviously. Sorry. I’ve since refreshed the list of plug-ins and removed the fake entry from mine, so you might have to insert the example above as I originally suggested. I can provide a new file if you want, but not for a couple of hours.

I also now wonder why I keep seeing alerts that the Networking plug-in wants to replace the other two. It must be checking all plug-ins, not just those that are installed. So I’ll look into that.

Also, what does this do to the startup time?

Shouldn’t do much of anything unless there are a lot of plug-ins to remove on one particular launch. Most of it should be operating on things that are in memory anyway.

@skurfer
Copy link
Member Author

@skurfer skurfer commented Apr 25, 2012

OK, I’ve added another commit that prevents the alert from showing up for uninstalled plug-ins.

Here’s a file you can test with: http://dl.dropbox.com/u/2214419/Quicksilver/PlugIns.plist

Install AirPort and/or Network Location and then check for updates with that plist loaded. Note that you can’t actually install the Networking plug-in from the alert because it hasn’t been posted yet. If you build and install it, the other two should be removed.

pjrobertson added a commit that referenced this issue Apr 29, 2012
@pjrobertson pjrobertson merged commit cc7ceb7 into quicksilver:master Apr 29, 2012
@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Apr 29, 2012

Merged

@skurfer
Copy link
Member Author

@skurfer skurfer commented Apr 30, 2012

Great. Once this makes it into a release (and has a build number assigned), I can add that to QSRequirements for the Networking plug-in. Actually, I guess current release + 1 will do the trick.

I’m assuming the on-line plug-ins system copies all of QSRequirements and we won’t need to tell it about this new key. Do you happen to know?

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Apr 30, 2012

I’m assuming the on-line plug-ins system copies all of QSRequirements and
we won’t need to tell it about this new key. Do you happen to know?

Yep, I think :)

On 30 April 2012 13:51, Rob McBroom <
reply@reply.github.com

wrote:

Great. Once this makes it into a release (and has a build number
assigned), I can add that to QSRequirements for the Networking plug-in.
Actually, I guess current release + 1 will do the trick.

I’m assuming the on-line plug-ins system copies all of QSRequirements and
we won’t need to tell it about this new key. Do you happen to know?


Reply to this email directly or view it on GitHub:
#764 (comment)

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