[jbosstools-dev] Do we still need Xulrunner in Devstudio?

Tue Oct 25 09:00:12 EDT 2016

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 at redhat.com> 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 at redhat.com> 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 at redhat.com
>> > 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 at redhat.com>
>>> > To: "Ilya Buziuk" <ibuziuk at redhat.com>
>>> > Cc: "Nick Boldt" <nboldt at redhat.com>, "Leo Ufimtsev" <
>>> lufimtse at redhat.com>, "Jeff Johnston" <jjohnstn at redhat.com>
>>> > Sent: Thursday, 29 September, 2016 9:04:42 AM
>>> > Subject: Re: Do we still need Xulrunner in Devstudio?
>>> >
>>> >
>>> >
>>> > ----- Original Message -----
>>> > > From: "Ilya Buziuk" <ibuziuk at redhat.com>
>>> > > To: "Aleksandar Kurtakov" <akurtako at redhat.com>
>>> > > Cc: "Nick Boldt" <nboldt at redhat.com>, "Leo Ufimtsev" <
>>> lufimtse at redhat.com>,
>>> > > "Jeff Johnston" <jjohnstn at redhat.com>
>>> > > 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 at redhat.com>
>>> > > wrote:
>>> > >
>>> > > >
>>> > > >
>>> > > > ----- Original Message -----
>>> > > > > From: "Ilya Buziuk" <ibuziuk at redhat.com>
>>> > > > > To: "Nick Boldt" <nboldt at redhat.com>
>>> > > > > Cc: "Aleksandar Kurtakov" <akurtako at redhat.com>, "Leo Ufimtsev"
>>> <
>>> > > > lufimtse at redhat.com>, "Jeff Johnston"
>>> > > > > <jjohnstn at redhat.com>
>>> > > > > 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 at redhat.com>
>>> 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20161025/f1726498/attachment-0001.html 