This KCM allows you to easily configure the standard Qt graphics system.
Please note that this requires Qt 4.7.0 or greater to work.
7 years ago
- 1.3 -
[li]Fix script creation if $KDEHOME/env directory does not exist[/li]
- 1.2 -
[li]Improve backend handling in non-X11 default cases by triggering a file write only if necessary and remove it if not[/li]
[li]More internal documentation[/li]
[li]Typo fixes by Alessandro Ghersi[/li]
- 1.1 -
[li]Detect standard backend if Qt was compiled with anything but X11[/li]
[li]Add helper application (build with -DBUILD_PROBER=ON) to check what the current backend is[/li]
- 1.0 -
[li]Initial release[/li]
7 years ago
- 1.3 -
[li]Fix script creation if $KDEHOME/env directory does not exist[/li]
- 1.2 -
[li]Improve backend handling in non-X11 default cases by triggering a file write only if necessary and remove it if not[/li]
[li]More internal documentation[/li]
[li]Typo fixes by Alessandro Ghersi[/li]
- 1.1 -
[li]Detect standard backend if Qt was compiled with anything but X11[/li]
[li]Add helper application (build with -DBUILD_PROBER=ON) to check what the current backend is[/li]
- 1.0 -
[li]Initial release[/li]
openDesktop.org :
g88
2 years ago
real homepage with docu
A way to set the Qt graphics system backend without recompiling Qt. In Qt 4.7 this is finally available.
You can configure the backend using the environment variable QT_GRAPHICSSYSTEM.
Now, since the topic of switching graphics backend in Qt is coming up now and then, I thought it would be a good idea to create a nice graphical interface. Actually I wanted something nicer to use for me personally :P
So I created a really simple KCM. You have 3 switches, of which two will write a .sh file to $HOME/.kde/env/. The content of this folder gets loaded at startup (via startkde), and that way you will globally end up with another graphics backend. That said, since the environment variable has lowest priority, it is still possible to override this on a per-application level (e.g. kolourpaint has problems with the raster backend I have been told).
Report
g99
2 years ago
Report
g99
2 years ago
so you used the "bomb" icon and bombed your X?
chose "OpenGL" ?
Now you're blinded. Great.
Here is what u can try. run
kcmshell4 qt-graphicssystem
operate it blindly:
hit alt-x (for X-render)
hit alt-o (for OK, done)
log out, startx
back to normal if you're lucky.
maybe someone will document which .config file this crap operates on. What a trash tool.
Of course, the RESET and DEFAULT buttons do absolutely nothing in this trash proggy.
You're not even told that it is not a kcmshell5 proggy. What utter trash.
Report
g99
2 years ago
chose "OpenGL" ?
Now you're blinded. Great.
Here is what u can try. run
kcmshell4 qt-graphicssystem
operate it blindly:
hit alt-x (for X-render)
hit alt-o (for OK, done)
log out, startx
back to normal if you're lucky.
maybe someone will document which .config file this crap operates on. What a trash tool.
Of course, the RESET and DEFAULT buttons do absolutely nothing in this trash proggy.
You're not even told that it is not a kcmshell5 proggy. What utter trash.
Report
g99
2 years ago
chose "OpenGL" ?
Now you're blinded. Great.
Here is what u can try. run
kcmshell4 qt-graphicssystem
operate it blindly:
hit alt-x (for X-render)
hit alt-o (for OK, done)
log out, startx
back to normal if you're lucky.
maybe someone will document which .config file this crap operates on. What a trash tool.
Of course, the RESET and DEFAULT buttons do absolutely nothing in this trash proggy.
You're not even told that it is not a kcmshell5 proggy. What utter trash.
Report
g99
2 years ago
chose "OpenGL" ?
Now you're blinded. Great.
Here is what u can try. run
kcmshell4 qt-graphicssystem
operate it blindly:
hit alt-x (for X-render)
hit alt-o (for OK, done)
log out, startx
back to normal if you're lucky.
maybe someone will document which .config file this crap operates on. What a trash tool.
Of course, the RESET and DEFAULT buttons do absolutely nothing in this trash proggy.
You're not even told that it is not a kcmshell5 proggy. What utter trash.
Report
g99
2 years ago
This stuff does next to nothing besides destroying X. Terrible.
Seems the guy never understood any letter of the word "documentation".
Report
hipsterical
6 years ago
Report
ZaWertun
7 years ago
http://download.opensuse.org/repositories/home:/ZaWertun:/kde4/
(those, prefixed with "KDE_Distro_Factory_")
Report
ZaWertun
7 years ago
http://download.opensuse.org/repositories/home:/ZaWertun:/kde4/
Report
dunemafia
7 years ago
Report
pejakm
7 years ago
Report
apachelogger
7 years ago
Report
whashnez
7 years ago
Report
apachelogger
7 years ago
Report
whashnez
7 years ago
[ 0%] Built target kcm_qt_graphicssystem_automoc
[ 41%] Built target kcm_qt_graphicssystem
[100%] Built target qt-graphicssystem-prober
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /usr/local/lib/kde4/kcm_qt_graphicssystem.so
-- Set runtime path of "/usr/local/lib/kde4/kcm_qt_graphicssystem.so" to "/usr/local/lib:/opt/qt-devel/lib"
-- Installing: /usr/local/share/kde4/services/qt-graphicssystem.desktop
-- Installing: /usr/local/bin/qt-graphicssystem-prober
-- Set runtime path of "/usr/local/bin/qt-graphicssystem-prober" to "/usr/local/lib:/opt/qt-devel/lib"
Report
apachelogger
7 years ago
You will need to install to the KDE search path (usually /usr), otherwise the desktop file will not be found and hence not show up anywhere.
Report
whashnez
7 years ago
Report
apachelogger
7 years ago
Say you have a Qt 4.7 installation in /opt/qt47 and your regular Qt 4.6 in /usr. Then you export LD_LIBRARY_PATH to include /opt/qt47/lib and hence override the standard search path /usr/lib, then every dynamically linked Qt application started with that setup will use Qt 4.7 and the option will have effect.
So it is more a question of runtime library loading rather than what an application was built against.
Report
whashnez
7 years ago
Thanks for your help and sorry for the many questions!
Report
apachelogger
7 years ago
b) Yes, generally when you do that all applications should load Qt 4.7 rather than the system one (that is: all apps that are not statically linked or have an rpath, I think rpath takes higher importance).
c) You do not want to do this globally since it can hurt stability (if/where) Qt 4.7 is incompatible with 4.6 (e.g. apps that are linked against QtMultimedia would still load that from 4.6 since 4.7 doesnt have it anymore and in the end you would have an application that overall runs on 4.7 but som parts are 4.7 due to QtMultimedia -> that can cause serious trouble).
Report
whashnez
7 years ago
Report
pejakm
7 years ago
http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/
Report
apachelogger
7 years ago
The backend basically is how widgets (i.e. buttons and textfields and icons etc.) are painted. And that how can either be a native toolkit choice, for example on Linux it will default to use the X11 API for that kind of stuff which will then take care of the actual processing. The raster engine is an own implementation of software rendering (which should be the same as X11 except that it is not as it mostly performs better). And OpenGL will, as the name suggests, directy all painting to the GPU.
So, say you use OpenGL then every button, textfield, icon... in a Qt application will be painted via OpenGL in the GPU. GPUs being specifically tweaked for graphics of course will calculate that usually super fast.
How the raster backend works is descirbed here:
http://labs.trolltech.com/blogs/2009/12/18/qt-graphics-and-performance-the-raster-engine
More information on OpenGL here:
http://labs.trolltech.com/blogs/2010/01/06/qt-graphics-and-performance-opengl/
So, while the OpenGL backend is probably the least working one (with Linux graphics drivers not being that much piece of awesome) it ought to be the fastest one if working, since the GPU will almost always out-perform the CPU when it comes to graphics.
Report
whashnez
7 years ago
Report