When launching an embedded Qt application by specifying the directfb back-end, there is a way to pass arguments to it by using a specific syntax
./my-qt-app -qws -display directfb:960x720
This will change the resolution.
Let's say I'd like to remove the chrome from the application window. Since directfb has lots of options, how could I specify them via command-line? Should a look for the internal Qt implementation or use CLI arguments as specified by the DirectFB project?
UPDATE although there is a mechanism using colons to pass arguments to the
display back-end, in the directfb case it won't work for resolution changes.
Best way to pass multiple arguments is to use the standard directfbrc mechanism, usually located under /etc or the directory determined by ${DFB_CONFIG_DIR} environment variable.
Also noticed later that things like the application window chrome are set inside Qt itself, not DirectFB.
As #milton answered one place is /etc/directfbrc and the other way is for example:
./app --dfb:window-surface-policy=auto
you can pass help to get all the commands:
./app --dfb:help
Related
I'm trying to make QT render to an image in a headless environment. I did it by passing a command line argument --platform offscreen. I prefer to do it programmatically but couldn't find any documentation. Does anyone know some way to do it?
I'm trying to run a very simple program that just closes the window when clicking the `exit button, but get the following output provided that the application window that contains the button does not show up:
Starting C:\Users\Ola\Desktop\signal_slot1-build-desktop-Qt_4_8_1_for_Desktop_-_MSVC2008__Qt_SDK__Debug\debug\signal_slot1.exe...
Qml debugging is enabled. Only use this in a safe environment!
What should I do in this case?
You have enabled QML debugging (actually it's on by default), this opens a port to the Javascript interpreter that is running the QML so you can get debug output from it. Obviously this creates a security hole, so it should be turned off when not being used in safe place (it's turned off automatically when you release compile). This warning is to remind you of that.
If you are not using QML, turn it off anyway. You can turn it off in the project's options page, where the build settings are (it's a check box in the qmake area).
Assuming you use Qt Creator:
If you select the Release-Build type the QML debugging will be disabled. To do this, select the build type on the bottom left corner above the "run" button and choose "release".
Manually, there is an option passed to qmake (either in the .pro file or via command line arguments) named
CONFIG+=qml_debug
which enables qml debugging.
If you omit that, it should be disabled.
You can change it to release mode if you want to and that would solve the problem
but I recommend you to change between MSVC and MinGW and check which one is going to work.
Project->Build and Run-> and choose what you need.
Gtk programs can have different keybinding themes by binding different keys to gtk signals, but afaik, qt programs cannot do that now.
Since Qt support plugins (as most of this kind of library do, and what I mean here is High Level Plugin or Qt Extension) and at least some of them (High Level Plugins) can be loaded automatically by all qt programs according to sth like ENV, is it possible to have global (Emacs or other style) keybindings (at least in all input area) using qt plugin? Or in an other word, does anyone know which kind of (High Level) plugin this should be?
My guess is a inputcontext plugin or a accessible(bridge) plugin.
For input context plugin, I wonder if this can work with input method since afaik only one inputmethod backend can be enabled at one time.
For accessible plugin, I haven't find out how to make it loaded automatically.
Thanks.
You could install an event filter to intercept key events, and use that to convert them to other events.
I think you're using the word "plug-in" in a different sense to Qt. It has various specific plugins -- for image codecs, SQL drivers, etc -- but no general-purpose "do this to all widgets" mechanism. For that, you would have to catch all the creation-points of the top-level widgets in your application and add code to install the filter for each case.
I somehow solve the problem (along with this one) using xkb, i.e. redirect C-npfbae to proper keys, although I haven't made C-d redirection compatible with terminal EOF.
I still think the problem (in Qt) can be solved with qtaccessible plugins but I haven't find out how to make that work.
I need to trigger a phone call from a Qt application. I looked to previous post without find a complete answer.
I need to make it with qt 4.6.3. I'm quite new to symbian development, I'm using the last nokiaSDK.
It MUST work ONLY on n97 and E71.
Can Anybody provide a solution?
May be a solution exec an extenal process using QProcess?
It seems like currently none of Qt APIs (including QtMobility) allows to do it. However, you can use native Symbian C++ API - CTelephony class. There are some examples showing how to make a phone call using this class. The obvious disadvantage is that it won't work on any other platform than Symbian.
You may be interested in this example: http://library.forum.nokia.com/topic/Qt_for_Symbian_Developers_Library/GUID-B4DA6005-3037-4FF8-82D5-BA748532E648.html#GUID-B4DA6005-3037-4FF8-82D5-BA748532E648. It shows how to mix Symbian C++ code with Qt code, and it also uses CTelephony, so you just need to change method call from GetPhoneId() to DialNewCall(). Don't forget to add appropriate library (etel3rdparty.lib) in your .pro file.
Excusing the actual folders used as an example, I want to achieve the following two widgets in Qt (the backend is similar to files, but not exactly filesystem files):
folder-replace-dialog and copy-file-dialog
I know Qt can do the native save-file widget (using QFileDialog static methods), but can it do the folder replace/file copy dialogs as well? Any suggestions?
You might have to call the Windows SHFileOperation directly for this. It should be possible whether your using gcc or the MS C++ compiler. You'll need to fill in the SHFILEOPSTRUCT but that shouldn't pose too much of a problem.