Porting old Win32-based Application to Multi-OS capable Qt4 app

Hi people,

I've been given the task to port a relatively complex Win32 MFC based application to Qt4 which is supposed to be able to run on both Linux (32/64-bit) and Win32. I personally have never programmed under Windows and therefore have trouble identifying possible improvements that I could do instead of copying the old code as far as I can.

The application will drive (or presently drives) a robot. We want to get better control over the timing, integrate OpenGL simulation/visualization, and a networked client. The current implementation has a shared memory segment, and multiple threads. Most of the constants interesting to the robot (e.g. gear ratios, etc.) are "#define"s, and the SHM is implemented as a bunch of structures accumulated in one large structure and accessed via pointer like this:

Code:

---

m_pSharedData=::MapViewOfFile(m_hMap, FILE_MAP_WRITE, 0, 0, 0);

---

Now I wonder if anyone here has some good tips in porting the software to Qt4. It is supposed to have a GUI interface. In terms of Software Design, does it make sense to separate the GUI functions (e.g. QApplication) from the actual drivers/low-level programming? Because in the current version, the event called from a, say, button, directly interacts with the electronics. In my opinion, this leads to the fact that the control code is distributed all over the code base and right now it's pretty hard to discern what function does what. Would it be clearer if I created some "robot" class that contains all the driving code, etc.?

I am really open to suggestions and if Qt has a really cool class that does exactly what I want or provides means to make life so much easier without me having to re-invent the wheel, I would be very thankful. For example, I've read that there is something called QtConcurrent, which seems to be an easier choice that QThread, but I don't know...

Thank you very much in advance.

Stephan

Quote:

---

Originally Posted by sfabel

In terms of Software Design, does it make sense to separate the GUI functions (e.g. QApplication) from the actual drivers/low-level programming?

---

In practically all cases I'm aware of: Yes. It's always wise to separate out code that provides GUI functionality from the actual data logic, which is also done in the Model/View framework Qt provides. Aside from that, you could choose to redesign your user interface. If the application has the driving logic and the GUI code in the same place, you end up rewriting functional parts of your code while you only have to tackle the GUI. The other way around, you will have to work in your GUI code where it only involves data logic. Worst of all is going to be when you have to build a command line client. In my opinion you should approach every GUI application as a command line program with a graphic shell.

Quote:

---

Originally Posted by sfabel

For example, I've read that there is something called QtConcurrent, which seems to be an easier choice that QThread, but I don't know...

---

Indeed. I have the impression that the QtConcurrent classes work best when you have a lot of queueable tasks. You say that you want to gain more control over threading. In that case I think you should go for QThread and the other threading primitives, rather than QtConcurrent. Remember that you can only have one GUI thread in Qt.