General and Desktop

@gabello306 said in Get position of widget under cursor during drag and drop in a QTreeWidget: What I need to know is how to put the showText box in the QTreeWidget instead of global coordinates. You have to convert the local coordinates to the global ones: https://doc.qt.io/qt-6/qwidget.html#mapToGlobal

@Christian-Ehrlicher Thanks!!

@Christian-Ehrlicher Thanks a lot. We already started a couple of years back in this project, and we went for 5.15.2. To make things even weird I asked about it in Qt subbreddit here and the answer proposed works fine for this test app, but the actual project is still doing weird stuff.

@Joe-von-Habsburg Ah ha! One of us should have mentioned this when you said about sender packet size :(

@marlonbuilder For your choice of using a thread --- and especially if you are not familiar with threads and their requirements --- as @jsulm has said it is not clear why you need one at all. Try it from the main event loop and only look into threads if there is a problem. Newcomers to Qt often rush into sub-threads when there is no need. For your updating of widget(s). Assuming you have some widget listening for dataChanged() signal. If you say that is happening too frequently and thereby causing lag --- is it? have you actually tried? if you are only emitting dataChanged() "a certain number of times per second" that may be fine, depending on how many times --- then you have a couple of choices. Basically you would want to "delay" emission of signal causing update so that you can "accumulate" multiple updates into one update for redraw. You might interpose a QIdentityProxyModel between your model and the widget to control signal emission. Or since you seem to have a setStat() which calls dataChanged() explicitly itself you might do it there. You would introduce a QTimer --- single shot or repeating --- which you start when setStat() is called and only when that times out would you emit a dataChanged(), with the data as it is at that point, having accumulated/ignored the earlier updates. Make the frequency of the timer sufficient for user, e.g. does user really need to see updates more than, say, 10 times per second? Although the situation is rather different, the principle is similar to that recently discussed in my post at https://forum.qt.io/topic/164540/spin-box-and-slider-tracking/11.

@nicholas_ru said in Running application with user privillegions.: Yes, of course. That is still a bit cryptic regarding your "but very difficult" answer. What difficulties do you have ?

I've marked this as solved. Whilst I didn't get a perfect / ideal answer, I Did some good responses and enough information to make a decision for my use case. In the end I decided that a refactor would be too much work, and while i came up with other more elegant solutions, they really all just boiled down to an extra call to setGeometry, so i ended up going with the existing fix. Thanks everyone though.

To wrap things up, this is a bug which is fixed for Qt 6.11.1: https://qt-project.atlassian.net/browse/QTBUG-140359

@uncore the actual problem is a false assumption. The black you see is not the transparent background after resize. It's just not rendered. I don't know if you can actually get a normal ApplicationWindow with only a transparent background. The Only way I know is via the QtFramelessWindowHint: [image: af646d06-9229-4099-8abb-975f44722759.png] but that comes with missing menu bar and stuff

Thank you so much, It works. For that kind of things, must be so explanatory. Thanks everyone :)

@Chris-Kawa Thank you so much for all the help!

As far as I understand, manually setting minimum/maximum may cause unexpected result. See: https://github.com/qt/qtbase/blob/dev/src/widgets/widgets/qscrollarea.cpp#L191 The min/max values are most likely measured in pixels. Otherwise, I don't understand why QScrollArea does that by default vbar->setRange(0, v.height() - p.height()); So if you limit the maximum to 100, you are probably going to only see very limited part of your table, which may result in looking like "nothing happened" because <100 pixels is perhaps too unnoticeable. You may try unsetting min/max value and just try something like QScrollBar* scrollBar = <whatever_your_scroll_bar_is>; scrollBar->setValue(int(scrollBar->maximum() * 0.1f)); And see if you can notice something. And another recommendation is that a minimal reproducing sample can really help here.

https://github.com/qt/qtbase/commit/c3bd5ffdc8a3b459f18ba6e35fca93e29f3b0ab0 I guess that was done so on purpose. 7 years ago, there was no such definition of reserved macro but Qt defined its own "QT_HAS_whatever". But then due to some C++ rules and recommendations, a wrapper around reserved macro is not recommended. And explicitly in commit message: Both https://clang.llvm.org/docs/LanguageExtensions.html and the SD-6 document at https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations recommend defining '__has_foo(x) 0' as a fallback for compilers without the macros, so that's what we go for. So I think that is the correct way of doing this. The solution should be just turn off "-Wreserved-macro-identifier" I think,

Okey thank you all for your help!!

Fixed in Qt dev, integration for Qt 6.11 is on the way

Thank you for your reply

The flashing happens because of "Note: When dynamically adding a QOpenGLWidget into a widget hierarchy, e.g. by parenting a new QOpenGLWidget to a widget where the corresponding top-level widget is already shown on screen, the associated native window may get implicitly destroyed and recreated if the QOpenGLWidget is the first of its kind within its window. This is because the window type changes from RasterSurface to OpenGLSurface and that has platform-specific implications. This behavior is new in Qt 6.4." as stated in https://doc.qt.io/qt-6/qopenglwidget.html#limitations-and-other-considerations. If you create a tiny invisible dummy QOpenGLWidget and parent it before the widget is embedded into the main window, it should work seamlessly.