[Development] Summary of renaming changes

[André Pönitz]

On Thu, Oct 18, 2012 at 10:16:37AM -0700, Thiago Macieira wrote:
> > I would remove creator from this list as it's a different ""product""
> > and comes with its own versioning and release cycle -- are all of
> > those 100% compatible with Qt 4? (First thing that comes to mind is
> > that designer loads plugins...). Otherwise, I would rename them as
> > well to enable coinstallation.
> 
> I added Creator to the list so that I could answer this exact question:
> 
> Does anyone here think we should have two versions of Creator installed, one 
> for developing Qt 4 applications and one for developing Qt 5 ones?

I personally don't think so.

Pretty much for the same reason that it does not seem to be overly
prudent to have different versions of Creator for gcc 4.6 and 4.7,
wxWidgets 2.8 and 2.9, boost 1.50 and 1.51, or Thursdays and Fridays.

> Creator needs *some* solution of some kind so that its Designer component
> can work for Qt 4 and Qt 5. 

Why? _You_ call Widgets "done". Why do you suddenly care how people
handle them? 
 
> One solution is to run designer out-of-process so that it can load the proper 
> plugins -- this also solves the problem of the MinGW / MSVC incompatibility on 
> Windows. This would require having designer renamed.

The MinGW/MSVC compatibility has been solved, or ignored, in various
ways during the last three years. None of the approaches involved
renaming the Designer binary, and it's not really clear how a 
'Designer5.exe' would help to solve the problem.

There have been incompatibilies in the Qt 4 era, too, and I am not
aware of a distribution renaming Designer into Desiger42 and Designer43
or similar, just because they generated and/or crashed on incompatible
.ui files.
 
> Another solution is to require the plugin upgrade, but continue to generate 
> backwards-compatible .ui files. That is, the plugin that provides KListWidget 
> should be upgraded too, to work in Qt 5, but continue to generate .ui data 
> that Qt 4's uic can understand and generate proper code for.
> 
> When I questioned briefly the Creator devs, they didn't seem too inclined to do 
> former option. That means we're going to require the second, moving the burden 
> to the plugin developers.

Which, incidentally, has worked for a few years already. Designer plugins
are not mandatory for successful use of Qt, not even for using Designer,
let alone Creator.

You are trying to solve a problem that does not exist in practice.

Andre'