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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > 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 > _______________________________________________ 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
