kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 5/2/19 5:32 PM, Dick Hollenbeck wrote:
> On 4/30/19 4:36 AM, Jeff Young wrote:
>> We had talked earlier about throwing the wxWidgets UTF8 compile switch to get rid of our wxString re-entrancy problems.  However, I noticed that the 6.0 work packages doc includes an item for std::string-ization of the BOARD.  (While a lot more work, this is a better solution because it also increases our gui-toolkit-choice flexibility.)
>>
>> I’d like to propose that we use std::wstring for that.  UTF8 should *only* be an encoding format (similar to s-expr).  It should never be used internally.  That’s what unicode wchar_t’s are for.
>>
>> And I’d like to propose that we extend std::wstring-ization to SCH_ITEM and LIB_ITEM.  (Then we can get rid of a bunch of our ugly mutex hacks.)
> 
> 
> I've been looking at this for a few months now.  I think it is so important, that a
> sub-committee should be formed, and if that committee takes as long as 4 months to come to
> a recommendation, this would not be too long.  This issue is simply too critical.
> 
> I would like to volunteer to be on that committee.  For the entire list to participate in
> this simply does not make sense to me.  I would welcome the opportunity to study this with
> a team of 5-6 players.  More than that probably leads to anxiety.  Then, given the
> recommendations, the list would of course have an opportunity to raise questions and take
> shots, before a strategy is formulated, and before anything is implemented.
> 
> Again, approximately:
> 
>   committee recommendations -> list approval -> strategy formulation -> implementation
> 
> 
> Up to now I have looked at many libraries and have [way *too* much] experience in multiple
> languages on multiple platforms, so I think I can be valuable contributor.
> 
> The final work product initially would simply be a list of recommendations, that quickly
> transforms to a strategy thereafter.  This is an enormous undertaking, so I suggest
> against racing to a solution.  It could look a lot easier than it will ultimately be, as
> is typical in software development.  But the return on investment needs to be near optimal
> in the end.
> 
> Some questions to answer are:
> 
> a) How did wxString get to its current state?  Is is merely a conglomeration of after
> thought, or is is anywhere near optimal.
> 
> b) Why so many forms of it?  Can one form be chosen for all platforms?
> 
> c) How does wxString it compare to QtString?
> 
> d) What does the set of characters that don't fall into UCS2 actually look like?  How big
> is this set, really?  (UTF16 is bigger than UCS2 and picks up the difference.)
> 
> e) For data files, I think UTF8 is fine.  So the change is for RAM manipulation of
> strings.  Aren't we talking about a RAM resident string that bridges into the GUI seamlessly?
> 
> f) What does new C++ language support offer?
> 
> g) What do C++ language designers suggest?

h) What is the list of deficiencies with current string usage?


> 
> 
> etc.
> 
> But this is best continued in a smaller group, as said.
> 
> 
> The other thing that I bring to this is vast familiarity with KiCad's internal workings,
> string use cases, and goals.
> 
> Let me know if I can help.
> 
> Regards,
> 
> Dick
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>