Spyros Blanas wrote:

my machine and required installation via the command-line)

Remember, this is a *release* and there will be plenty non-programmers using it. And I think that such an error will prevent many people from enjoying the work done on extensions.

Exactly, which is why any last-minute fix must work perfectly. The only absolutely safe way is to disable Effects. I would appreciate any help on how to do this safely and effectively otherwise.

However, there might be a trick that people are ignoring. If you look at the code in script.cpp, you can see that the "interpreter" property of a .inx is processed thusly (here it is 'interpretstr'). We are getting a value for "insertText ".

1. Say it is "python". It is looked up in the table, and given the defaultval of "python" 2. The value for "python-interpreter" is looked up in the "extension" section of the prefs file. 3. If not found, and Win32, we try to search the PATH.

With a utility method in src/registrytool.cpp, we can get the path for inkscape.exe, and hardcode our python.exe's path into this method. However, look at 2. We are not using that at all!

Wouldn't this be a safer fix for this release, to just make sure that Win32 guys have their prefs set up to look for python? Just pre-can the entry.

If this doesn't seem to work out right, I will go ahead and use 3.

Could someone check this out, before I break anything?

bob

================ SNIP ===================

struct interpreter_t { gchar * identity; gchar * prefstring; gchar * defaultval; }; const interpreter_t interpreterlst[] = { {"perl", "perl-interpreter", "perl"}, {"python", "python-interpreter", "python"}, {"ruby", "ruby-interpreter", "ruby"}, {"shell", "shell-interpreter", "sh"} }; /* Change count below if you change structure */ for (unsigned int i = 0; i < 4; i++) { if (!strcmp(interpretstr, interpreterlst[i].identity)) { const gchar * insertText = interpreterlst[i].defaultval; if (prefs_get_string_attribute("extensions", interpreterlst[i].prefstring) != NULL) insertText = prefs_get_string_attribute("extensions", interpreterlst[i].prefstring); #ifdef _WIN32 else { char szExePath[MAX_PATH]; char szCurrentDir[MAX_PATH];

GetCurrentDirectory(sizeof(szCurrentDir), szCurrentDir); if (reinterpret_cast<unsigned>(FindExecutable(command_text, szCurrentDir, szExePath)) > 32) insertText = szExePath; } #endif

================ SNIP ===================

Spyros Blanas schrieb:

Hi! ...

(Let alone the fact that this installer crashes during installation on my machine and required installation via the command-line)

Kalimera Spyros,

pls can you explain mor detail about that. I have no problem running the installer I have WinXP SP2

What dialogs had the installer passed already? Are you trying to work as non-admin? What is your OS?

Remember, this is a *release* and there will be plenty non-programmers using it. And I think that such an error will prevent many people from enjoying the work done on extensions.

• Spyros Blanas

Thanks,

Adib. ---

Ive noted single groups onto the oldest bugs in each set in case there is overlap. Posting the full list to the mail list as an overview.

opening

1114254 cannot open/import eps files 1180226 Can't open .eps file

overall export issues

1027699 imported EPS files are scaled to 80% 1378123 EPS export: BoundingBox crops image (rounding issue?) 1273753 Exporting EPS creates a too-wide picture

component issues

1170322 Clippath does not work in PS export 1208874 pattern fills do not export to ps or eps 1234678 PNG transparency lost after EPS->PDF export 1305178 export to eps problem with symbol and xrefs 1404903 Resizing an image and saving in eps format malbehaves 1423023 Exporting as EPS or PS with refected gradients doesn't work

dialogs

1237867 EPS export options issues

text in eps

1222689 EPS export of non-ASCII text 1333035 EPS import: text items are corrupted