Hi Alex,
31.05.2020 09:13 tarihinde Alex Harui yazdı:
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.
I'm pretty sure and agree with you that is why I am still here.
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.
For one of the cases it is true and I replaced to mx TextArea, for the
rest I am going to work on.
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
Thanks,
Serkan
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>.
> >>
>
>
>
