Important: Please read the Qt Code of Conduct -

Alternatives to 'QProgressDialog'

  • Greetings.

    As before, I'm working on a project in which I use Qt and OpenCV.

    I am currently developing a dialog that (among other features) presents the user with a list of morphological operations (erosion, dilation, etc) and allows you to apply interactively on a selected image, which is displayed in a preview in the dialog.

    The problem is as follows:

    Medical images are very large (3000 * 4000) and some of the operations take longer to complete a lake (several minutes). So, I thought of putting some widget that tells the user that the operation is being performed, so that the application does not freeze during that time.

    However, the only widget I've seen used for this purpose is the 'QProgressDialog', but this really does not help me since I have no way to know the level of progress of an operation being applied on the image. For example:

    Once invoked the morphological functions of OpenCV as cv::erode () or cv::dilate (), there is no way to know the level of progress of the operation ... you can only wait for the function to return.

    So, for the QProgressDialog is not the most appropriate. The specific question is:

    What alternative to 'QProgressDialog' exist for this task?

    I thought that the ideal would be to place a widget as a small hourglass or or some other like that telling the user to wait for it to complete the operation.

    Thanks in advance for any responses and / or comments.

  • If you set:
    then you get the progress barr like "In progress..."

  • I think it is unacceptable nowadays to have operations in a computer program take several minutes without the user either being able to continue working, nor giving progress information. Also, please note that you should never perform such operations in the main thread. It will block your GUI, and make your application seem unresponsive.

  • Not to mention good old windows will grey out your application window, put a neat "not responding" label on it and kindly offer you to terminate it.

    Believe it or not, but top tier applications are still locking up the main thread. I recently experience such stupidity courtesy of industry leader Autodesk - some genius decided to put the UI and the viewport rendering in the same thread, resulting in a almost entirely non-responsive UI in scenes that are heavy on the viewport. It is certainly a great pleasure to work with an application, whose heavy UI runs at 0.1 FPS. It requires patience to wait for a drop down menu to show.

  • Thanks for your answers.

    I understand what he says Andre and utcenter. The parallel execution is another problem I'm working on, and I've been thinking about using TBB (since OpenCV can be built with support for this library) and multithreaded processing classes Qt itself.

    However, I should clarify: The dialog that I am developing part of an application of digital pathology (a project of the University). It is a modal dialog, so it blocks the application.

    On the other hand, I think that even if you use multiple processing threads to perform tasks faster, I still have to provide some widget that indicates that an operation is being performed (although this is not shown for a long time ... if parallelization accelerates execution of the operations). Also, if the application is running on a computer that does not have a multicore processor, some operations may take time, right?.

    I just started reading about 'QCursor', but not if I could be of any use.

    Again, thanks in advance for any help

  • That is right, your main (UI) thread should spend its time doing almost nothing while the worker threads sweat and send progress updates to the main thread.

    You don't really need extra cores to run extra threads, you can still keep the UI thread free and responsive, and use another thread for computation, of course if you have only one core it doesn't make sense to use multiple worker threads because there will be no performance increase, but that is a whole different scenario than keeping the UI thread responsive.

Log in to reply