kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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. !!!