I tried very hard. But, still am not satisfied with the implementation. And now am feeling helpless.
If I set set, fixedsize for QLabel, then scroll bars won't appear if I use zoomout/zoomin.
My question is why QLabel won't shrink back after changing size through Qsplitter. I tried all the combinations of sizepolicy and nothing has worked so far
I wasn't able to do it with QGraphicsDropShadowEffect, and creating all images twice and including them in the rcs-file is simply a no go.
Therefore I create a function, that draws a shadow - all 4 sides - around the the QImages, either at startup or during runtime.
Here it is, in case anyone else needs something like it.
QImage drawShadow(QImage img)
//Condition img allready has a transparent border 4 Pixel in this case
//Create new Img with same Size
QImage imgBGround(img.size(), img.format());
//Fill it with transparency
QPen pen; pen.setStyle(Qt::NoPen);
p.fillRect(QRect(0,0,img.width(), img.height()), QColor(255,255,255,0));
//Draw Rounded Rectangle as Shadow
//Draw Original Img over background
QPainter can draw a QImage. So you can for example create a new Widget, subclass for QLabel for example if you want and reimplement paintEvent. Like this you work all the time with your QImage without creating another one.
And better you can only update the region that changed, no need to refresh everything. I did not try it but it should work.
Thanks for the reply. This is using intel graphics, and unfortunately your workaround does not help. After your message, I've tested the same code from a newer live image and also on my more up-to-date laptop (which has similar hardware) and I can not reproduce the issue in either of these cases. On the affected machine, I tried updating the intel driver and mesa, but this did not solve it, so I guess it probably needs the kernel or qt packages updated as well. Unfortunately, this is not an option at this point.
I've worked around the issue by re-implementing paintEvent() to do something like the following
Which seems to work just fine. In fact, re-implementing the paintEvent has given me the chance to animate the image changes which looks pretty nice, and it will be easy to simplify the code a bit when all my machines are fully updated and the glitch is gone.
Okay, so I studied @Chris-Kawa's answer again. And what hit me like a bolt of lightning is that what I was dreaming of doing is virtually nonsensical. Now I really understand what he was saying.
This is what I wished to make happen (when I was naive :D):
The background timer's timeout event, issues an update() command which draws immediately into the screen (like magic), which in turn, triggers a ~17ms single-shot timer.
When that timer's timeout occurs, the text shown on the screen is cleared immediately (again magic).
This keeps on looping till the user stops the background timer.
This is what actually happens:
Issue an update() command that "draws" the text (text is NOT shown yet). The single-shot timer (@~17ms) is triggered.
...probably some milliseconds elapsed (let this be x ms).
At the vertical refresh moment, text becomes visible on screen. (this is damn fast, so I'm ignoring this interval)
...probably some milliseconds elapsed (let this be y ms)
The single-shot timer has ended after ~(x+y) ms and a command to clear the text has been issued.
...probably some milliseconds elapsed (let this be z ms).
At the vertical refresh moment, text is cleared from the screen. (ignoring this interval again)
So, the user sees the text for about (x+y+z+k) ms where, k is the sum of the additional milliseconds used in actually doing that stuff. Now, x+y+z+k ms is almost always not equal to the desired interval.
That's why, this process sucks, big time.
Now, this is the best that can happen:
Wait for the background timer to end. After it ends, as soon as a refresh cycle occurs, issue the command to draw the text.
At the next refresh cycle, the text will be drawn to the screen. After the text is drawn, start the single-shot timer.
After the timer has ended, issue the command to remove the text. Wait for the next refresh cycle.
At the next refresh cycle, the text will be removed from the screen. Now, start the background time. Now go to the first step.
Visualizing the process,
Now, it is evident that showing the text exactly for 15ms is impossible using the previous method. But at least we can make sure that we don't show that more than ~32ms. And that's good news. At least in my case.
Now, the point is how to achieve that. I don't know. But I'll find you and I'll kill you, nay implement you.
Thank all for your replay,
I solve my problem by using Phonon: :video player
i. Add Phonon::Video Player in ui file. I rename its programing name as "Video Player"
ii. Add one button in that ui file and go to that button slot and adding following code in it:-
// For getting system date and time for video name
time_t now = time(0);
struct tm tstruct;
tstruct = *localtime(&now);
strftime(buf, sizeof(buf), "%d_%m_%y_%H_%M", &tstruct);
qDebug() << "Date and Time: "<<buf;
// For getting static path where video will be stored
QString a = "/home/Working_QT/BackupErrorWorking/DeviceTestVersion1/video/";
qDebug() << "a: "<<a;
// For giving comlete command as it is accepted as a QString and converted into char(Because konsole command is accepted only char it shows error so we convert it)
QString command = "ffmpeg -f video4linux2 -i /dev/video0 -vcodec mpeg4 -b 500k -r 25 -t 00:01:30 ";
qDebug() << "Command: "<<command;
strcpy( x, command.toStdString().c_str());
// Commaand to sysytem
qDebug() << "Command given to system to capture video and name it according to that particular date and time: "<<x;
// For playing video through Phonon VideoPlayer
qDebug("Before video recording display");
qDebug("After video recording display");
iii. Included #include <time.h> // Required for giving video file name according to date and time
and #include <qdebug.h>
iv. Make changes in .pro file
PixmapItem indeed seems to have been created for that exact purpose, whereas ProxyWidget is more useful (as the name implies) for embedding a widget inside the scene. One drawback though, I did not knew about its existence while implementing the interactive pointer. Plus it will take me a while to implement it because I cannot directly take textPointer and use it as is in a PixmapItem. I definitely want to implement it later on though, probably as soon as I finish with undo/redo functionality.
I am glad you did not see the delete statement because that way I learned something new. Not to mention that the code is more simple this way.