Hello, Leo Unfortunately, I do not have any snippet for testing POC based on BrowserFunction approach. However, I do believe you can relatively easy implement some synthetic tests for DOM manipulations via script executed by BrowserFunction (e.g. replace all "div" tags with "p" tags / change "src" attributes of the "img" tags etc. ). I did something similar for CordovaSim some time ago for implementing Cordova InAppBrowser executeScript [1] functionality. Please, find the code of the executeScript BrowserFunction [2] I used. [1] https://cordova.apache.org/docs/en/2.7.0/cordova/ inappbrowser/inappbrowser.html#executescript [2] https://github.com/jbosstools/jbosstools-aerogear/blob/master/ cordovasim/plugins/org.jboss.tools.cordovasim/src/org/ jboss/tools/cordovasim/plugin/inappbrowser/ExecScriptFunction.java#L57 On Mon, Oct 24, 2016 at 5:05 PM, Leo Ufimtsev <lufimtse(a)redhat.com&gt; wrote: > Hello, > > I'm in the process of migrating Webkit1 to Webkit2 in SWT. This also > includes porting the BrowserFunction. In regards to: > > On Thu, Sep 29, 2016 at 6:28 AM, Ilya Buziuk <ibuziuk(a)redhat.com&gt; wrote: > >> Hi, Aleksandr >> Alexey has already moved this discussion to jbosstools-dev. >> >> Unfortunately, I do not have Webkit POC ready to hand, but I think I >> remember the approach. Basically, the WebKit based transformation was done >> via SWT BrowserFunction[1] and the performance was much worse in comparison >> with the DOM API. If you want to figure out how the current Xulrunner based >> implementation work, you should probably start with tests[2] that cover >> things like mapping between source jsf / jsp tags and visual part via DOM >> API. However, I still want to put my 2 cents in this discussion. >> > > Would you happen to have a snippet lying around that uses BrowserFunction > that I could use to evaluate Webkit2 performance? > I'm implementing a few bits in native C, which could potentially speed > things up a bit. Or at least I could keep performance in mind during the > port in case you guys do end up choosing to go down the Webkit route. > > Regards > > Thank you > > Leo > > > >> Let's face the bullet - JSF is dying technology, and spending any time >> on new development is simply nonsensical IMO. Even if eventually a better >> WebKit based VPE will be created (which is doubtful because it was >> developed by big team ~ 10 developers for a couple of years) it will have >> very little value for both community and business. For now the only request >> from the community was - "please, leave it as is". >> >> If SWT will drop GTK 2 support than we will have to deprecate it on this >> Linux. But it worth mentioning that all Linux distros are just a couple of >> percents of the tools user base and our target audience ~ 85 - 90 % is >> Windows developers. For me it is also not clear why it is important to >> deprecate it right now ? We already had this discussion and decided not to >> do it in 2015, so I can not come up with a reason why should it be done in >> 2016. Just to be clear, I am not against deprecation, I am just saying that >> we should think twice before doing it and get some agreement about >> Xulrunner future, so that we will not be returning to this discussion again >> and again. >> >> [1] http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.ec >> lipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fs >> wt%2Fbrowser%2FBrowserFunction.html >> [2] https://github.com/jbosstools/jbosstools-vpe/blob/master >> /tests/org.jboss.tools.vpe.base.test/src/org/jboss/tools/ >> vpe/base/test/VpeTest.java#L340 >> >> On Thu, Sep 29, 2016 at 8:07 AM, Aleksandar Kurtakov < >> akurtako(a)redhat.com&gt; wrote: >> >>> Adding Max and Alexey (maybe we should move to the mailing list?) and >>> dropping Jeff to not spam him. >>> >>> ----- Original Message ----- >>> > From: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt; >>> > To: "Ilya Buziuk" <ibuziuk(a)redhat.com&gt; >>> > Cc: "Nick Boldt" <nboldt(a)redhat.com&gt;, "Leo Ufimtsev" < >>> lufimtse(a)redhat.com&gt;, "Jeff Johnston" <jjohnstn(a)redhat.com&gt; >>> > Sent: Thursday, 29 September, 2016 9:04:42 AM >>> > Subject: Re: Do we still need Xulrunner in Devstudio? >>> > >>> > >>> > >>> > ----- Original Message ----- >>> > > From: "Ilya Buziuk" <ibuziuk(a)redhat.com&gt; >>> > > To: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt; >>> > > Cc: "Nick Boldt" <nboldt(a)redhat.com&gt;, "Leo Ufimtsev" < >>> lufimtse(a)redhat.com&gt;, >>> > > "Jeff Johnston" <jjohnstn(a)redhat.com&gt; >>> > > Sent: Wednesday, 28 September, 2016 8:23:47 PM >>> > > Subject: Re: Do we still need Xulrunner in Devstudio? >>> > > >>> > > Basically, jsf tags can not be displayed as-is and be parsed >>> correctly in >>> > > browser like html, due to the fact that it is server side >>> technology. So, >>> > > the algorithm for VPE is the following: the content is rendered >>> and all >>> > > jsf tags are parsed through a set of templates via the native DOM >>> API which >>> > > is available only in particular older versions of XULRunner. So, in >>> order >>> > > to use Webkit or other engine and migrate all VPE features, >>> reimplementing >>> > > all of those temlpate transformations is required. Plus not to >>> forget the >>> > > performance thing - processing might take a long time (I think we >>> had some >>> > > WebKit POC but performance was just unacceptable). This is not a >>> trivial >>> > > task at all and I do believe that we have no resources for doing >>> it - VPE >>> > > component's code base is one of the biggest (if not the biggest) >>> across >>> > > tools. >>> > >>> > That's exactly the kind of info I was looking for. Can you point me >>> to the >>> > transformations used for the xulrunner? Sorry for being lazy but it's >>> > foreing land for me so I would rather not lose time lurking around. >>> > Do you have a pointer to the WebKit POC? It might be interested to >>> reach out >>> > to the desktop team (there is webkit developer there) with all the >>> info so >>> > maybe they can hint us how to achieve what's needed if latest webkit >>> doesn't >>> > fullfill the needs. >>> > >>> > > In a nutshell - after reimplementing there will be the same, or less >>> > > powerful, VPE with more bugs and poor performance. >>> > >>> > That might be true now but you should think a bit further in time. In >>> the not >>> > so distant future (2018 release most probably, if not 2019 for sure) >>> SWT >>> > itself will drop support for running on GTK 2.x and that would be >>> > effectively the end of this plugin if no action taken. >>> > >>> > >>> > > >>> > > On Wed, Sep 28, 2016 at 6:42 PM, Aleksandar Kurtakov < >>> akurtako(a)redhat.com&gt; >>> > > wrote: >>> > > >>> > > > >>> > > > >>> > > > ----- Original Message ----- >>> > > > > From: "Ilya Buziuk" <ibuziuk(a)redhat.com&gt; >>> > > > > To: "Nick Boldt" <nboldt(a)redhat.com&gt; >>> > > > > Cc: "Aleksandar Kurtakov" <akurtako(a)redhat.com&gt;, "Leo >>> Ufimtsev" < >>> > > > lufimtse(a)redhat.com&gt;, "Jeff Johnston" >>> > > > > <jjohnstn(a)redhat.com&gt; >>> > > > > Sent: Wednesday, 28 September, 2016 7:19:24 PM >>> > > > > Subject: Re: Do we still need Xulrunner in Devstudio? >>> > > > > >>> > > > > Actually, we planned to remove xulrunner and deprecate VPE some >>> time >>> > > > > ago >>> > > > > and leave only VPV as a WYSIWYG html editor. >>> > > > As someone not familiar with the topic I don't see xulrunner and >>> VPE >>> > > > deprecation that closely coupled. What is the reason for that? >>> What's >>> > > > preventing to achieve it with webkit? Do you extend SWT Browser >>> API >>> > > > somehow? >>> > > > Please give all the details you can think of so I can get better >>> > > > understanding of the issue/reasons. >>> > > > >>> > > > > However, as soon as we gave a >>> > > > > shout out about this on tools.jboss.org the first comment was: >>> > > > > >>> > > > > Nice. The reason I used JBoss Tools was the Visual Editor for >>> JSF, >>> > > > > > especially for the Visual parts, which was not perfect but >>> was good >>> > > > enough >>> > > > > > to have it. Will you have alternatives for that ? [1] >>> > > > > >>> > > > > >>> > > > > It was decided that we need to slow down with this process. I >>> can not >>> > > > > say >>> > > > > if it is a high time for doing this assuming that some people >>> actually >>> > > > use >>> > > > > it. Furthermore, some people treat it as a killer feature for >>> JSF that >>> > > > only >>> > > > > one IDE is providing. So, we need to think twice before doing >>> it. >>> > > > > >>> > > > > [1] http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.GA- >>> > > > for-luna.html >>> > > > > >>> > > > > On Wed, Sep 28, 2016 at 5:40 PM, Nick Boldt <nboldt(a)redhat.com&gt; >>> wrote: >>> > > > > >>> > > > > > On the Eclipse team call today, the question of why we need >>> Xulrunner >>> > > > > > was brought up again. >>> > > > > > >>> > > > > > As I understand it, the only reason we still include >>> Xulrunner is for >>> > > > > > the Visual Page Editor. But Alex pointed out today that >>> Xulrunner >>> > > > > > only >>> > > > > > works on GTK2, which means a user has to explicity disable >>> GTK3 in >>> > > > > > order for Xulrunner to be used, as these days GTK3 is the >>> default >>> > > > > > OOTB >>> > > > > > implementation on the platforms we support (Fedora 24/25, >>> RHEL7, >>> > > > > > etc.). >>> > > > > > >>> > > > > > So... is it time to remove Xulrunner from the Devstudio >>> dependencies, >>> > > > > > if most people are not even seeing it used? >>> > > > > > >>> > > > > > Alex suggested it might be useful to set up a call to discuss >>> this in >>> > > > > > more depth. Is there a good time tomorrow or Friday you guys >>> would >>> > > > > > like to meet to discuss this, if it can't be resolved >>> asynchronously >>> > > > > > via email? >>> > > > > > >>> > > > > > Whatever we decide here, we should make sure we announce this >>> on the >>> > > > > > jbosstools-dev@ list. >>> > > > > > >>> > > > > > -- >>> > > > > > Nick Boldt :: JBoss by Red Hat >>> > > > > > Productization Lead :: JBoss Tools & Dev Studio >>> > > > > > http://nick.divbyzero.com >>> > > > > > >>> > > > > >>> > > > >>> > > > -- >>> > > > Alexander Kurtakov >>> > > > Red Hat Eclipse team >>> > > > >>> > > >>> > >>> > -- >>> > Alexander Kurtakov >>> > Red Hat Eclipse team >>> > >>> >>> -- >>> Alexander Kurtakov >>> Red Hat Eclipse team >>> >> >> >