@Iftekhar
Before you get that far, I would completely rethink your class Sprite : public QTimer class. Subclassing should be thought of/subject to the "is-a" test: is a sprite a (kind of) timer?
A sprite is an object you draw, which maybe has a position which changes over time. You have it as an instance/subclass of a QTimer, with a draw() method to draw it. This seems completely unsuitable, and the wrong way round. If anything a sprite should be a QWidget or a QObject, perhaps with a QTimer as a member; or the QTimer might be better external to the sprite.
void MainWindow::paintEvent(QPaintEvent *)
{
QPainter painter(this);
// ...
emit draw(painter);
}
I don't think you should be emitting any signal here, nor pass it a QPainter.
I think I would just have a list of all the ball-sprites in existence. A single QTimer which, each time it ticks, causes code to go through the list and update the positions of every sprite. (Unless you want accuracy/timing/movement on each ball separately, so they don't all move at the same time: in that case you might put a QTimer into each sprite, but it would not be my inclination.) You can then also use that same timer to cause a new sprite to be created and added to the list, by checking if the current tick is at one of the "regular intervals" for creation. Or, if you prefer, have a second timer ticking just for new ball creation. We end up with either one QTimer or two, no matter how many sprites there are.
If your whole objective is to have an area showing a number of "balls" moving around, I would be tempted to change over to using a QGraphicsScene + QGraphicsView. Then your Sprites can be subclassed from QGraphicsEllipseItem. You can then create, remove and move them easily.
I could also mention the possibility of using QAnimation to automate smooth movement of objects; but that may be a step further than you want.
