[Interest] Kicking out QtScript completely

[Philippe]

Very well expressed...

Philippe

On Tue, 17 Mar 2015 21:21:18 +0100
Christian Dähn <daehn at asinteg.de> wrote:

> 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
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest