[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Thiago Macieira]

On Sunday 18 January 2015 22:24:40 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > That said, back in 2012 when we were discussing the renaming, I made the
> > argument that some of our binary executables are not "build tools" but are
> > instead "user applications". Those should not be installed in a private
> > libexec dir, but should be global in /usr/bin and not proxied by
> > qtchooser. Distros would also take care to install only one and we would
> > take care to keep compatibility with Qt 4 and, if necessary, Qt 3.
> 
> Some of the executables are "user applications", but still need to be
> renamed. For example assistant-qt4 vs. assistant-qt5. At least, they show
> different content by default (and the Qt 3 version that is unsuffixed
> "assistant" here is completely different, it is what has become the
> deprecated assistant_adp in Qt 4). The same goes for designer, linguist etc.

You're right for Assistant, even though that's actually just a configuration.

Linguist has no such problem.

As for Designer, the discussion in 2012 was that its output is compatible with 
Qt 4 and will remain so, but distributions need to upgrade the plugins to use 
Qt 5 instead and we can't be blamed if the plugins break their behaviour.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center