Will using Qt in a big MFC Windows-only app speed up development? [closed]

Question

I know there is a lot of Qt vs MFC questions, but I'll try to be very specific.

We have a big (10 years of development) C++ MFC application for niche industry. It's supposed to stay Windows-only and English-only forever. But we need to add a bunch of new designer-drawn GUIs and GUI controls (dialogs, buttons, custom lists, ...).

We can hire 1 or 2 new GUI developers to build these new interfaces, so we can afford to choose different technology than MFC.

Qt seems most promising and suitable to run side-by-side with MFC (oh, no, we are not reduilding the app from scratch).

It seems that most cited Qt advantages are irrelevant: cross-platform development, easy internationalization, opensource, non-GUI libraries (we don't need networking and have most of other features already implemented).

But Qt is also famous for its good OO design and they've introduced QtQuick recently. I'd like to give it a chance, so the questions are

• In a commercial Windows-only project, what are substantional advantages of moving to MFC+Qt from of pure MFC, which is worth the trouble of learning Qt, integrating it in our build/deploy process and maybe paying for a commercial license?
• In particular, will it speed-up the development if we build new GUIs in Qt and incorporate them in the app via QWinWidget?

Answer 1

Probably not.

If the gui and business logic are nicely separated then it might make sense to move the gui gradually to Qt or implement new parts in Qt - but we both know the gui/logic will be a horrible mixed together mess

If you are doing a rewrite (which is what the Qt will end up as) then if it's a regular business type app then using C#/.net is probably easier.

If performance is critical and you have a lot of domain knowledge tied up in well defined well separated c++ libs then a Qt front end would be worthwhile