Porting application from Qt

[alawrence]

I stumbled upon your project and watched some of your videos on your YouTube channel. I was impressed with what you presented.

I am currently building (using C++) a new kind of general-purpose data management system called 'Didgets' and I have used Qt as the interface for its Admin tool (DidgetBrowser). The system is designed to replace traditional data managers like file systems, relational databases, and many of the NoSQL solutions. So far, it has some very impressive benchmark results.

I have used Qt since version 4.7 and upgrade every once in awhile, but I think my application uses most of the features of Qt that have been around a long time (tabbed windows, lists, dialogs, tree views, etc.) I am trying to determine how much trouble it would be to try and get my application running using CopperSpice instead. I don't know if I use something in Qt that is unavailable on your platform. You forked from Qt, but it is unclear if CopperSpice has implemented features that might be new to Qt version 5.

You can see a few demo videos of my application running on my YouTube channel:
https://www.youtube.com/channel/UC-L1oTcH0ocMXShifCt4JQQ
I am interested if you think this application would be a good candidate for porting to CopperSpice. If so, what benefits do you think it might give it?

[barbara]

I stumbled upon your project and watched some of your videos on your YouTube channel. I was impressed with what you presented.

Thanks. We do our best to provide good information and it is nice to know people find it of value.

1

I am trying to determine how much trouble it would be to try and get my application running using CopperSpice instead.

We have both API and Overview documentation for CopperSpice. The CS Overview docs cover the information about how to get started, downloading pre-built binary files, building from source, migrating to CS, etc. Here is a link to the docs you might find of value.
https://www.copperspice.com/docs/cs_overview/main-migration.html

Each time we assist a project with migration or hear about someone who made the move on their own, we gather information about the process. The docs are maturing and we will happily add whatever else you find.

2

I don't know if I use something in Qt that is unavailable on your platform. You forked from Qt, but it is unclear if CopperSpice has implemented features that might be new to Qt version 5.

This is a great question and very well worded. The CS libraries have been enhanced to include many of the classes found in Qt 5, although most of them have been adjusted to use modern C++ features. We have also improved all the containers, JSON classes, and algorithms. QString has gone through a full rewrite and uses UTF-8 rather than UCS-2 ( commonly thought of as UTF-16 which is not exactly correct ). We do have a QString16 for when this is required. Other classes which are new in CS include QRegularExpression, QStringView, and QStringParser.

If there are any classes you fine that are missing in CS please let us know. The CopperSpice team is dedicated to providing a good library while maintaining the ideas of open source software.

Barbara

[alawrence]

Thanks for your reply.

As a startup, resources are very limited so I try to get a good idea how much effort something will take and what the possible benefits are before I begin. I guess I was looking for some success stories where someone ported an application similar to mine from Qt to CS and related their experience. How long did it take? What are some areas that gave them trouble? How did their application behave differently after the port? Those are the questions I have in my head as I consider it.

Speed is of utmost importance in my application. I built the database functions to be significantly faster than conventional databases, for example. If the interface slows things down that is a real issue, but if it speeds them up that is a definite positive. My database queries are about 4x faster than the same data set in SQL Server, PostgreSQL, or MySQL (without needing separate indexes) so speed is my main selling point. The same is true for my file system metadata handling that is thousands of times faster than conventional file systems.

I am not a Qt expert like I am for the data management layer, so I have had to learn things as I go. One area that is giving me fits is paging using the fetchMore mechanism in Qt. If I query a large DB table (e.g. 10 million rows) and the result gives 200K rows (displayed in a QTreeView), I want to be able to quickly jump up and down the rows. Right now, I have to scroll down a page at a time which if I have sorted alphabetically can take a long time to get to the letter M rows. The same is true for other kinds of lists I display (e.g. list of 50,000 photos, or 300,000 documents).

Does CS use the same MVC mechanism as Qt? Have you made it easier in any way to jump down the list when it is very long? Maybe Qt has an easier way to do it than I am doing it, but I have not discovered that.

Thanks in advance for any feedback and/or advice.

[janwilmans]

I am interested if you think this application would be a good candidate for porting to CopperSpice. If so, what benefits do you think it might give it?

Let me first say I may not be objective, because I'm a copperspice team member. That being said I'm also a user and I've used the PepperMill tool to convert a sizable application from Qt4.6 to Copperspice.

Being on Qt 4.6 I did not miss any features or classes moving to Copperspice. Aside from CMake changes and few tweaks to the application it worked out of the box.

The effort was a few days of work, most of which were manual cleanup of obsolete macro constructs.
Benefits may include a much more C++ centric programming model, which means:

• while the classic Qt API's are still available the internals of all containers have been upgraded to be compatible with the algorithms from the standard library.
• the signal/slot mechanism was redesigned to preserve type-safety, so it is less error-prone, as many errors that would previously manifest only at runtime are now detected at compile time.
• no upkeep costs and no runtime licences are needed, however, paid support is available on request and is appreciated.
• the project is under a LGPL 2.1 license, so you can license your program any way you want.
• QString changed from UCS-2 (which looks like utf-16 but is not) to UTF-8 this helped a lot because it means you don't have to deal with the oddities of the UCS-2 encoding. You can now forget the encoding and the string behaves 'as you would expect it'.

Let me know if you have any specific questions.

Jan

[ansel]

I am not a Qt expert like I am for the data management layer, so I have had to learn things as I go. One area that is giving me fits is paging using the fetchMore mechanism in Qt. If I query a large DB table (e.g. 10 million rows) and the result gives 200K rows (displayed in a QTreeView), I want to be able to quickly jump up and down the rows. Right now, I have to scroll down a page at a time which if I have sorted alphabetically can take a long time to get to the letter M rows. The same is true for other kinds of lists I display (e.g. list of 50,000 photos, or 300,000 documents).

Does CS use the same MVC mechanism as Qt? Have you made it easier in any way to jump down the list when it is very long? Maybe Qt has an easier way to do it than I am doing it, but I have not discovered that.

Thanks for raising this question. Performance for large data sets is generally better in CopperSpice since we use the C++ standard library containers which tend to be better optimized for the platform and do not incur the overhead of copy-on-write. The MVC mechanism in CS has not fundamentally changed, but the signal delivery which is used heavily in this area has improved runtime performance.

We highly encourage you to try the migration process and we will fully support you along the way. If you find something which may help others, we are happy to add it to the migration documentation.

If you have ideas for how we could improve CopperSpice to better support your use case we would be very interested in your input. We look forward to working with you.