|
|
Obsolete Plugin CleanupIt would be excellent if there was a little utility app, independent of kinemecore probably (but this wouldn't be bad with kinemecore too), that would go and "cleanup" old plugins like structure tools, directory scanner blocking, spooky, gl tools during the alpha port function era, etc., that have been made obsolete by new plugins/have been lumped in with new plugins. Like, how Kinemecore checks for duplicate versions/older versions of a given plugin, or locations being in the wrong place. I realize that something like that would have to have a static list of some outdated plugins inside the app and patches that replace them, that would be maintained, and that this could get into a pain. Maybe this would be best as an opensource thing where people could update that list themselves. The purpose of it's being it's own utility app, script, or whatever, is so that someone wouldn't have to start up QC to do a "plugin management". The "problem" scenario, is that, if you're loading an app that uses patches like Structure Maker or Directory Scanner Blocking that have been gobbled up by other patches over the years (DataTools, FileTools), and the user has them double installed - like, they have Structure Maker AND DataTools installed, not only does QC have problems on start, but it's pretty darn hard to figure out a way to keep your own app from crashing on start, or not initializing, because of the duplicates. Maybe there's some eloquent way to handle this in the internals of an app, but I sure haven't found it - and I doubt there is in the case of duplicate plugins, when loading them from user, library, or system locations. I don't necessarily want to stop external loading of QCPatches altogether, but I guess that would be the alternative, to making it so the user doesn't have to jump through as many hoops. It just keeps them from using QCPatches installed on their system though (like QB does currently), which is sometimes not an advantage. |
Apart from the wealth of well maintained information upon Kineme Plugins by Kineme, there is a clear need here for a Wiki book to be setup and maintained, which could be commenced by collecting together all the versioning for Kineme's Plugins, with a separate page for other forum posters who are also Plugin authors, which information can also be added onto by those who are users of the 3rd Party Plugins. There would also need to be a separate page or section for Plugins from Apple, I'm thinking here of those great Developer examples. These pages could also have the facility to hold upload / download links for updated versions of either other author's Plugins and also for Apple Developer Plugins updated to be conformant with the concurrent version of QC. An application based upon that Wiki list would then be more feasible.
There def is a wiki page on obsolete plugins. At this point, it's just Kineme stuff, but it could make sense to list all other old stuff that is kicking around and just doesn't work anymore.
I'm thinking more of a utility app. It's not a super big deal... for the most part, if the plugin loading routines are right, and nothing crazy has been done with the plugin (hahaha), things work OK when stuff is double installed. It's just unpredictable which will load without some fancy footwork.
I was thinking that this might be easy to whip up, if a couple of assumptions are true (?).
I'm guessing that the mechanism that keeps KinemeCore from spamming other qtz based apps must be that it stops itself from loading in anything other than QuartzComposer app? I haven't tried to setup an app project to spoof it into opening in the menubar, but it seems like this may be the case.
If a pared down k-core plugin with something like "just the plugin management" routine could be loaded by an app's bundle (and maybe safemode, or other stuff that made sense), or a simple app was made that loaded that part of the kinemecore function and associated nib stuff that pushes that to a menubar, there could be a "plugin management" utility app made without much effort, as long as it loads the patch...
.... I think?
So, two related ideas -
2. Having the applicable parts of k-core load in a simple utility app, so people could do the plugin management without opening QC. This is good, b/c someone's install could be so screwed up that QC might not even start. This could fix the problems without requiring QC actually runs.
-and/or
2. Letting parts of k-core (or new variant) spam the menubar of people's custom apps if they load it, to do plugin management.
If I could help with either one, I'd be happy to as time allows (I'm sure you all are busy too).