Some parts of widgets (e.g. button in a QDateEdit) are by far too small so they cannot be properly used with touch screens.
On my system, the sliders, e.g. for the widget's scroll areas, become bigger if I use setGlobalStrut() accordingly. But a slider has buttons with arrows which are very small on our system. The same is true for QDateWidget. The Buttons with the arrows are very, very small in our system and therefore cannot be well used with touchscreen.
We use Pvbrowser (pvbrowser.org) for visualisation of a gas measurement device on an embedded system with touchscreen. It is running an embedded linux yocto/poky "jethroo". By passing a parameter, the application calls QApplication::setGlobalStrut. The effect is, that some elements become bigger, but not sub elements within the widget.
Is there any way to change the appearance of Qt applications on systems like this:
X11 was used instead of egl because the vnc functionality is needed. A display manager is not used and the windows manager is "matchbox". Qt is version 5.5.1.
In the meantime I have found a solution. The screen size was not set in X11 and xrandr reported 0 dpi.
If I set the dpi, e.g. by calling "xrandr --dpi 146" from mconsole, the size of arrow elements etc. within dateTime widgets, scroll bars or other are adjusted accordingly when the application is restarted.
Not only the widgets and its elements are changed but also the font size since it is given in points which depends on dpi.
Related
My current UI doesn't use QT widgets paint and it's mostly done with QSS markup. The current styles are defined in pixels and I could not find anything in the QT documentation that allows the styles to be defined as relative unit as opposed to pixels. I would like to know if it's possible to use something relative then tie that unit to a ROOT font-size. In case I need to adjust for a particular screen size like a battery charger IOT device that has a small screen, while my main UI was designed for very large screens (27 inch monitor). So instead of me styling a button just for the IOT device, I shrink the base unit (technique similar to web responsive like REM) then everything like fonts, padding, buttons shrink proportionally. Is that something that QT supports?
To my knowledge vanilla Qt Widgets don't support free scaling at all. Recently high-DPI display support was added, but it only scales in fixed ratios (e.g. 1:2). There are other options to get scaling in Qt applications:
Use QML (didn't try this yet myself, but it's developed with adaption to different displays in mind)
Use QGraphicsScene with QGraphicsWidget
Use QGraphicsScene with custom graphics objects that implement the behavior you need
Roll your own widgets
I'd love to stand corrected on this answer - maybe in a future Qt version...?
I am currently developing an application. And my development computer resolution is 1366*768, I know how to make the application size auto resizable according to resolution. But the problem is in the labels used in application. If the resolution of the monitor is less than 1366*768, the labels becomes cramped and unable to see text, if i keep the font low, and if i use higher resolution monitor the text in those labels looks very tiny. I know one solution that is to check the resolution of monitor during the application start and assign appropriate font to the labels dynamically. But this method takes more time as i have to first create a list of resolution with appropriate font by using trial and error method. And this also requires lot of code. I was wondering if there is any feature or function in qt that i am unaware of to auto scale the font as per resolution. Thanks!
I'm working on application for embedded and we have 256x64 grayscale screen. Qt 5.3 perfectly renders on that screen with -platform linuxfb option. Obviously, we save every pixel of space, so I faced with trouble: Qt Designer adds excess 1 pixel spacing for every layout element deeper in hierarchy. So they accumulate for the most deep widgets. More precisely, for some reason child element of layout components gets coordinates (1,1) relative to parent. So, it's true for every widget except for root widget. Picture below demonstrates accumulated spacings (thin and thick red lines), and (1,1) coordinates of the very first child widget.
I believe it's Qt behavior itself, not just Qt Designer issue (not tested yet). But I can't work further even if it's shown in Designer only: I need to have pixel-exact view while designing.
Of course, every spacing and margin of every component in form set to 0.
Manual coordinates assigning (from code) eliminates the problem of course, but I need to generate code by uic.
So, my question is: how to avoid such spacings? Fixing Qt core sources can be (hard) option too, since anyway we recompile Qt for the project.
Mirror post on Qt forums
Thanks.
Ilia.
If you select Form > View Code, you can see that the geometry is not actually used for widgets which are inside a layout. So the numbers you see in the Property Editor are purely informational and have no relevance to the eventual code that is generated from the ui file (which is why they are greyed out).
The one pixel offset is there because Qt Designer needs space to draw the red boxes around layouts. They have to be be represented somehow, so I don't see how this can be avoided given the way Qt Designer currently works. If you want a more accurate reprentation of the final results, I suppose you will have to show a preview.
There is a facility in Settings > Preferences > Embedded Design that allows you to specify device profiles (which determine things like style, font, and screen resolution). This will add a new entry to the Preview In menu, which should allow you to refine the accuracy of the previews even further.
I am developing a tool which will have some variable sized windows. I am able to achieve this using the QSplitter horizontal & vertical. Please see attached image.
Now, how to make these individual windows detachable/maximize/close? How can I add cross markers at the top-right-corner of each window so that they can be closed maximized or detached from there? Just like this link :--
http://vector.com/portal/medien/ecu_testing/tae/test_automation_editor.png
You're looking for the QDockWidget class:
The QDockWidget class provides a widget that can be docked inside a
QMainWindow or floated as a top-level window on the desktop.
QDockWidget provides the concept of dock widgets, also know as tool
palettes or utility windows. Dock windows are secondary windows placed
in the dock widget area around the central widget in a QMainWindow.
Check out this example
In 2021, there is KDQDockWidget, an apparently much better Qt docking framework with both commercial and open source licenses.
The site lists the following advantages:
It provides advanced docking that QDockWidgets doesn’t support.
The layouting engine honors min/max size constraints and some size policies.
Supports PySide2 bindings.
Clean codebase.
Supports lazy separator resize.
You can reorder tabs with the mouse.
Supports partial layout save/restore, affecting only a chosen sub-set.
Allows double clicking on title bar to maximize.
Allows double clicking on separator to distribute equally.
Shows close button on tabs.
Allows you to make a dock widget non-closable and/or non-dockable.
Provides an optional maximize button on the title bar.
FloatingWindows can be utility windows or full native.
Is it possible to cut a QGLWidget? I mean I would like to cut it so i get access to the gui below. It sounds strange, but it would be a lot of work for me to divide my QGLWidget into two. I hope you understand what I mean.
I don't fully understand what you mean by "cut" and GUI below. In Qt with layout mechanisms properly used a widget consumes the area it covers and there are no widgets beneath it.
Do you want to render multiple views into a single QGLWidget? This is easily achieved by proper use of glViewport + glScissor.
EDIT due to comment
There are two kinds of windows:
Top level (those you can freely move around on the screen)
Child windows (subwindows like widgets or panes in a top level window)
Child windows again come in two characteristics:
logical child
real child
A logical child window just consists of its position, dimension and layer and are managed by the toolkit. From the view of the operating system there's just one top level window. The toolkit is it that manages its internal state to give the impression of independent sibling windows in the toplevel window.
A real child window is manages by the operating/graphics system. Such real child windows may share their graphics context with their parent and sibling. However OpenGL only works well if the window into which a OpenGL context is created has its very own graphics context. Thus any OpenGL child window inevitably will have its very own graphics context and graphics system window object. Most graphics systems out there don't properly support applying shapes onto child windows (only toplevel windows, and then this also conflicts with OpenGL).
So this boils all down that it's virtually impossible, nor advisible to try to "layer" an OpenGL window on top of a sibling. It may work in some circumstances, but most of the time it won't.
That's the bad news.
The good news are, that you simply looked in a slightly wrong direction. I hereby direct your view towards QGraphicsView. QGraphicsView supports OpenGL as a backend, you can also write your own OpenGL renderer code to be executed within a QGraphicsView. But furthermore QGraphicsView can also be used for rendering widgets, also using OpenGL. So all you have to do is putting both your OpenGL rendering code and your widget into a common QGraphicsView scene and are done. And here is a tutorial http://www.crossplatform.ru/node/612 the result of the tutorial looks like this: