Rework Object Previews / PreviewProviders

[ilexp]

The aim of this issue has shifted away from a distinct editor module and towards a (DualityEditor) preview panel control, which is incorporated in the Object Inspector (plugin). See the first comment for more information.

Summary

Object previews are currently embedded directly into the Object Inspector. This leads to code duplication and needless limitations. Replace this concept with a new "Object Preview" editor module that simply displays a preview of the currently selected object(s).

Analysis

• With a custom (docking) editor module, previews can be adjusted by the user to fit any size, rather than being dependent on proprety editor sizes.
• It would be a lot easier for custom Resources to display a preview, since all that is needed is a custom PreviewProvider, which is a lot easier to write and more versatile, as it is also used by ContentRef<T> property editors, etc.
• A lot of custom PropertyEditor code could be removed or unified after implementing this.
  • TexturePreviewPropertyEditor / TextureContentPropertyEditor / TexturePropertyEditor
  • PixmapPreviewPropertyEditor / PixmapContentPropertyEditor / PixmapPropertyEditor
  • FontPreviewPropertyEditor / FontContentPropertyEditor / FontPropertyEditor
  • AudioDataPreviewPropertyEditor / AudioDataPropertyEditor
  • ImagePreviewPropertyEditor
• Releasing this package would also require releasing a new installer .zip package, since the list of default packages will have to be extended.
• Should multiple instances of an Object Preview module be allowed?
  • If yes, a selection coordination similar to the existing one in Object Inspector would be necessary.
  • If not, there will no longer be a convenient per-selection-group preview like currently in a multi-inspector situation.
  • Does this really add value? Questionable. Maybe limit to single-instance for now and extend later when needed.

[ilexp]

Issue:

• One downside of the Preview Module approach would be that it's always there and always takes away screen space - even if there is no preview.
• Also, the actual preview would be disconnected from the module where its data is displayed. This can be a bad thing usability-wise.

Potential Solution:

• As a solution - or at least intermediate change - the Object Inspector could be adjusted to have a resizable preview area Control at the bottom that is only displayed when a preview of the current selection is available.
• The code cleanup aspect of this issue would be preserved, as would some of its smaller usability aspects.
• As a neat side effect, no new .zip release and manual package install is necessary for this, since no new module is introduced.

[ilexp]

Issue:

• Some previews require user interaction, such as the multi-frame preview for Pixmaps and Textures that provide an atlas. Also, think of animated / animation previews, etc.

Approach A:

• In the long run, the PreviewProvider API should be extended to plugins can provide the means for interactive previews as well as static images and audio tracks. The exact shape of this has yet to be determined.
• Short term, the preview control can use hardcoded special cases for Pixmaps and Textures. They are the only two applications so far and the improvement of removing the nested PropertyEditor hacks outweighs this smaller special case.

Approach B:

• Split up the PreviewProvider API in two tiers:
  • PreviewControl is an actual WinForms Control that will be instantiated inside the PreviewArea control. It handles how a certain preview content is presented.
  • PreviewGenerator is an abstract API that will generate a preview output from input data. The type of that output is either generic or unspecified (object).
• Displaying an object preview is now done in multiple steps:
  1. Determine which preview generators are available for this kind of input object.
  2. Determine which preview controls are available for the available set of generated preview objects.
  3. Of the available preview controls, select the one with the highest priority.
  4. Activate the selected preview control. It will query any number and type of previews it requires.
• Since instantiating a control has quite an overhead, the PreviewArea root control should internally cache previously used PreviewControl instances.
• Previews can also be displayed outside a PreviewArea (PropertyEditors!), in which case the generator API is queried directly with an expected output type.

[ilexp]

Currently favoring approach B, making this a breaking change and candidate for the v3.0 milestone.