-1

I am evaluating the feasibility of converting my app (Win32) to Qt. I would like to convert the code so that I can gradually convert one single codebase from Windows GDI to Qt, rather than cloning the source and have duplicate code. By flipping one global switch, or declaring one manifest constant in the project properties, I want to convert and test, while being able to release a production version (with the old code) whenever necessary.

Windows starts with a WinMain() function, I see that Qt has a main().

Is there an technique to organize the source to facilitate this? What is the best way to structure the code?

Pierre
  • 4,114
  • 2
  • 34
  • 39
  • 1
    You cannot gradually port your UI from native Windows to Qt. Qt is all or nothing. There is no in between. And frankly, I wouldn't know why you'd want to do that. You have a fully functional, snappy UI, with working keyboard support, and want to sacrifice all that? What for? – IInspectable Aug 26 '18 at 21:58
  • 2
    @IInspectable Er cross platform would be one motivation – David Heffernan Aug 26 '18 at 22:14
  • 1
    @Dav: If cross-platform is the motivation, there are certainly better alternatives (e.g. wxWidgets). If a quality UI matters, Qt is likely the last option to consider. – IInspectable Aug 26 '18 at 23:25
  • @IInspectable That's demonstrably false, and you seem to have some anti-Qt bias; based on functionality alone wxWidgets is a much less capable tooklit than Qt (if you care about future functionality of your app!). There have been huge industrial projects converted from all sorts of toolkits to Qt, in an incremental fashion. Qt interoperates with native Windows message pumps. Replace the `TranslateMessage(), DispatchMessage()` loop with `app.exec()` and you're done in most cases. The widgets can then be ported one-by-one. It's fairly straightforward in most cases. – Kuba hasn't forgotten Monica Aug 27 '18 at 17:01
  • @Kub: I'm referring to functionality, *that works*. Qt cannot deliver in that department with respect to its GUI implementation. While `DispatchMessage` works, `app.exec()` simply doesn't. Occasionally, Qt will drain the message queue, and replay those messages later. At that point, `GetMessageTime` will no longer return the desired value, neither does `GetKeyState`. Likewise, `GetTouchInputInfo` in response to `WM_TOUCH` will also fail. And while you think that I were to *"have some anti-Qt bias"*, that's incorrect. I have a strong bias against *any* library, that cannot deliver. – IInspectable Aug 27 '18 at 18:42
  • @IInspectable I omitted to mention that the app has to run on macOS as well as Windows. Looks like I'm going to have to break it down into stubs and test piecemeal. – Pierre Aug 27 '18 at 21:43
  • If you want to target Windows as well as macOS, you should evaluate your options first. Qt certainly is an option, one that is fair to all of your customers, as it doesn't favor any one user based on their choice of OS. It simply sucks on *any* OS. Qt is a full software solution, that tries to replicate the *entire* GUI stack of any supported target platform. Personally, I would always opt for a "native" GUI toolkit, one that wraps the native implementation, without attempting to rebuild it. Qt is really geared towards a wider range of target platforms (Windows, Apple, Android, Linux, etc.). – IInspectable Aug 28 '18 at 08:33
  • @IInspectable 500KLOC, one guy doing full-time enhancements/development/maintenance/support/marketing. How do you propose one go about converting to "native" macOS? Rewrite every line in ObjectiveC? What is your experience with Qt? I'm all ears :o) – Pierre Aug 28 '18 at 16:14
  • I wasn't suggesting to rewrite all of your code to use the native programming infrastructure. I was suggesting to use a native mode toolkit, that wraps platform-specific infrastructure behind a cross-platform interface (like wxWidgets). When instantiating a widget, the code will create a native control for you. Contrast that with Qt, that doesn't use any native controls on any OS, but rather reimplements all of them in code. One of the reasons for its unreliability and general sluggishness. – IInspectable Aug 28 '18 at 16:24
  • @IInspectable Thanks for the feedback. I will make careful note. I'm still interested in what Qt projects you have worked on. – Pierre Aug 28 '18 at 18:24
  • Lots of pro-Qt, anti-wxWidgets comments here: https://news.ycombinator.com/item?id=4216832 – Pierre Aug 28 '18 at 19:15
  • All of the projects have been Windows only, one of them essentially a rewrite of an existing MFC application, so that's a good baseline for comparing UI quality. In contrast to MFC, Qt fails in lots of places: Button states aren't reliably updated, leaving buttons highlighted, even when the mouse has moved outside; poor rendering performance; intermittent loss of keyboard input; perceptible sluggishness with touch input; etc. The (commercial) support was underwhelming as well. Not a single bug I reported was fixed (bug reports are still open, most of them flagged as *"Important"*). – IInspectable Aug 29 '18 at 18:28

1 Answers1

0

If "how to facilitate this" means "how to change Windows executable entry point" then in VS project settings: "Configuration Properties > Linker > Advanced" put in "Entry Point" this "mainCRTStartup".

If you need to do that from command line then check this: Replacing WinMain() with main() function in Win32 programs

c-smile
  • 26,734
  • 7
  • 59
  • 86