[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

[XaraXtreme-dev] Errors finding SVGFilter

I /think/ I know what the root cause is of the problems finding

In xpoilfitl.cpp there are lines like this:

  wxString sCommand(m_CanImport);
  sCommand.Replace(_T("%IN%"), (LPCTSTR)FileName.GetPath());
  INT32 code = wxExecute(sCommand, saOutput, saErrors,


  wxString sCommand(m_PrepareExport);
  sCommand.Replace(_T("%OUT%"), (LPCTSTR)pPath->GetPath());
  sCommand.Replace(_T("%XML%"), m_XMLFile.GetFullPath());

  INT32 code = wxExecute(sCommand, saOutput, saErrors,

However, in each instance, sCommand does not appear to be
passed through binreloc in any way before it is used. This
means it is reliant on the filter being on the path
(as far as I can see), which is a bad plan not least
as any other random version of the filter from a previous
install may be on the path.

I really think we ought to be doing some form of binreloc
on these, or we risk running whatever version last got
put in /usr/bin, which is not a good plan. It binrelocs
the config directory successfully. I suspect this
is the root cause of the long thread re filters on

Now the problem with this is if the filter's xml file
actually deliberately specifies a path. Alternatively
if it doesn't come with Xtreme, so SHOULD be found in
/usr/bin (i.e. on the path).

So all in all I think the best solution is we look
for %BINDIR% on the path, and replace it with the binreloc'd
path to the filters. So if someone puts %BINDIR% in
the .xml file, it means "this file is right alongside
xaralx, wherever that may be". If someone doesn't
put "%BINDIR%" in, then we look along the path as
normal, i.e. we don't do a binreloc type operation.
Clearly SVGFilter should then have %BINDIR%
in the XML so it actually uses the version we ship,
rather than whatever randomly landed ahead of it in the

Note all this is confused by autopackage attempting
to modify the path, and not doing it properly (in
that it seems to require login and logout). This will
be fixed by the above, as well.