[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Re: Filter IDs (was Re: FW: [Bug 1294] New: Problems with "save as" in version 1475)
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Wed, 19 Jul 2006 13:05:09 +0100
- Subject: Re: [XaraXtreme-dev] Re: Filter IDs (was Re: FW: [Bug 1294] New: Problems with "save as" in version 1475)
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.
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
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
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?