[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: dependencies on KJS/KHTML in kdelibs and kdebase-runtime
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2010-09-25 12:39:34
Message-ID: 201009251339.34259.aacid () kde ! org
[Download RAW message or body]

A Dissabte, 25 de setembre de 2010, Chani va escriure:
> On September 24, 2010 23:20:23 Maksim Orlovich wrote:
> > Nah, the performance part is likely the accurate one, unless the bloat
> > of QtScript manages to hide JSC's excellent performance. Which it
> > actually might.
> > 
> > On 9/24/10, Albert Astals Cid <aacid@kde.org> wrote:
> > > A Divendres, 24 de setembre de 2010, Maksim Orlovich va escriure:
> > >> > To put it plainly, if I'm the maintainer of a piece of code (in
> > >> > kdelibs, kdebase, wherever) that uses KJS, and someone offers me to
> > >> > port that code
> > >> > to QtScript himself (stating as reasons wider availability, higher
> > >> > performance, and shorter code), is there a reason to refuse that?
> > >> 
> > >> How about when the truthfulness of most of these claims is dubious?
> > > 
> > > Then it's when we do some benchmarking?
> 
> the "shorter code" part is.. an understatement. I saw a bit of it. there
> are huge swaths of code that would be just *gone* after switching to
> qtscript.
> 
> wider availablility? well, given that kde depends on qt, kjs cannot have
> wider availability than qscript. as best they'd be equal - but as aaron
> explained, on mobile there's no room for multiple implementations of
> things. therefore qt has wider availability.

ldd libkjs.so and see it's dependencies, you'll notice Qt is *not* a 
dependency.

Albert

> 
> and... you say that higher performance is likely accurate.
> 
> so, I'm not seeing anything dubious here. o.0
[prev in list] [next in list] [prev in thread] [next in thread]