Re: [XaraXtreme-dev] Re: Filter IDs (was Re: FW: [Bug 1294] New: Problems with "save as" in version 1475)

[Alex Bligh <alex@xxxxxxxxxxx>]

Gerry,

Gerry Iles wrote:
> As you have discovered, the filter id defines and the enum in
> filter_types.h are not supposed to match.  The filter_types.h file was
> created during the port to define symbols that were defined in a file
> supplied with a non-GPL-able library.  There is currently no dynamic
> filter type system.

OK. The name "FilterID" at the top of the enum in filter_types
is thus rather confusing!

> At present, this causes a bug in this area in Xtreme.  The import and
> export dialogs in Xtreme do not remember a plugin filter across runs of
> the program.  When you restart it they go back to the native Xar format.
> This is because the PluginNativeFilter class doesn't actually do
> anything about the filter id so it uses FILTERID_NATIVE set by the base
> class.  During one run of the program, the filter type is remembered
> directly by the import or export dialog.
>
> In LX, somehow the plugin filter is remembered across runs of the
> program but I don't currently understand how.  Presumably the dialog is
> already saving its preferences in a different way.

Yes.

> I think the only sensible course is to change our filter ids from
> integers to a string.  Then we would be saving a unique string in the
> preferences.  It would be a little slower to look up filter by id but I
> think we can live with that given the number of filters.

We could use a hash if it becomes even slightly time-consuming.

> The system could be changed to not use a simple base class member
> variable e.g. a Filter class virtual BOOL IsThisFilter(const String_256&
> FilterID) would give us the ability for a filter class to have more than
> one ID though we would then need to also parameterise lots of the other
> filter functions (e.g. the ones that return the display name and file
> type strings and the actual import and export processes) so that a
> single Filter-derived class could more easily implement multiple
> different filters.

That sounds fine.

In the mean time I have redone the ImageMagick stuff so its filter
IDs are defined by a range in filters.h, and a single enum entry
in filter_types.h (I hope that's OK). That seems to cope provided
that the bitmap preferences can be distinguished solely by use
of virtual functions for ImageMagick filters - that's the idea
anyway.

This solves the immediate problem I think, but doesn't change points
you make above.

> BTW: The export hint uses its own enum to store the filter type.  Only
> some filters cause an export hint to be saved (jpeg, gif and png) as
> this was added specifically for when files are rendered from templates
> (e.g. in Webstyle and online stuff).

I'm not sure what an export hint is, but the PNG filter was using the
filter_types enum to store transparency and interlace settings.
Is that what you mean?

Alex