6:42 p.m.
Hi!
I was testing 0.44pre1 build for Win32 and spotted that PyXML issues
with extensions (when having installed python seperately on windows)
have not yet been resolved.
I don't know if there is a way to hack around this (ideas: invoking
python with full path, changing PATH variable before execution,
installing PyXML on user's machine if not available) but at least there
should be a more informative message on what is going on.
The current message hardly clarifies anything: "The inkex.py module
requires PyXML. Please download the latest version from
<http://pyxml.sourceforge.net/>." Average-user questions: What is
inkex.py? What is a module? What is PyXML? Why is it required?
(Let alone the fact that this installer crashes during installation on
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.
- Spyros Blanas
8:27 p.m.
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 ===================
8:48 p.m.
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.
---
12:27 a.m.
Adib Taraben wrote:
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?
Kalimera! :-)
First of all, I am complaining about the PyXML installer, not the
inkscape one.
I am working as a non-admin, in a windows XP SP2 machine. The PyXML
installer detects automatically that PyXML should be installed into the
main python path c:\Python\Lib\site-packages\, doesn't bother asking me
for another directory, tries to open the file (which can't access) and
crashes.
The command-line command "python setup.py install
--prefix="c:\another\path\site-packages\" worked fine where the
user-friendly UI installer failed.
- Spyros Blanas
1:01 a.m.
On Wed, 31 May 2006, Bob Jamison wrote:
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?
Well, I can't really verify this, I do think putting this into script.cpp
so that it'll check the "locally installed" version before looking to the
system installed one is a good way to go. I suggested this earlier but
no one would tell me how to do that on Windows ;) It looks like this
would work for Perl and Ruby also, if we decide to ship those in the
future, is that true?
--Ted
3:34 a.m.
ted@...11... wrote:
Well, I can't really verify this, I do think putting this into
script.cpp so that it'll check the "locally installed" version before
looking to the system installed one is a good way to go. I suggested
this earlier but no one would tell me how to do that on Windows ;) It
looks like this would work for Perl and Ruby also, if we decide to
ship those in the future, is that true?
--Ted
I guess that makes sense. For all three interpreters, use the
version that
we supply, over the one specified in the path. So how about this order of
search?
1) Use the one specified in the prefs, (defaults to none)....
2) Use the location of inkscape.exe to hardcode the interpreter's
executable
relative to it. If it doesn't exist.....
3) Search the PATH (what is currently happening).
This will still allow the end user to specify which python.exe he wants,
especially
if he is designing a new Effect.
We still really ought to launch the local copy via C, but we're way
too close to the release for that.
Bob
7:42 a.m.
Bob Jamison wrote:
1) Use the one specified in the prefs, (defaults to none)....
2) Use the location of inkscape.exe to hardcode the interpreter's
executable
relative to it. If it doesn't exist.....
3) Search the PATH (what is currently happening).
This will still allow the end user to specify which python.exe he
wants, especially
if he is designing a new Effect.
I committed code to test in this order.
Interpreters we package with
Inkscape should be called python/python.exe, perl/perl.exe, ruby/ruby.exe,
etc.
This seems to work ok on Win32. Can people please test this on Linux,
to make sure that I didn't break anything? I rewrote some code away
from gchar*
to Glib::ustring, to better handle Unicode.
bob
8:57 a.m.
Bob Jamison wrote:
This seems to work ok on Win32. Can people please test this on
Linux,
to make sure that I didn't break anything?
Well, that was confusing. :-)
By 'this', I mean, can people just test the Perl and Python extensions on
Linux to make sure I didn't break them? Linux should not have changed
at all.
bob
10:34 a.m.
New subject: Summary of EPS import/export bugs
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
2:37 p.m.
On Wed, 2006-05-31 at 17:42 -0500, Bob Jamison wrote:
This seems to work ok on Win32. Can people please test this on
Linux,
to make sure that I didn't break anything? I rewrote some code away
from gchar*
to Glib::ustring, to better handle Unicode.
But, judging from the errors (I can't get a diff from SF right now)
you've change the interface that the script object is implementing. It
may work, but that is certainly bad form. I'm actually curious how it
works at all, must be some sort of overloading madness.
--Ted
5:18 p.m.
New subject: Summary of EPS import/export bugs
Many thanks. This is great work that helps the other tracker
maintainers a lot. Some of these can now probably be closed because
of duplicates.
ralf
You wrote
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.
6210
days inactive
6211
days old
inkscape-devel@lists.inkscape.org
10 comments
7 participants
participants (7)
-
unknown＠example.com -
Adib Taraben -
Bob Jamison -
Janet Hawtin -
Ralf Stephan -
Spyros Blanas -
Ted Gould