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

Fri Oct 28 09:16:22 EDT 2016

I have created an issue[1] for xulrunner dependency removal from vpv.
Please, feel free to put your thoughts on it there

[1] https://issues.jboss.org/browse/JBIDE-23425

On Tue, Oct 25, 2016 at 3:00 PM, Ilya Buziuk <ibuziuk at redhat.com> wrote:

> 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/20161028/e745fc7a/attachment-0001.html 