kicad-developers team mailing list archive
Mailing list archive
Re: 6.0 string proposal
Wayne Stambaugh <stambaughw@xxxxxxxxx>
Fri, 3 May 2019 09:25:31 -0400
addr=stambaughw@xxxxxxxxx; prefer-encrypt=mutual; keydata= mQGiBEM0hxQRBAC2fNh3YOVLu1d5GZ0SbrTNldGiGnCJPLqzEnqFX9v6jmf33TMt6EmSLkl6 Wtfkoj0nVwKxcYmJkA8DX0QAokBkwNIzhSsBzQvthBLIk/5LnPVVKrEXOcL4mUyH1doKlkaE slgJozNa6Av+oavcvD02o1zJOloBbaHlNlyRt7fKswCgtIFlVjWggVH/15KfWk+Qo5JVPbME AIUBAQyL2OAx0n60AWec2WHnO9buHuG0ibtICgUMkE+2MRmYyKwYRdyVwGoIUemFuOyHp0AJ InX4T+vy2E7vkwODqjtMLfIoRkokW74Fi4nrvjlhOAw/vdq/twLbAmR9MOfPTpR4y7kQy1O2 /n+RkkRvh26vTzfbQmrH7cBJhk6aA/9Uwvu3E4zNJgHVZeS0HyWtmR1eOPPRbnkPgJTToX5O KMKzTJI/FX6kT7cFoCamitHrW3BJP4Dx+cMMsa47EGxqVTdbVJ4LjogsXTXxb+0Fn1u4zBdx x3Cer6O7+hqWy7zvpzeC6nSREjqDKa5CgHtv/GLm5uFPOmsjAsnHj2tlBrQmV2F5bmUgU3Rh bWJhdWdoIDxzdGFtYmF1Z2h3QGdtYWlsLmNvbT6IeAQTEQIAOBYhBOffs6CbblRzBkv33BtR cWlZ+CReBQJbFBS2AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBtRcWlZ+CReMI8A nRbrLkzp7+c2f0vX7sfg4ICX8LAKAJ9uClo4uJajmZa5zZrL2nKdZlUwIrkCDQRDNIcxEAgA gCru+3/aOC6RCjpvYC72wY+d5SmHphC6yeiV2/mOumyt5MLo/Ps2GznZr11JspqFk5K/Zpvp MMLqqjDZ39+50a2iKRQFJ6NlK+hJWMmj6eJygQrCwYo3Gjc6CqfrqUv+8VSnf/i5sIZmtOVA 4ZjML18MuBvMSsNdVLFJd5HNnYb1iOECpvqdPVh/21LLCEw7MUUGGnHBhCrmk2aJe5hFmcSN g4ldBcXrgMQBwf7aMVoobXBMFDb/IENByXn0llB7Gr2IFMRmNS9/p8s/II1Yl2bTqyX4FSz8 cfn7C9KEz7faZ7wzAcpwHFC/zs3JoAjJ0IEKdNUpIwAlKMzT3CzctwADBQf/cxpG28MKyrqk nNmq/8LQLy+x6FSYXBLjxQz9BiBNYeesDZQ6J5UbL1mjpJzMa5tLZypPYo4bbGyR22hrbyDF K7m6AcVaMIJKl98g4ukMutFfAJyRDaREH5Zl/X1P4u1Z/yaAIy9mKaNbaK1/5djNJ5wCTFen TUgAp9xdc30kGkFDdLJFp5uxDY4P0vaZiZdjUCvDM3Zjv5IzpNOfxVqTUBQNUP/BnnKhkk0p DTD6s3X8S+D0rOtEBQ8K0cwERI/E8EFa8nj0TNw4e2MYGR8wg+SxqJ7z5f0zPY0bO6G9DDFB wYCqzzPWGqdAh9vA5971TAbPERtdFybhkurozp2SfYhJBBgRAgAJBQJDNIcxAhsMAAoJEBtR cWlZ+CResHUAniULLCWiT26ieRTl7N2vS6vBo/DuAJ4m7Ss/gyiW6ybTn1ctDXAUgm2QVQ==
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
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
> 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?
> 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.
> 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.
> 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