kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

Hi Chris,

>From long time I was merging updates from Cirilo's branch related with changes on 3D plugins.
That difference comes from one of that updates:
http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/revision/5608.35.101#pcbnew/exporters/export_vrml.cpp

Maybe Cirilo can clarify this difference.
Maybe something was lost or I miss updated it.

This remind us that branches should be compared side by side looking for any (not expected) differences on non 3d-viewer source code as I may touched something by mistake.

Regards,
Mario Luzeiro
________________________________________
From: Chris Pavlina [pavlina.chris@xxxxxxxxx]
Sent: 15 June 2016 13:27
To: Mário Luzeiro
Cc: kicad-developers@xxxxxxxxxxxxxxxxxxx; stambaughw@xxxxxxxxx
Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

Mário,

In order to build on OSX, I had to make the following change:

pcbnew/exporters/export_vrml.cpp, line 1210
-        wxFileName modelFileName = wxString::FromUTF8Unchecked(
-            resolver->ResolvePath( sM->m_Filename ) );
+        wxFileName modelFileName = resolver->ResolvePath( sM->m_Filename );

Because ResolvePath returns a wxString, and wxString::FromUTF8Unchecked does
not accept a wxString, and the particular combination of wx and compiler on
that platform does not allow any implicit cast that can resolve that.

I need to clarify what exactly is going on here, though. If ResolvePath
returns a wxString, this implies that the path has already been decoded from
UTF8 and is stored in the wxString as a sequence of codepoints in whatever
format wx uses for that. wxString is to contain Unicode codepoints, not raw
encoded data. If ResolvePath does indeed decode the path, then it is safe to
remove the call to FromUTF8Unchecked. However, if ResolvePath is not
decoding the path, it really needs to be changed to return something more
suitable for holding raw UTF8 data.