M
Malcolm McLean
Microsoft has just bought mobile phone company Nokia.
This wouldn't be of any particular interest to the comp.lang.c community,
except that Nokia is the driving force behind Qt, which was emerging as the
standard free cross-platform windowing system. However Nokia had cut new Qt
development to a bare minimum, understandably, as it tried to cut costs to
respond to its fall in market share.
Qt has a sort of C++ interface. Code that calls Qt is written in a language
that is almost C++, but has a "slot and signal" mechanism that isn't implemented
in C++, but by a front end. So the code needs to be run through the Qt
front end first. Whilst the Linux Qt code was open source, the Windows version
was closed source.
It remains to be seen what Microsoft will do with Qt. They can't kill the
Linux version, because its open source any any third party could choose to
develop it. But they can kill it for Windows, which would drastically reduce
the attractiveness of the Qt route. It must be worrying for anyone who has
a big base of Qt code.
My conclusion is that you're better of sticking with simple solutions,
using pure C interfaces without any sort of front end or development.
This wouldn't be of any particular interest to the comp.lang.c community,
except that Nokia is the driving force behind Qt, which was emerging as the
standard free cross-platform windowing system. However Nokia had cut new Qt
development to a bare minimum, understandably, as it tried to cut costs to
respond to its fall in market share.
Qt has a sort of C++ interface. Code that calls Qt is written in a language
that is almost C++, but has a "slot and signal" mechanism that isn't implemented
in C++, but by a front end. So the code needs to be run through the Qt
front end first. Whilst the Linux Qt code was open source, the Windows version
was closed source.
It remains to be seen what Microsoft will do with Qt. They can't kill the
Linux version, because its open source any any third party could choose to
develop it. But they can kill it for Windows, which would drastically reduce
the attractiveness of the Qt route. It must be worrying for anyone who has
a big base of Qt code.
My conclusion is that you're better of sticking with simple solutions,
using pure C interfaces without any sort of front end or development.