[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
[XaraXtreme-dev] Filter IDs
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Wed, 19 Jul 2006 11:16:56 +0100
- Subject: [XaraXtreme-dev] Filter IDs
[previously sent in error just to Phil]
Phil,
> I would guess I'm registering a filter for something best done
> internally. I think the main problem is "save as" seems to
> want to use ImageMagick. Who knows why. I will investigate.
Euurghh! I've found out why this is but I'm not sure how to fix it.
It was previously only working by accident as there weren't enough
filters to trip it up.
The Camelot native export code is trying to do a preview. To do
this, it looks through the list of filters trying to find one
with (say) FILTERTYPE_PREVIEW_GIF. These are defined in filters.h
using a #define, not an enum.
The filter types themselves (when registering the filters) seem
to be defined in filter_types.h.
Unless the enum and the #define values magically coincide, it will
use the wrong filter. In LX we have disabled various types of
filter (possibly including the GIF preview filter), so the #define
"went off the end of" the enum. Now I've added more filter types,
they overlap.
I think it would be a good idea to define filter types in only
one place, and only via one route or the other (not both).
Are filter types ever saved on disk anywhere? IE do the numeric
ID's need to be persistent between sessions? If not, then we
can just bin the whole lot and do _R(FILTERTYPE_PREVIEW_GIF)
instead (you can think of _R() as a macro which will always
return the same value unique whenever in that session passed with the
same parameter), which will have the advantage that we do not need
to alter ANY header when adding another filter, and that if we
have an extensible plugin filter system, there will be a way
of assigning them a unique dynamic ID - this is a trivial
patch to do, but means filter types will be dynamic between
sessions.
Thoughts? I can go either of these routes.
Alex