Using Qt for POS system?

nickname · wrote on 25 Dec 2011, 19:13

We are about to develop a POS (Point Of Sale) system as a "SaaS", and have started to think Qt might be a good choice.

Some main features required to be supported:

Fully touch enabled (for the tills)
Running both Offline (i.e no Internet Connection) and Online (with sync when connection comes back)
Can be run as a Web application in the browser (no native app support needed)

Pros as we see it with Qt for this:

Very flexible language, with lots of libraries available
Great community to discuss and get answers
Rapid updates

Con:

We have no C++ developers in the team (yet), only PHP/Python so there would be a learning curve to climb

Should we consider Qt for this?

Not the most info for a decision to be made, but should be enough to give us a gut feeling on whether to consider Qt or not.

goetz · wrote on 25 Dec 2011, 23:53

Although there is a Qt browser plugin (or at least there used to be - I don't know the current state), I would not recommend this for a mission critical solution.

As you're after a web application in the browsers, Qt could be of use on the backend (server side) only, but not for the frontend.

If you don't have a decent C++ developer at hand, chances to fail are not small.

While im a Qt advocate, naturally, I wouldn't recommend Qt without limitations under this circumstances.

Regarding the other two main features:
The touch enabled device is more an aspect of the operating system and the graphics system and drivers. Basic touch features like clicking etc., should be supported by nearly all devices and OSes nowadays. Zooming gestures like on iOS/iPhone is a bit more problematic.

The online/offline sync is part of your business logic, you will have to develop that yourself, I would say. But if you need that and your frontend shall be a browser based solution, you will most probably need some proxy-server solution on the client machine to achieve this. I'm not that deep into browser applications and not sure whether you have some offline storage there and whether it's a good approach to use a browser app to do the online/offline sync.

010110102 · wrote on 27 Dec 2011, 02:12

If you have some skilled python programmers you could look into "PyQt":http://www.riverbankcomputing.co.uk/software/pyqt/intro
Thats all the advice I can give for the moment. Without C++ programmers your chances are pretty small.

sakshisyan · wrote on 27 Feb 2014, 05:22

Hmm, Great!
Thanks for sharing it!!

martin_ky · wrote on 27 Feb 2014, 06:41

I can attest to a successful creation of a POS UI system using Qt for one of my clients. We had no prior knowledge of the Qt toolkit, although I was already quite decent C++ programmer at that time. I can really recommend Qt for the UI parts. Qt's documentation is superb, community helpful and there is a lot of materials on the net. However, there is still a learning curve, even for an experienced C++ programmer; for me that was a couple of months to become really efficient with Qt. That is mostly because Qt uses some concepts and idioms not seen elsewhere, that take some getting used to. But after that, the development can be very rapid.

I made only the UI frontend in Qt for a pre-existing backend java server. The first challenge was the communication between the java server and the Qt UI parts. We used XML messages over a plain TCP socket. While Qt has decent XML support, it does not do XML serialization out of the box. There are surely more elegant ways to do communication in a heterogenous programming environment.

The second challenge was to write "drivers" (or controllers) for various attached POS devices, such as barcode scanners, magnetic card readers, fiscal printers, etc. While there is a software stack called UPOS to help with the devices, it only for certain versions of Windows, and not all devices even have UPOS drivers. So we decided to roll our own drivers for commonly used devices. This proven to be quite easy, as these are mostly devices attached to a serial port and use very simple protocols to communicate.

I'm not sure about the "SaaS" part. As I mentioned, a Point of Sale system usually makes heavy use of various attached devices. I can't really imagine using those devices with the SaaS approach (eg. a web application running in a browser getting input from a barcode scanner).