[Interest] Kicking out QtScript completely

Christian Dähn daehn at asinteg.de
Tue Mar 17 21:21:18 CET 2015


Hallo Andre´,

thanks for your very philosophic (sorry: but off topic) post.

But your post shows really in depth the problems between developer's opinions
and real life requirements.

Business grade frameworks have to last for many many years,
while (pure) open source projects are far beyond this business
requirement. A steady changing API causes investments to break
and maintenance costs to explode.

Further a quick deprecation of a very basic functionality (like QtScript)
can break complete thirdparty solutions build on top of Qt (as many many
business applications, like mine).

So every smart manager would stop his developers and take them down
to earth - what we see here is just a small group deciding about world wide
used public APIs without ever thinking about building up a migration path
nor thinking about the thousands of developers who are using QtScript to
earn their salary and thus pay for the developers work (license fees to Digia).

And as you can read inside this thread and the original thread from february
there still is no full support for all QtScript functions and types, nor will there
be any chance of a migration path, nor will there be a graphic script debugger,
nor will old scripts work with the new and not as famous as thought QML script engine.

From my experience and opinion as senior developer this is a very common
problem of open source developers not concerning customers and business
requirements. They just decide about giant changes without thinking about
consequences and how to support their paying customers.

And this is a management problem, too.

For me as paying customer it looks like Digia / Qt Company doesn't operate
in any customer oriented way. Otherwise the communication would be much
better and nobody would talk about deprecating something without offering
support for a smart migration.

Instead customers and users are described as just angry birds who fear any
small changes and just complain. Of course they do, because nobody was
part of this hughe descision.

Great work guys!

Greetz,
Chris

PS: I work with Qt since 1999 and whitnessed so many big changes - but no
       and honestly no change made me so angry and afraid like this.
       I'm really really worried about how keeping my industrial apps alive,
       which I MUST maintain for many years while keeping them secure.

Von meinem iPad gesendet

> Am 17.03.2015 um 20:51 schrieb André Pönitz <apoenitz at t-online.de>:
> 
>> On Tue, Mar 17, 2015 at 04:37:23PM +0100, Alejandro Exojo wrote:
>> El Tuesday 17 March 2015, Koehne Kai escribió:
>>> The QtQml library has no GUI dependency. So while I see some porting effort
>>> to switch from QtScript to QtQml, it's not true that this prevents command
>>> line applications.
>>> 
>>> And you don't have to use the QML language either ... QtQml has a QJSEngine
>>> class.
>> 
>> Or... keep using QtScript. People seem to complain only when a module is 
>> deprecated in a blog post, but don't raise their voice when they see no 
>> commits at all:
> 
> This is understandable insofar as "keeping the status quo" is good enough,
> if not "all that's desirable", in a lot of setups.
> 
> People who have a bread-and-butter-application that happens to use libraries
> X_1 ... X_n as *helpers* for their primary case are typically only interested
> in keeping the depenendencies in a workable state in their prefered setup,
> i.e. compatible with the toolchain and tooling they choose for their main
> application.
> 
> Performance improvements and security fixes for those libraries dependencies
> are typically welcome, less so source incompatible changes that require
> changes to their general setup or, worse, their b&b application itself.
> 
>> If it worked for you in previous releases, it should work more or less the 
>> same in the next ones, because it received almost no changes.
> 
> Right.
> 
> And this may continue for a while. But at some time $ANCIENT_VERSION_OF_X_I
> does not compile with $PREFERED_COMPILER anymore. Then $PEOPLE have a problem.
> Since $PEOPLE know this happens rather sooner than later after $X_I is called
> "deprecated" or "done", $PEOPLE will start complaining as soon as $X_I is put
> in that basket. That is predictable (and if I may add: sane and rational)
> human behaviour.
> 
> Andre'
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest



More information about the Interest mailing list