Sun 23 Mar 2008 06:32:17 PM UTC, comment #14:
Fixed. I grabbed the wrong CVS branch by mistake. Everything appears to be working correctly now.
|
Sun 23 Mar 2008 04:56:06 PM UTC, comment #13:
Weird, is HAVE_G_URI_UNESCAPE_STRING defined in gchempaint-config.h? Did you run autogen.sh before configure?
|
Sun 23 Mar 2008 04:49:44 PM UTC, comment #12:
No change - it still halts at the same point, with a new complete CVS download.
|
Sun 23 Mar 2008 03:31:39 PM UTC, comment #11:
I updated the cvs gchempaint-0-8 branch with a local copy of g_uri_unescape_string. Please test.
|
Sun 23 Mar 2008 02:32:55 PM UTC, comment #10:
That would appear to be the problem - I do still have 2.14. The 8.04 Ubuntu release has 2.16, so I'll have it in a month - which really is soon enough for me, it's not that big a deal in the meantime to just relocate my files when I'm working with them. Or I could consider this yet another reason to move to Debian Sid.... after I get my current round of grant applications out.
|
Sun 23 Mar 2008 02:26:25 PM UTC, comment #9:
Damn'd, you are right, these functions are new in glib-2.16, do you still have 2.14? Seems I must check if it exist in configure and then use a local copy if not (if possible).
|
Sun 23 Mar 2008 02:20:31 PM UTC, comment #8:
You are correct - I thought I'd already applied the earlier patch, but evidently lost in somewhere along the line. However, using either a fully patch 0.8.7 or the CVS, I still get the following error:
application.cc: In member function ‘void gcpApplication::OpenWithBabel(const std::string&, const gchar, gcpDocument)’:
application.cc:589: error: ‘g_uri_unescape_string’ was not declared in this scope
application.cc:685: error: ‘g_uri_unescape_string’ was not declared in this scope
application.cc: In member function ‘void gcpApplication::OpenGcp(const std::string&, gcpDocument*)’:
application.cc:803: error: ‘g_uri_unescape_string’ was not declared in this scope
make[2]: *** [application.lo] Error 1
make[2]: Leaving directory `/home/terry/Desktop/gchempaint/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/terry/Desktop/gchempaint'
make: *** [all] Error 2
I'm not sure if this is related to your HEAD comment or not - I can only see one branch in CVS. If it's relevant, I'm using 0.8.7 GChemUtils.
|
Sun 23 Mar 2008 02:05:55 PM UTC, comment #7:
I missed an important detail: cvs branch you must use is gchempaint-0-8. HEAD is not maintained as the code has been moved to GChemUtils.
|
Sun 23 Mar 2008 02:04:18 PM UTC, comment #6:
Hmm, I applied both patches to cvs, so it should at least compile.
|
Sun 23 Mar 2008 02:02:54 PM UTC, comment #5:
Please first apply the patch attached to #22686.
|
Sun 23 Mar 2008 01:50:25 PM UTC, comment #4:
The patch failed to apply to both 0.8.7 and CVS. When I made the changes manually in application.cc, it failed to compile. The CVS version still has the error, but it doesn't appear you've applied the patch there yet.
|
Sun 23 Mar 2008 07:48:44 AM UTC, comment #3:
Not an OpenBabel issue, my bad. The file name has to be unescaped before opening the stream. Attached patch also unescapes the file name before displaying it in a message box.
(file #15314)
|
Sat 22 Mar 2008 08:12:16 PM UTC, comment #2:
I see, it is a cdxml file. This means that it might be an openbabel issue. The message is emitted when OpenBabel returns a NULL format. I'll have a look at this code.
|
Sat 22 Mar 2008 07:43:20 PM UTC, comment #1:
I should add that I did NOT see this problem with the gchemutils programs (0.8.7) - in the molecular viewer I was able to open a .pdb file containing spaces in the path without a problem, as well as chemical markup file that did not work with Gchempaint from the same location (again, only through File...Open).
|
Sat 22 Mar 2008 07:36:14 PM UTC, original submission:
Using Ubuntu 7.10, either 0.8.5 or 0.8.7 (w/ patch to fix crashing for non-existant file), I get the following (as an example) when I try to open a file with a space in the name:
Could not open file
file:///home/terry/Data/Georgia%20Tech/ligands.cdxml
The specific path is not important, I've had it fail in all paths tried containing a space, and work in all paths not containing one. The file type also does not seem to matter. It does work from the command line.
In the event the root cause is in one of the dependencies, here are the versions I used to build:
openbabel 2.2.1
goffice 0.4.2
gtkglext 1.2.0
libglade2 2.6.2
libgnomeprintui2.2 2.18.1
gettext 0.16.1
libgnome2 2.20.0
BODR 6
chemical-mime-data 0.1.94
|