[jbosstools-dev] Do we still need Xulrunner in Devstudio?
Alexey Kazakov
alkazako at redhat.com
Thu Sep 29 12:06:25 EDT 2016
So, this all was about removing Xulrunner/VPE from RPM only? RHEL 7
doesn't support GTK2 at all or it's just tricky to use it instead of
GTK3? What about Fedora?
On 09/29/2016 08:37 AM, Nick Boldt wrote:
> Why wouldn't it be a solution?
>
> devstudio includes vpe. vpe depends on xulrunner. xulrunner needs
> GTK2. GTK2 on RHEL7 is not supported.
>
> Therefore devstudio rpm shouldn't include vpe/xulrunner/gtk2. QED. :D
>
> What if we provide two different install paths?
>
> a) rpm installs everything in devstudio except vpe/xulrunner (supported config)
>
> b) users who want vpe can then install it by hand from the devstudio
> *update site*, plus the 4 dependency RPMs, and enabling GTK3=0 to
> force Eclipse to run in unsupported GTK2 mode.
>
> I would also be open to the idea of building a quasi-supported ("Tech
> Preview") rh-eclipse 46-devstudio-vpe rpm, which provides the
> vpe/xulrunner and requires the 4 dependencies. It could maybe even
> enable GTK3=0 (?) on startup of Eclipse, provided it includes an
> eclipse.sh which would enable that property before starting the
> eclipse executable.
>
> This new rpm would of course require buy in from GSS and QE. Adding
> Len and Rick to cc:.
>
> N
>
>
>
> On Thu, Sep 29, 2016 at 10:53 AM, Alexey Kazakov <alkazako at redhat.com> wrote:
>>
>> On 09/29/2016 06:37 AM, Aleksandar Kurtakov wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Alexey Kazakov" <alkazako at redhat.com>
>>>> To: "Ilya Buziuk" <ibuziuk at redhat.com>, "Aleksandar Kurtakov"
>>>> <akurtako at redhat.com>, "jbosstools-dev jbosstools-dev"
>>>> <jbosstools-dev at lists.jboss.org>
>>>> Cc: "Max Rydahl Andersen" <manderse at redhat.com>, "Nick Boldt"
>>>> <nboldt at redhat.com>, "Leo Ufimtsev"
>>>> <lufimtse at redhat.com>
>>>> Sent: Thursday, 29 September, 2016 4:33:00 PM
>>>> Subject: Re: Do we still need Xulrunner in Devstudio?
>>>>
>>>> It looks like I missed some discussion here. So, I'm repeating my
>>>> question, why would we like to remove Xulrunner and/or deprecate VPE?
>>> The discussion started from xulrunner being usable only in GTK2 env when
>>> on RHEL 7 we support only GTK3. It would be really nice to not have
>>> recommendations to use GTK2 for using VPE as it would cause issues for other
>>> plugins.
>>
>> OK. So, removing VPE is not a solution for this anyway ;)
>>
>> Thanks.
>>
>>
>>>> Just want to understand if there is some real problem and our Xulrunner
>>>> stuff blocks us to solve it or this is just for cleanness sake.
>>>>
>>>> Thanks.
>>>>
>>>> On 09/29/2016 03:28 AM, Ilya Buziuk 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.
>>>>>
>>>>> 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.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fbrowser%2FBrowserFunction.html
>>>>>
>>>>> <http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%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 <mailto: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
>>>>> <mailto:akurtako at redhat.com>>
>>>>> > To: "Ilya Buziuk" <ibuziuk at redhat.com
>>>>> <mailto:ibuziuk at redhat.com>>
>>>>> > Cc: "Nick Boldt" <nboldt at redhat.com <mailto:nboldt at redhat.com>>,
>>>>> "Leo Ufimtsev" <lufimtse at redhat.com <mailto:lufimtse at redhat.com>>,
>>>>> "Jeff Johnston" <jjohnstn at redhat.com <mailto: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
>>>>> <mailto:ibuziuk at redhat.com>>
>>>>> > > To: "Aleksandar Kurtakov" <akurtako at redhat.com
>>>>> <mailto:akurtako at redhat.com>>
>>>>> > > Cc: "Nick Boldt" <nboldt at redhat.com
>>>>> <mailto:nboldt at redhat.com>>, "Leo Ufimtsev" <lufimtse at redhat.com
>>>>> <mailto:lufimtse at redhat.com>>,
>>>>> > > "Jeff Johnston" <jjohnstn at redhat.com
>>>>> <mailto: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 <mailto:akurtako at redhat.com>>
>>>>> > > wrote:
>>>>> > >
>>>>> > > >
>>>>> > > >
>>>>> > > > ----- Original Message -----
>>>>> > > > > From: "Ilya Buziuk" <ibuziuk at redhat.com
>>>>> <mailto:ibuziuk at redhat.com>>
>>>>> > > > > To: "Nick Boldt" <nboldt at redhat.com
>>>>> <mailto:nboldt at redhat.com>>
>>>>> > > > > Cc: "Aleksandar Kurtakov" <akurtako at redhat.com
>>>>> <mailto:akurtako at redhat.com>>, "Leo Ufimtsev" <
>>>>> > > > lufimtse at redhat.com <mailto:lufimtse at redhat.com>>, "Jeff
>>>>> Johnston"
>>>>> > > > > <jjohnstn at redhat.com <mailto: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
>>>>> <http://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-
>>>>> <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 <mailto: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
>>>>>
>>>>>
>
>
More information about the jbosstools-dev
mailing list