@JonB said in How to change background-color of widget, but not items: [Looks like @J-Hilk types faster than I can... :) ] Sometimes, but I imagine I write with more errors as well :)

@SGaist I tried the Qt 5.12.6 and it did the trick! Thanks. But interestingly, the title of the main application is no longer scaled by "Make text bigger" setting but the dockwidget ones does. I guess that there is an intention not to scale the main title. "Make everything bigger" setting does scale everything properly now except the titlebar height of only the main application looks not enough for the enlarged font size. I will give qt5.14 a try as well.

@hobbyProgrammer I don't know what is going on here, but I note that for a given circuitID you do two new Circuit(circuitID)s, one in fillCircuitMenu() and another any time slot goToCircuit(int index) is invoked. I don't know if that is correct, no re-use of same Circuit instance? Separately, I don't think there is any need to use deprecated QSignalMapper any longer. You can replace with new signal/slot syntax (you should get away from SIGNAL/SLOT() macros in all new code) plus a lambda. See e.g. https://doc.qt.io/qt-5/qsignalmapper.html#details for an example of this.

@hobbyProgrammer Do you actually have event loop running when you emit the signal?

Set a stylesheet for the widgets: QWidget:hover { border: 1px solid red; } And get the clicked widget's pointers by connecting to QApplication::focusChanged(QWidget *old, QWidget *now).

@Dariusz Sorry to make a post to just confirm what @SGaist has said above, but 20 * 75 == 1,500-odd line edits average. That's a lot! (And I pity the user who has to fill those in ;-) ) I think the suggestion that you look at the possibility of some kind of table instead needs reiterating. And @VRonin will then be here to ensure that you achieve this using item delegates instead of widgets in your table, so it will all be fast and not use up too much memory/resources ;-)

@jsulm Hello! Sorry, but that doesn't work. I tried to insert a loop in different places, but the result remains the same. I also tried to display the main widget. @SGaist Hello. So the VideoWindow.h file (VideoWindow class) is my custom widget. This is the first piece of code that I presented.

@SGaist said in SetTitlebarWidget & its height: Hi, You should show your widget implementation. Its something like fo = QDockWidget() fo.show() w = QPushButton("yoyoyooy") w.setMaximumHeight(10) fo.setTitleBarWidget(w) The PushButton is x pixels below top of window, so the title bar is still xx height.

@SGaist I ended up hocking up to resize event of parent widget to find out when size changed & resize my other widget acordingly. I ended up using "invisible" QLabel that retains size as my "spacer". I had to change its spacing role on the go depending of one or more widget are visible or not as I needed to retain correct order. So far works great. TIA

@SGaist Ok that sounds a bit bad like - "delete while in use" situation. So it seems plausible it could crash from that in some cases.

@SGaist Hey, nope did not try it yet. It happens on 2-3 different pcs. So I don't think its hardware limited, maybe OS? But dont think its drivers. Nvidia/intel gpus.

I don't believe X11 will allow negative coordinates, as traditional geometry uses the form AxB+C+D where the (+) can also be a (-) to cause the offset to be from the right hand side or bottom of the display. You should however be able to use coordinates that are GREATER than the visible desktop.

...the rest. Next phase is to use recursion to make a Sierpinski Triangle. // Inner triangle pt1.setX(pt1.x() + side1.dx()/2); pt1.setY(pt1.y() + side1.dy()/2); pt2.setX(pt2.x() + side2.dx()/2); pt2.setY(pt2.y() + side2.dy()/2); pt3.setX(pt3.x() + side3.dx()/2); pt3.setY(pt3.y() + side3.dy()/2); side1 = QLineF(pt1, pt2); side2 = QLineF(pt2, pt3); side3 = QLineF(pt3, pt1); myTriangle.clear(); myTriangle << side1 << side2 << side3; mypainter.setPen(Qt::red); mypainter.drawLines(myTriangle);

@jsulm ok I found out the solution. I had to change the engine for a QQuickView in the main.cpp. But is there any method to create a new kind if widget un qml and insert It like I can maje with a button ?

Hi and welcome to devnet, Glad you found a solution and thanks for sharing ! One thing you can do is to take a look at the release logs to see what has changed. However from your description you may have found a regression. Did you already check the bug report system ?

You should really read the chapter about the parent/child relationship here: https://doc.qt.io/qt-5/qobject.html#details ".... The parent takes ownership of the object; i.e., it will automatically delete its children in its destructor" So if they are all children of your mWidget then they will get deleted when mWidget is destroyed.

got solution. before using the minimum size function set the windowstate Qt::WindowFullScreen. In my case I used line this->setWindowState(Qt::WindowFullScreen); before this->setMinimumWidth(1366); this->setMinimumHeight(768);.

That article answers quite a few questions I had about that scenario, woah nice thanks! But... I kinda like the idea of more "control"... somehow, creating the widget this way allow the user to resize it which won't be possible using a popup, so I would like to get the focus to work properly... TIA

You won't get a paint event at all during drag'n'drop I would guess since the cursor is not directly painted by Qt when I'm correct.

Then add a signal to your dialog that you will emit when needed from your mouse move event.

no, decrese the font size and see if it works. then you'll know whether you can change font size at all. If it works then that should be a hint as to why you cannot increase the size.

We found a solution to that bug. The Cocoa window itself isn't set to non resizeable. If you do this, everything works as expected. class MainWindow : public QMainWindow { public: explicit MainWindow(QWidget *parent = nullptr) : QMainWindow(parent) { //this will get rid of the size grip widget showing setFixedSize(500, 500); } void mousePressEvent(QMouseEvent *) override { std::cout<<"mouse pressed"<<std::endl; } }; int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w; NSWindow* window = [(NSView*)w.window()->winId() window]; //IMTPORTANT. Otherwise the lower right mouse events will not be passed on correctly by cocoa window.styleMask &= ~NSWindowStyleMaskResizable; w.show(); return a.exec(); }

@J.Hilk Thanks for your test, I checked it and the setValue function is normally called with the right value and the display still doesn't display the change.

You can make a "container widget" that will handle the showing of the label properly.

@kweber said in Add widget to layout programmatically: setLayout(ui->verticalLayout); my bad for posting untested code ui->centralWidget->setLayout(ui->verticalLayout);

@b2soft I want to customize BrowserModel ::data() returning colors using QSS @raven-worx knows much more than I, but I don't get this. role == Qt::TextColorRole will want to return a QBrush (http://doc.qt.io/qt-5/qt.html#ItemDataRole-enum). How is that linked to returning a string to use for a name in a stylesheet? :confused:

Hi and welcome to devnet, What version of macOS ? Did you also check whether the latest beta of 5.12 has the same problem ?

Ok so after LOTS of fighting with QTreeView... I started looking at viewport() and wuaila! void myTree::resizeEvent(QResizeEvent *event) { QAbstractItemView::resizeEvent(event); b->setFixedSize(event->size().width(), 25); b->move(0,height()-25); viewport()->setMaximumHeight(height() - 50); }; Now my viewport gets painted exactly where I want it to, and the extra buttons can be placed in area where I want it to (b is the button) + its all nice all in one widget. I can expose needed controls for b as pert spec but drawing is as it should. Yay!

I said 'Maybe you've a typo...' The problem with auto-connect is that you can not be sure if it is really connected (e.g. when there is a typo somewhere in the functions signature or the ui element name) and it easily breaks (e.g. when renaming an ui element).

Hi and welcome to devnet, First thing, please don't delete all that stuff in your destructors. Qt has a pattern that is based on parent widget (the parameter "this" in widget constructors) that take care of destructing all the children automatically when the parent is deleted: http://doc.qt.io/qt-5/objecttrees.html Now regarding your problem, only one widget can have focus at the same time. For the focus part, you can use setFocusPolicy on your widgets, giving an enum that tells more about the behavior you expect. For what I have experienced, playing with opacity and trying to give a modern look to a desktop software is kind of a pain. Long story short: there is no user friendly API to do so, or at least as user friendly as what QML provides. This is either because the widgets part is late compared to the QML one, or because "modern" has been associated with app, browsers, Internet, but not with desktop. Nonetheless, things might evolve in the future, since Qt developers have communicated about resuming the widgets development. This doesn't solve your problem, but could explain why you are having so much trouble trying to code an overlay that behaves with good focus policy, and using low level code such as QPalette that is always a sign you're doing something wrong, or at least not initially intended. Which could be fine, if you really know what you're doing, and you are aware that you'll have to deal with a lot of work to make your application look the same on every platform. EDIT: So I created a project with your code and here are some remarks: 1 Do not set a layout to your main window, just set the central widget with, well setCentralWidget(widget) 2 qreal is an alias for double, so instead of qreal(100)/100 just write 1.0; same for qreal(50)/100, just write 0.5 and it will be perfectly fine. 3 No need to use "this->" you are coding in C++, not JAVA ;) For your problem, I think I don't really get what you are expecting. Just an overlay when the setting widget pops? If so, maybe working with a QDialog (a modal one) would be better.

Hi The qemf seems able to only rendering of EMF not generating it. What is the data you want to put in the emf file ? Qt has http://doc.qt.io/qt-5/qpicture.html#details that works like WMF but its not same (file) format at all. However, its pretty simle to generate WMF/EMF from windows API. (CreateEnhMetaFile)

@raven-worx said in QWheelEvent & Siblings/Children: @J.Hilk said in QWheelEvent & Siblings/Children: Currently I do this with a signal that has the QWheelEvent* as argument why not directly forward the event to the child widget instead? (using QCoreApplication::sendEvent()) Well, yes, that seems exactly like the proper way to do it! I'll look further into it, thanks! Yes this is exactly what I was looking for. Solved!

@jsulm Ok! I will make sure to read all the links you've given me. Thanks for the help!

@Christian-Ehrlicher Thankyou It's Working

@sierdzio said in QWidget: Cannot create a QWidget without QApplication - OpenCV imshow() 2.4.13 ?: Is Qt the only supported backend? If yes, then indeed requirements do propagate. No, it has been added later on. It's maybe even the latest that has been implemented. AFAIK, what the OP is hitting here, is that OpenCV doesn't have an implementation for imgshow for iOS. It would require to either use Qt to show the result of what he's doing or native stuff.

Why not implement my original suggestion ? Put a QLabel and your grid widget in a QStackedLayout and change to the label and back as needed ?

Hi Does the custom CustomQWidget do its own drawing with QPainter ?