Submitted by evolver on Sun, 06/22/2008 - 22:11. General Questions
I have an old Motif application that is about 10 years old. Upon start, it performs data manipulations before it pops the first window and goes into XEvent processing loop, which effectively make application interactive. In 10 years, the data set grew substantially. It was taking 10-15 seconds to go through the initial "data preparation" process but now it may take up to 5 minutes. It gets very annoying if you have to wait for 5 minutes with no interactive feedback. I want to add a progress indicator of some sort that would be able to report some milestones of the initial "data preparation"; thus, making user experience more entertaining.
The problem I'm facing is that I cannot manipulate Motif GUI until XEvent processing loop kicks in. I cannot create a window, force it do draw itself with all the widgets, and then to update it periodically from my data processing logic.
So, I have two fundamental problems:
1. I don't know if it possible to update and visualize widgets outside of XEvent processing loop. I tried to play with XmUpdateDisplay() but it only shows the window with decorations, including title, but none of the child widgets. Is there a way to force it to redraw the child widgets?
2. Is it possible to spin off a new thread that would handle events specific to this window alone? I would just run XtAppMainLoop() in this thread. I tried that but threads of my test application get stuck in XtRealizeWidget() call. Does anybody have an example of how to write a Motif application where more than thread processes events for individual windows?
Thanks,
/Sergey
I only have one general advice and one partial answer.
First, as a developer, you have a choice of what do you spend your time on. You can spend it on making progress bar behaving properly, or on actually optimizing your application.
Assuming your init algorithm is linear O(n) with respect to data, I think it is unlikely that your data set grew so much faster than the processor and hard drive speed. Your response time grew 20 times, while processor speed grew at least 20 times in the last 10 years. So your data set must be 400 times bigger?
Or there is some really sloppy code in the init, which nobody taught was that important at the time.
If I were you, I would rather compile the application with profiler and fix the actual bottleneck.
On the other hand, I am not against progress bars as a concept. All you need to do is to divide your initialization in smaller chunks, for example call it with XtAddTimeout and let the work function call itself until it is finished.
If you leave some time within the XtAddTimeout, the interface will have time to redraw itself between your busy loops.
I know, sometimes it is hard to do. I have such a case, when my code displays progress during ftp download or upload. In this case, I first pop-up the progress window, and only then start the operation. For showing progress, I do not use Motif functions, but rather simply draw increasing filled rectangles in a drawing area with Xlib calls.
These bypass the Motif/Xt interface main loop and get drawn immediately (as the X server processes the requests). Works good enough, if user does not manipulate windows while the process is going on.
dpeterc,
I share your opinion about more effective algorithms. The root cause of the problem is an ineffective algorithm. This issue stands out with the new bigger set of configuration data. The group of engineers looks at two things at the same time, performance improvement as well as providing more interactivity with the user. The latter is more of a safety harness if the former does not get us far.
Thanks!
Look at the XmtWorkingBox widget in O'Reilly Volume6C
hello Sergey,
i would suggest you writing balloon help for X/Motif applications under X Window System. In many graphical applications you probably noticed, when the mouse pointer is moved over a graphic button and if the pointer remains on the button for a short period of time, a small rectangular window pops up with a one line help message. This kind of help is known as balloon help, bubble help or quick tip. Quick tip is particularly helpful for push buttons with graphic bitmaps, especially if the bitmaps are not very obvious. If you are a X/Motif programmer, you may have thought about adding this kind of help to your applications but was not quite sure how to do that. I can describe you also how to write balloon help for X/Motif applications. A C routine Qtip() (stands for Quick tip) with source code, documentation and examples is also supplied. This routine can be used to add quick tip to any X/Motif application.contact me with any questions