RE: [XaraXtreme-dev] Open file, get standard colours

["Gerry Iles" <GerryI@xxxxxxxx>]

It is perfectly legal for a Xar file to not have any named colours in
and the program should not crash when this is the case.  Any problems
that occur when there are no colours are bugs and need to be fixed.

The user may have deliberately created a default template document that
has no colours so the import should definitely not create a set of
default colours.  Loading of the default template to import into is the
only "correct" thing to do.

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of JLM
Sent: 28 June 2007 01:11
To: dev@xxxxxxxxxxxxxx
Subject: Re: [XaraXtreme-dev] Open file, get standard colours

Here are a number of points.

Let's suppose there is a means by which a filter plugin can communicate
it's need for a default document. It is possible for a plugin to state
that it does not need a default document, and yet not output any named
colours. In order to directly fix this problem it would need to be
understood by plugin writers (and documented) that if you do not request
a default document, then you must provide at least one named colour.
Additionally, a robust implementation of Xara should still check to see
if there are any named colours after loading the document, and either
cancel the load or do something else reasonable.

My second point is that maybe the problem is not directly with loading a
document with no colours, but with the rest of the system in assuming
that all documents have colours. If you open the colour gallery while
working on a document with no colours and click on "New...", Xara
crashes. Clearly this should not happen.

Thirdly, I noticed that after opening an SVG (SVGs do not load a default
document), the bitmap gallery shows the Xara default standard bitmap. So
this is an inconsistency. If no default document is loaded, and no
colours are created, then I would also expect no bitmaps either. Since
this is not the case, it would seem to validate my proposed solution of
creating default colours for documents that have none. Although maybe
the implementation should be different, since I do not see the default
bitmap being created in the same function as I am creating the colours.

Gerry Iles wrote:
> Yes, it sounds like your change is fine, at least for the time being.
> 
> As for the SVG filter, it sounds like the "plugin" filter mechanism
> could do with a way for the filter to specify if it needs a default
> document to import into when opening files.  This should probably be
> specified in the XML file that defines the filter, the PluginOILFilter
> class tweaked to read the setting from the XML and the
> PluginNativeFilter class override the IsDefaultDocRequired function to
> return the relevant setting.  This could easily default to the current
> FALSE value when the setting isn't present in the XML so existing
> filters would only need to change if they need a default document...
> 
> Gerry