On 11/13/2013 11:50 AM, Wayne Stambaugh wrote: > On 11/13/2013 11:46 AM, Dick Hollenbeck wrote: >> On 11/13/2013 09:28 AM, Wayne Stambaugh wrote: >>> Fix committed in r4463. >>> >>> ** Changed in: kicad >>> Status: New => Fix Committed >>> >> >> tool_manager.cpp: >> >> line 142 is using concatonation against a format string, this is a bug. >> >> If you want formatting, we need wxString::Format() or the new std::string >> StrPrintf() or >> similar. >> >> If the format string is not going to be translated, then there are savings >> by going down >> to an 8 bit string. On linux, wxT() creates a 32 bit string, which takes up >> 4 times the >> memory of an 8 bit string. >> >> >> Further consideration has us anticipating a transition to wx 3.x on all >> platforms, at >> which point we can remove all wxT() instances, supposedly. That also will >> be a transition >> to 8 bit constant strings, one we have to wait for. >> >> So there are two paths forward, both sensible, one you have to wait for. >> >> The deciding factor for me is that aTool->GetName() returns >> >> const std::string& >> >> so we start with an 8 bit string. >> >> So I offer the attached patch. >> > > I missed this before but doesn't the string in this patch need to > translated with _()? Previously, these messages were dumped to a wxLog > so only developers would see them but now they are being displayed to > the user by the call to DisplayError().
This one has a low chance of ever showing up. Apparently Orson thought it too improbable, so why pester a translator person. We need an 8 bit internationalization interface, if ever we were to wean ourselves of wxString(), short of the GUI functions. What comes back from _() is const wxChar*. This is contrary to the wx documentation which says wxString. i.e. the documentation is wrong on this function. wxString _() <--- not true const wxChar* _() <--- actual const wxChar* is a pointer to a 32 bit string help by the translation library. We need an 8 bit std::string() returned from such internationalization function, in the current locale. Maybe we introduce our own __() function, which is two underscores, and then refrain from using wxString in all but the wxWindow derived class functions. std::string __( const char * ) is really what is needed. The result does not need to UTF8 encoded, but should be in the current locale, so we can use the new 3.0 wxString( std::string ) constructor. We only care about the 8 bit encoding in a couple places: 1) disk based 8 bit text. 2) 8 bit plotter bound strings. 3) GAL strings In most of the remaining contexts, the current locale's encoding is fine in the std::string. !!! This is so you can use wxString( std::string ) and that means you can pass a std::string() to many of the wx GUI functions with no syntactical magic, if they can be promoted to wxString using the current locale's encoding. !!! _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
