Defining buttons in OpenGL-window - c++

My question is, if it is possible to display buttons on an opengl-window. As you can see on the picture I have created in the main window two smaller ones. The right grey corner is designated for the buttons(marked with a red rectangle). This I created before using Qt. Now I see that Qt is always creating the buttons at the border of the window. Is it possible to place my buttons in this red rectangle?
I am using a mac.

Yes. In code, set the containing widget as the parent of the contained widget in its constructor or use setParent() after it has already been constructed.

Related

Scrollable background with resizable Qt widgets on it

I would like to create a Qt window that
can be scrolled/panned by dragging its background (scrollbars should not be shown)
contains multiple sub-widgets at defined locations (which scroll with the background)
the sub-widgets can be resized by pulling their border
What I managed so far is to create a QGraphicsView with setDragMode(QGraphicsView::ScrollHandDrag) http://doc.qt.io/qt-5/qgraphicsview.html#dragMode-prop. I then placed the sub-widgets on a QGraphicsScene, however, this didn't allow the sub-widgets to be resized by pulling their border.
I also tried to inherit my custom sub-widget class from QDialog, which allows setSizeGripEnabled(true). However, this doesn't resize their content, and QDialog is probably not meant to be part of a QGraphicsView.
Any suggestions? It would also be ok if the sub-widgets behave like sub-windows that can also be dragged at their title bar, as long as they cannot be closed and they move when the background is dragged.
You can look aside QMdiArea class (Qt documentation: QMdiArea). By problem description it is what you need.
Of course, you can use Graphics View Framework, but, i think, it will be more difficult. If you choose such approach, very useful will be class QGraphicsWidget (Qt documentation: QGraphicsWidget).

Do I need a top-level sizer on my wxWidgets frame-based app?

I am undergoing a number of tutorials on wxWidgets and found that I must add a wxPanel to my main frame in order to get a Windows native-like background, instead of the ugly dark-grey that it defaults to.
Now, the WxSmith tutorial: Hello world states that a wxBoxSizer is the first control that should be added to the main frame. Then goes the wxPanel, and then another sizer where I'll put my controls (text, buttons, etc).
I'm failing to understand the need for the first sizer. For me it would make more sense to have the following hierarchy: Frame -> Panel -> Sizer -> Controls.
So, do I really need to add a top-level sizer to my frame, before the panel?
Note: The only purpose of the wxPanel is to give my window a light-grey background.
Edit In fact, I only get what I want (light background color for the entire window) if the panel is the frame's first and only child control.
No, you don't need a sizer for the panel because wxFrame automatically resizes its only child to fill its entire client area, just because it's such a common case.
The purpose of wxPanel is not only to give you the "correct" background, but also to provide correct keyboard navigation among your controls. And the reason it is decoupled from wxFrame is that some frames don't contain controls but are used as e.g. canvases, in which case the panel would be unnecessary.
Finally, don't be confused: sizers are not controls, they are associated with a window and, in turn, contain (some of) the window children, but are not controls themselves.

QT: How to position a IconTool box on the right side of a window

QT 4.8, C++
I have a few dock-able icon tool box widgets in my window.
They are all displayed horizontally, on the first line.
I would like to anchor (by default) one of the tool boxes to the right corner of the window, as displayed in the pic.
Note that the the tool bar needs to keep anchored as I resize the window. Also, since the tool bars are dock-able, then can be moved or re-ordered by the user.
This is an example I made (with paint, with Visual Studio windows) that exemplify the issue:
You could probably create a QWidget and use it as a spacer in the left tool bar. Place the spacer after the undo/redo buttons and set the size policy and it's minimum width (or alternatively subclass and re-implement it's size hint) to get a desired behaviour:
QWidget spacer;
spacer.setSizePolicy(QSizePolicy::MinimumExpanding, QSizePolicy::Fixed);
spacer.setMinimumWidth(200);
fileToolBar->addWidget(&spacer);

Area for detachable QDialogs within QGridLayout

I have a QMainWindow with a QGridLayout of various widgets that looks like the following:
I will have various little input dialogs that come up at different times, and I want them to appear in certain cell of the layout (bright cyan area below purple tab widget in picture). They would show up in this cell by default but should be detachable and able to be moved around as desired (just like a regular, stray QDialog).
What would be the best way to go about this?
I tried using a QDockWidget and just adding it right into the grid layout, but it seems I cannot un-dock it and move it around, even with a call to setFeatures that should allow this freedom.
The addDockWidget function allows the desired movement, but this won't let me incorporate the dock area within the grid; it just puts the dock widget on, e.g., one side of the entire main window.

Displaying a popup widget in QT over application border

Let's say that I have an application frame, and I want to show a popup QCalendarWidget over on the right side of the frame. Normally, QT will clip the edges of the QCalendarWidget, cutting it in half and not displaying the rest, as it would be over the right side border.
Is there a way to work around this limitation without resorting to implementing a QDialog?
I want the widget to be visible outside the bounds of it's container.
If you'd show your Calendar, let's say, after a button click, as QDateTimeEditor does, it's contents will not be clipped, cause it do not belong to frame. It will be just a widget, that shows in a dialog manner. And maybe you should even place it in QDialog, that is modal and provides some convenience methods, rather then simple QWidget.
Btw, why don't you want to use QDatetimeEditor?