Hi Serkan, I hope I never wrote or implied that the goal of the emulation components was to 100% emulate Flex. With a different runtime, limited time and resources, it would be impossible or impractical to emulate some features with available resources. I don't know every API well enough to come up with a list of things that would be in the category of impossible/impractical, plus that list changes constantly. But things like weak reference and priority in event listeners comes to mind. Turns out FileReference.save() is one, and also a 'cancel' event from FileReference.browse().
I hope I only said that Royale should be the shortest and/or safest path to migration because you don't have to rewrite as much of your application code. But I hope I also said that you would have to rewrite some of your code. I still think that's true, even though early adopters like you and some others have been working on the migration for around 2 years. Who knows how many harder-to-find problems there would have been if you switched to some other language/framework? When you use Royale many of your code paths do not change. If you port to a new language, every line of code pretty much changes. And so, in that reality, we have to make trade-offs to try to get you and others migrated as soon as we can given the resources we have. We did sort of get TLF working in Spark TextArea, but after it broke again, and looking at all of that code, I think mx:TextArea is a better answer. In the example you provided, your code was going to take HTML, convert it to TextFlow, and then the TLF would convert it to a bunch of HTMLElements. It should be much faster to just pass the HTML straight into a Browser's TextArea. It should save everyone time, and make it worth changing your code for a few instances of Spark TextArea. But if you disagree, we can certain discuss further. Similarly for FileReference, unless you want to restrict yourself to Chrome, there is no practical way to emulate the Save method. I'm pretty sure I've also written that some of these hard problems would have been a problem for you if you didn't choose Royale. IOW, I don't think there are other frameworks out there that can popup a Save dialog. If there is, let us know and maybe we can use their solution. I wish Royale could make migration pain-free, but it can't, we can only try to make it less painful, by providing a framework that should let you migrate by touching much less of your code than any other solution out there. In summary, we simply have to collaborate on what the fastest solution is. Sometimes that is changing the framework, sometimes it is changing your code. HTH, -Alex On 5/30/20, 3:59 AM, "serkan" <[email protected]> wrote: Hi Alex, 30.05.2020 10:22 tarihinde Alex Harui yazdı: > Hi Serkan, > > I'm sorry, I keep finding some of your emails in my junk mail. I haven't found a way to prevent that. And it has been a particularly busy time for me recently so sorry for not responding sooner. > > I've read this three times now and I'm not sure what kind of response you are looking for. I think we all appreciate that you are still working with us. I’m still trying to find time to help you, but I can't always get to your issues right away. Response matters, what ever it is > As with any user, the hope is that they will learn how the framework works and improve their ability to work with us and eventually provide patches and pull requests and earn committer status. Becoming less reliant on current committers is your best insurance for the future. If you have ideas on how that can happen let us know. I keep hoping other committers will help you more, but they also have their own priorities to juggle. Also, many of the available committers are independent developers so they are going to prioritize paid work, whereas I don't have to. Yes I have ideas but ends up with documentation > IMO, working with the framework code is different than working on application code, especially if the application code is your own code. You are not obligated to try to learn the framework code and remain more of a user than a committer. That said, the better your understanding of the framework, the more efficient the cycle of reporting and fixing bugs will be because the test cases will be easier to work with and you may even provide the answer yourself. So similarly, if you are interested in learning the framework and have ideas on how that can happen let us know. The unfortunate fact is that there really isn't a whole lot of documentation and the current set of committers are unlikely to be able to stop and provide a bunch of documentation so it tests one's skill at figuring out other people's code. I also develop frameworks Alex, I guess I have an idea and I believe all are specific and need special know-how, background and attention. Which is really different here for me is working on visual framework that I do not really like from the beginning of my career as I am a system/server side software developer. This does not mean that I do not want to participate in bug fixing or learning the framework. But for here, it is really complicated and more than just using and fixing a visual framework. There are lots of things unclear for the way to go, mostly you decide what to do and do it. And there should be documentation even from the architectural view and the path to be followed while fixing bugs. For example, FileReferance case. Which is the right way, to emulate 100% percent flex or just a work around who will decide and how ? (I am happy with workarounds by the way) > I don't doubt that you are trying your best to provide good test cases. And my apologies if you felt I singled you out by saying that your test cases could use improvement. You are not the only one who submits test cases that need fixing or simplification. I think that's something that would improve as your knowledge of the internals of the framework improves. Thanks, and agree. > For example, in this recent MenuBar case, the issue was not locales at all, but two other parts of the framework: DataBinding to XML (not from) and Collection notification. I was able to much more efficiently build and debug a test case without involving locales. On your insistence, I did take the time to create a test case to prove that locale changes would update XML via DataBinding correctly. The better your understanding of the framework, the fewer times I will have to go do that. i thought it was just related with change notification. > For the TextArea issue, stack traces are like fingerprints. They help identify that the same culprit is the problem. Learning to identify stacktraces helps make the development process more efficient. Instead of filing a bug with a stack trace and waiting for me to find time, it would better if somehow you could have realized it was the TextArea issue yourself and then we could have saved time and started discussing the choices. I started on a "reduced" emulation of Spark TextArea, but I put it on the shelf because it appeared that you had switched to mx:TextArea. If you only have a few s:TextAreas, then it might be more efficient to just replace those few instances instead of waiting for me to find time to finish this version and debug it. But if you have dozens of them, it might make more sense to see if we can get a reduced emulation working. I use sTextArea few times and need some time to check if mx is enough. > If you are willing to keep using Royale, I will keep trying to help you. I may not be able to help you as quickly as you like. If you can find a way to get to know the framework code better, I think that will be the best thing for you and hopefully all of us can help with that to some degree. If you have money, you can pay one of the other committers to prioritize your issues. My help is free and cannot be paid for, but then you can't get prioritized either. I see can live with. > HTH, > -Alex Thanks, Serkan > On 5/29/20, 7:14 AM, "serkan"<[email protected]> wrote: > > No response means some kind of response Harbs, > > Thank you for considering > > Serkan > > 27.05.2020 15:07 tarihinde Harbs yazdı: > > I noticed this email a couple of weeks ago assuming that someone who has been more involved in the emulation work would respond. It just occurred to me that Serkan never got a response. > > > > I assume people were busy and/or missed this. > > > > From my perspective I’ve been looking at what Serkan has been doing favorably, but I have not been focused on emulation or really involved much in that work. > > > > Piotr, Greg, Yishay or Alex (or anyone else who’s been involved) could someone respond to this and give Serkan some feedback? > > > > Thanks! > > Harbs > > > >> On May 16, 2020, at 10:50 PM, serkan<[email protected]> wrote: > >> > >> > >> Hi all, > >> > >> Moving to list because it became something more than issue comment. > >> > >> Nearly two year - starting with emulating classes - I am trying to make my flex application running with royale emulation. > >> > >> But more than my application, I am trying to be the part of the project that I believe doing very good things mostly the help of Alex and help to remove issues related with emulation components > >> > >> The way I go : > >> > >> 1. Running my app discovering the non-functioning parts. > >> 2. Trying to isolate the case from application - sometimes really time consuming issue because it is client-server app. > >> 3. Preparing a case than can be compiled and executed without server and simplify as possible > >> 4. Creating the issue and attaching the case to the issue > >> 5. Additionally porting the java script files to a server to make online testing available. > >> > >> And let me go step by step. > >> > >> /*If you have an issue with locale change, then create a test case I can run locally that uses a bundle I have (like one from Flex) that exposes the issue. If it is notifications, it should not be necessary to involve MenuBar or XML. Maybe a string in a Label.* > >> > >> /If every text in the application is changing with the locale change except the menubar which is populated with xml, is staying with the initial locale how can I create the case ?//I do not know any other to express myself/. /I am open to advises. > >> > >> /* > >> Almost all of the past examples you've sent that involve resources have been simplified by using string substitution. So that's what I did to this example, and sure enough, the MenuBar did not update, so I proposed a workaround.*/ > >> > >> All the cases I am attaching the issues are the isolated sources from the application sometimes does not have any similarity with app except the bug. I value your propositions. > >> > >> > >> /*I don't recall asking you to host live examples of these scenarios. I would only look at live examples if I could not reproduce a problem locally because locally I have all of the source so I know there aren't any side-effects from other modules and can re-compile with a change if needed.*/ > >> > >> I am trying to make it easier for you to view the issue with less effort but I can see it is going to the opposite direction. > >> > >> > >> /*For your TitleWindow issue, I just looked at the call stack and could see that it was another case of s:TextArea.*/ > >> > >> TitleWindow is the case that we have discussed couple of months ago. Replacing s:TextArea with mx:TextArea need some additional investigation because the component creation call hierarchy is working different and I am going to let you know after my investigation. > >> > >> /* > >> I'm not going to first try remote debugging. It just isn't efficient for me. I'm sorry you don't like the way I work. */ > >> > >> My aim for preparing the live demo is not the alternative for the attached case but the identical working one in case you need to see it alive. > >> > >> I am not trying teach anyone or you Alex which way to work, because I do not want anyone to try to do the same to me, I am just trying to help you to get case as soon as possible but unfortunately it did not worked. > >> > >> Do not have any comments on the way you work - like or dislike. > >> > >> /* > >> You are welcome to tell me not to help you anymore and get someone else to help you. > >> > >> */Nearly 99% of the time only you are interested and involved in emulation components and the bugs./**/How can this be possible or realistic ? > >> > >> At least why I should think that way ? Of course not. Just want to express my self. > >> > >> But if you think this is not helping Royale for improving the emulation components you just tell me to drop. > >> /* > >> */Thanks, > >> Serkan > >> > >> -------- İletilmiş İleti -------- > >> Konu: Re: [apache/royale-asjs] Can not change locale for menubar constructed via XMLList within declarations (#824) > >> Tarih: Sat, 16 May 2020 09:00:15 -0700 > >> Kimden: aharui<[email protected]> > >> Reply-To: apache/royale-asjs<reply+abnu4sqwu5ue3vgvqfxd6v54zpxq7evbnhhcjgj...@reply.github.com> > >> Kime: apache/royale-asjs<[email protected]> > >> CC: Serkan Taş<[email protected]>, Author<[email protected]> > >> > >> > >> > >> If you have an issue with locale change, then create a test case I can run locally that uses a bundle I have (like one from Flex) that exposes the issue. If it is notifications, it should not be necessary to involve MenuBar or XML. Maybe a string in a Label. > >> > >> Almost all of the past examples you've sent that involve resources have been simplified by using string substitution. So that's what I did to this example, and sure enough, the MenuBar did not update, so I proposed a workaround. > >> > >> I don't recall asking you to host live examples of these scenarios. I would only look at live examples if I could not reproduce a problem locally because locally I have all of the source so I know there aren't any side-effects from other modules and can re-compile with a change if needed. > >> > >> For your TitleWindow issue, I just looked at the call stack and could see that it was another case of s:TextArea. I'm not going to first try remote debugging. It just isn't efficient for me. I'm sorry you don't like the way I work. You are welcome to tell me not to help you anymore and get someone else to help you. > >> > >> — > >> You are receiving this because you authored the thread. > >> Reply to this email directly, view it on GitHub<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fissues%2F824%23issuecomment-629667547&data=02%7C01%7Caharui%40adobe.com%7C290ffc7f59324714d33208d80488958a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637264331959321999&sdata=QtzsAiHhQFSt5tpwwgrHXkWuYok7ScYsKrVXvmoGrdU%3D&reserved=0>, or unsubscribe<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABNU4SVCTHKCFSOIGOD6GGDRR22A7ANCNFSM4M3I4SIQ&data=02%7C01%7Caharui%40adobe.com%7C290ffc7f59324714d33208d80488958a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637264331959321999&sdata=zw%2Bp97KE1Jnox00shTm3LcZlIDfsZPyD8ucbhy%2FguOk%3D&reserved=0>. > >> > > >
