id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
19026	[PATCH] The imagery preferences code should be more generic	taylor.smock	team	"The imagery preferences should be generic. I pretty much copied the code into the MapWithAI plugin, since I'm improving support for third-party data sources, and it would be nice for the users to see where the source is located.

I'm going to work on refactoring the code for this particular use case (so I'm not duplicating code). I'm probably going to be moving ''most'' of the code to a class by the same name, but with `Source` instead of `Imagery`, and then recreate the original `Imagery` classes extending the `Source` class. This means that any plugins which directly reference the classes shouldn't need (too much) adaption. Where `Imagery`/`imagery` is used, I'm going to add a constructor that takes that as a variable. I don't know how this is going to affect the translations (I assume that `tr(""Modify list of {0} layers displayed in the {1} menu"", tr(""imagery""), tr(""Imagery"")` isn't going to be exactly the same as `""Modify list of imagery layers displayed in the Imagery menu""` -- I might just add an abstract method that gets the description).

Classes I will need to touch:
* `ImageryProvidersPanel`
* `ImageryLayerTableModel`
* `ImageryDefaultLayerTableModel`
* `ImageryLayerInfo`
* `ImageryInfo`
* `ImageryBounds` (I probably won't have to modify this class greatly -- I'll probably rename it to `SourceBounds`

A couple of enums will have to be modified to implement an interface (specifically `ImageryType` and `ImageryCategory`)."	enhancement	closed	normal	20.06	Core		fixed	imagery, plugin, preferences	michael2402 wiktorn