For the record, I'm pretty sure that the change that I made was something completely different than what you were thinking it was.
-- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Thu, Apr 2, 2020 at 4:47 PM Carlos Rovira <carlosrov...@apache.org> wrote: > Hi > > I'm sorry to say that the Josh's fix I commented is not fixing the thing I > suggested. The problem of labels removed is still there as you can see in > the following image (I had it today again): > > https://imgur.com/a/NEiUZXH > > The labels or icons that are removed change, so I think this could be some > thread problem since happens un one compilation from around other 15 or > so... > > If someone could take a look at this, would be great, since I think is an > important problem. > I think we should detect what's happening if we can before 1.0 > > Thanks > > > > > > On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira <carlosrov...@apache.org> > > > wrote: > > > > > >> Hi Josh, > > >> > > >> many thanks for this report to see what changed: > > >> > > >> Although all is impressive, I think the second point is really > > important, > > >> if is what I think it's. > > >> > > >> From always, I had "false compilations" in TDJ (and other real apps) > > that > > >> make string labels in menus, list, and icons, be blank sometimes and > > >> randomly. I think is 1/20 compilations. So that change seems to fix > that > > >> if > > >> I'm understanding correctly. > > >> > > >> I'll be watching that the following days to see if that's finally > solved > > >> or > > >> I still can get a false compilation. > > >> > > >> If is solved, I think this change is key, since until now I think an > > user > > >> getting that behaviour will think not so well about Royale stability. > > >> > > >> Thanks!! :) > > >> > > >> Carlos > > >> > > >> > > >> El mié., 1 abr. 2020 a las 21:04, Josh Tynjala (< > > >> joshtynj...@bowlerhat.dev>) > > >> escribió: > > >> > > >> > Good news! I was able to expand on what Alex suggested to provide a > > >> > solution that prevents public variables from being renamed by Google > > >> > Closure in release builds. A few key points: > > >> > > > >> > - You can set public variables in MXML, and they will work > > correctly > > >> in > > >> > release builds. Previously, only properties with setters worked > in > > >> > release > > >> > builds. > > >> > - I've also determined how to prevent Google Closure from > creating > > >> > multiple copies of static public variables, which caused some > > values > > >> > (numbers, boolean, strings) to get out of sync if changed at > > runtime. > > >> > This > > >> > was a closely related issue. > > >> > - I added prevent-rename-public-symbols and > > >> > prevent-rename-protected-symbols compiler options. They are true > by > > >> > default, but you can set them to false to go back to the old > > behavior > > >> > (which would include reporting a warning for public vars). > > >> > - No changes were required to the MXMLDescriptor, so my changes > > won't > > >> > mess with debugging workflows that require inspecting that data > > >> > structure > > >> > at runtime. > > >> > > > >> > The process of implementing a better solution for this gave me some > > >> ideas > > >> > related to adding more control over exports, so I plan to give that > > >> another > > >> > try too. Thanks again to Alex for the suggestions that helped make > > this > > >> > happen. > > >> > > > >> > -- > > >> > Josh Tynjala > > >> > Bowler Hat LLC <https://bowlerhat.dev> > > >> > > > >> > > > > -- > Carlos Rovira > http://about.me/carlosrovira >
