I'm writing a quick&dirty number crunching test, using a Qt console application.
It prints several thousand lines, but the number of lines displayed in the console seems to be limited to about 300. This means that at the end I can no longer scroll back to the beginning of my printout.
How can I raise this limit? I found nothing in the project settings.
Or is it completely impossible, as the console window is controlled solely by my operating system?
It's important for me to launch the program directly from Qt creator, so a solution where I use a batch script or similar trick to run my program is not preferable.
Does a solution even exist, or am I forced to switch to a Qt GUI application where I create my own console out of a QTextEdit widget?
The number of lines displayed and the number of lines in the buffer is a property of the operating system. You can change this. How to do this depends on your OS.
Related
I am trying to show a progress in the taskbar of the plasma desktop using the KDE Frameworks. In short, it want to do the same thing as dolphin, when it copies files:
I'm kinda stuck, because I don't even know where to get started. The only thing I found that could be useful is KStatusBarJobTracker, but I don't know how to use it. I could not find any tutorials or examples how to do this.
So, after digging around, and thanks to the help of #leinir, I was able to find out the following:
Since Plasma 5.6 KDE supports the Unitiy DBus Launcher-API, which can be used, for example, to show progress
I found a post on AskUbuntu that explains how to use the API with Qt
The real problem is: This only works, if you have a valid desktop file in one of the standard locations! You need to pass the file as parameter of the DBus message to make it work.
Based on this information, I figured out how to use it and created a GitHub repository, that supports cross platform taskbar progress, and uses this API for the linux implementation.
However, here is how to do it anyways. It should work for KDE Plasma and the Unity desktop, maybe more (haven't tried any others):
Create a .desktop file for your application. For test purpose, this can be a "dummy" file, that could look like this:
[Desktop Entry]
Type=Application
Version=1.1
Name=MyApp
Exec=<path_to>/MyApp
Copy that file to ~/.local/share/applications/ (or wherever user specific desktop files go on your system)
In your code, all you need to do is execute the following code, to update the taskbar state:
auto message = QDBusMessage::createSignal(QStringLiteral("/com/example/MyApp"),
QStringLiteral("com.canonical.Unity.LauncherEntry"),
QStringLiteral("Update"));
//you don't always have to specify all parameters, just the ones you want to update
QVariantMap properties;
properties.insert(QStringLiteral("progress-visible"), true);// enable the progress
properties.insert(QStringLiteral("progress"), 0.5);// set the progress value (from 0.0 to 1.0)
properties.insert(QStringLiteral("count-visible"), true);// display the "counter badge"
properties.insert(QStringLiteral("count"), 42);// set the counter value
message << QStringLiteral("application://myapp.desktop") //assuming you named the desktop file "myapp.desktop"
<< properties;
QDBusConnection::sessionBus().send(message);
Compile and run your application. You don't have to start it via the desktop file, at least I did not need to. If you want to be sure your application is "connected" to that desktop file, just set a custom icon for the file. Your application should show that icon in the taskbar.
And thats basically it. Note: The system remembers the last state when restarting the application. Thus, you should reset all those parameters once when starting the application.
Right, so as it turns out you are right, there is not currently a tutorial for this. This reviewboard request, however, shows how it was implemented in KDevelop, and it should be possible for you to work it out through that :) https://git.reviewboard.kde.org/r/127050/
ps: that there is no tutorial now might be a nice way for you to hop in and help out, by writing a small, self contained tutorial for it... something i'm sure would be very much welcomed :)
This seems a rather silly question: but I can't find (for more than an hour) now a button to "reset" all standard windows.. I accidentally closed quite a lot of them during a crash. (Especially the "command window" and the signals-in-region during simulation seem to be gone permanently).
From "ModelSim User’s Manual, v10.1d", appendix F:
Most user GUI preferences are stored as Tcl variables in the .modelsim file on Unix/Linux
platforms or the Registry on Windows platforms.
You may consider to look into .modelsim, and possibly delete it, together with .modelsim.bak. The motivation for this suggestion is that .modelsim contains setup details for the layout of panes. .modelsim will (should!) be regenerated next time you open modelsim.
At the menu bar (main window), click on layout and then choose reset. Most of the windows will be reset.
I'm running a qt embedded application and mplayer, both of them on framebuffer.
When I start video playing through mplayer, I get a lot of flickers around the movie.
See the following movie:
http://youtu.be/kbKpfjLHzTY
How to fix it?
For Qt 4 with QWS,the embedded linux graphics sub-system for writing directly to a frame buffer you can run the following in a the -qws server's GUI thread before invoking mplayer,
QWSServer *server = QWSServer::instance();
if(server)
server->enablePainting(false); // Suspend Qt's drawing.
You can use a SIGCHLD or something to figure out when mplayer is finished and re-anble painting. Another way would be to position mplayer's output window and use a QWSEmbedWidget to tell Qt not to draw there.
Both QWS and mplayer open the frame buffer and draw to it directly. There is nothing to marshal access to the display device. The QWS sub-system allows multiple Qt application to draw to the screen at the same time. However, it has no control over other processes accessing the frame buffer. For this reason, X11 or other display managers like Wayland, etc can be used. This is generally the method use in Qt5.
I'm not that familiar to memory handling, but i am currently working on a Qt project (c++), developing an app for Symbian devices, using the Qt Nokia SDK.
Platform: Windows 7
1'st question:
If i create a pushbutton like this:
QPushButton *button = new QPushButton(parent);
Do i have to delete it? (I think no, since it is part of the UI, but correct me if i'm wrong).
2'nd question:
How can i find a memory leak, do you know of any good programs that can help me with this?
I've tried using Nokia Analyzer tool, but when i run atool:
atool.exe -lf build armv5 udeb -f phoneMeomoryLog
i just get
Build type: udeb Build platform: armv5 Data gathering mode: log to
file Allocation call stack size: 40 Free call stack size: 0 Deferred
free: feature disabled Heap corruption check (guard blocks): feature
disabled AnalyzeTool : Error, creating/reading makefiles.
Hope someone can answer me.
Thanks in advance
1'st question : No you don't have to delete it. It will be deleted when the parent is deleted. So you have to delete the parent which is probably a form or dialog.
When you create the dialog with Qt::WA_DeleteOnClose flag Qt deletes this widget when the widget has accepted the close event. So you will not have any memory leaks.
So create your dialog with this flag and add your widgets as you are doing now and you will be fine.
2'nd question: If you are running on linux use valgrind.
example : valgrind --tool=memcheck --leak-check=yes ./myprogramname
valgrind has many options you can use for fine tuning.
Also using *unique_ptr* or *auto_ptr* if you are using older c++ or QScopedPointer are good programming techniques to avoid memory leaks.
The answer to your first Q is No. It seems that unlike windows standard GUI Objects, in Qt you should not delete it. It is being released when your main window is being closed.
You can use microsoft's memory link detector embedded at VS. Find more in this link.
Both "It is being released when your main window is being closed." and "The parent just releases the UI resources, not the memory !!! – hsalimi " are wrong. The parent keeps a list of its children and will delete them when it is destructed itself. This has nothing to do with "UI resources" or "main window", it's normal QObject behaviour. std::auto_ptr is neither needed nor useful here either.
Well, I have no experience in Qt Nokia SDK, but based on my C++ knowledge.
Yes. Everything created by new should be later freed. A pointer cannot free itself and C++ doesn't offer any garbage collector.
There are several ways. For example, check how many new's you're doing and how many delete's. For each new there should be a delete somewhere. Check the memory used: if memory used only grows and never (or not often) decreases, then you're not handling memory correctly. Make sure you're deleting any allocated resources on destructors.
To avoid this you can use auto-pointers
My scenario here is the following: I am using a pyqt widget to display a solid color fullscreen on a second display and observe this display with a camera that is continuously capturing images. I do some processing with the images and this is the data I am interested in. This works great when used interactively with ipython and matplotlib using the qt4agg backend like so
% ipython -pylab
# ... import PatternDisplay, starting camera
pd = PatternDisplay(); pd.show(); pd.showColor(r=255,g=255,b=255)
imshow(cam.current_image)
I need a similar behavior now in a console script though: it should display the PatternDisplay widget, capture an image, than change the color on the PatternDisplay and take a new image and so on.
The problem is now that the PatternDisplay is never updated/redrawn in my script, likely because PyQt never gets a chance to run it's event queue. I had no luck trying to move the linear worker part of my script into a QThread because I cannot communicate with the PatternDisplay Widget from another Thread any longer. I tried to replicate the implementation of ipython/matplotlib, but I didn't fully understand it, it is quite complicated - it avoids running the QApplication main loop via monkey patching and somehow moves QT into it's own thread. It then checks periodically using a QTimer if a new command was entered by the user.
Isn't there an easy way to achieve what I want to do? I am gladly providing more information if needed. Thanks for any help!
What you need is easier than IPython's job - IPython makes the Qt application and the command line interactive at the same time.
I think the way to do it in Qt is to use a timer which fires at regular intervals, and connect the signal to the 'slot' representing your function that gets the new image and puts it in the widget. So you're pulling it in from the event loop, rather than trying to push it.
I've not used Qt much, so I can't give specifics, but the more I think about it, the more I think that's the right way to do it.
I solved the same problem (i.e. interactive ipython console in terminal, and GUI thread running independently) in the following way with ipython 0.10 (code here)
1. Construct QApplication object, but don't enter its event loop explicitly
2. Run the embedded IPython instance
3. Run the UI code you need by instantiating your window and calling show() on it (like here with the yade.qt.Controller(), which I aliased to F12. (I did not find a way how to ask the embedded shell to run a command at the start of the session, as if the user had typed it)
(You can also show() your window first, then run the embedded ipython. It will provide event loop for Qt.)
(BTW I also tried running Qt4 from a background thread (using both python threads module, and Qt4.QThreads), but it refuses to run in such way stubbornly. Don't bother going that way.)
The disadvantage is that UI will be blocked while ipython is busy. I hope to finding something better for 0.11, which should have much better threading facilities (I asked on ipython-users about how to unblock the UI).
HTH, v.