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

["Gerry Iles" <GerryI@xxxxxxxx>]

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.

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.

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.

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).

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 19 July 2006 12:12
To: dev@xxxxxxxxxxxxxx
Cc: Alex Bligh
Subject: Re: [XaraXtreme-dev] Re: Filter IDs (was Re: FW: [Bug 1294]
New: Problems with "save as" in version 1475)

Gerry Iles wrote:
> Indeed.  This would actually be preferable as it also needs to
remember
> plugin filters and they may be uninstalled between runs of the
program.
> At least if the name is stored we can default to a sensible choice
(e.g.
> the default) if the relevant filter doesn't actually exist rather than
> some random filter (presumably the next one in the list).
> 
> We do store some filter related things in the Xar data (export hint
> record, export options for slicing, etc).  I don't think these store
the
> internal filter ID but there is a chance they might.

Well if we do, they are (I think) broken for plug-in filters anyway,
yes?

Given the plug-in filters effectively mean we /already/ have dynamic
filter ID's, it sounds like we already have a dynamic system.

How are you assigning filter IDs in the plug-in filter system, Gerry?
I'll need that to change (I can provide a Filter::GetUniqueFilterID()
call or something, or they can just to CamResource::GetResourceID on
the filter name).

Alex