kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Thanks Wayne for giving me a chance to participate.

Jeff has been very helpful so far.  Before we setup a small group communications
mechanism, I look forward to Jeff's further input.  I think the needs analysis is
important before we build a solution work environment.

Maybe there's a simple solution set, without too many ripples.  But to get that lucky
would require knowing what the immediate problems are in more detail.


Dick


On 5/3/19 8:25 AM, Wayne Stambaugh wrote:
> Dick,
> 
> On 5/2/19 6: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.
> 
> I have no intention of just winging a solution and hoping it works.  We
> are just in the very early stages of brainstorming.  We know that in the
> long run we will have to do something to improve our current handling of
> strings so carefully defining what that looks like is important.  Once
> we have a well defined strategy, implementation will be clear to all
> developers.
> 
>>
>> 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?
> 
> UTF8 is definitely not going to change for file I/O.
> 
>>
>> f) What does new C++ language support offer?
>>
>> g) What do C++ language designers suggest?
>>
>>
>> etc.
>>
>> But this is best continued in a smaller group, as said.
> 
> I'm fine with keeping this limited to the lead dev team and yourself
> since it most likely the responsibility to implement this will fall on
> one of our shoulders.  There is no hurry on this.  Everyone has plenty
> to do as V6 development is in full swing.  I would prefer to take our
> time and get the strategy correct before we attempt to implement anything.
> 
> Cheers,
> 
> Wayne
> 
>>
>>
>> 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
>>
> 
> _______________________________________________
> 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
>