General and Desktop

Hi and welcome to devnet, What is your setup ? You have a widget with a QGraphicsScene and want to render its content in QML ? What do you have in that scene ?

I would do so, yes. Even though I would not expect a threading problem with qFindChild as long as the object tree is not changing but one never knows.

Does anyone know if Qt::WA_NativeWindow actually works with Qt 6.5 ? From my current debugging at the Wayland protocol level it doesn't appear to be working as I would expect. I am creating two QWidgets, one a child of the first top level QWidget. Both have the Qt::WA_NativeWindow flag set. I use QPainter to draw into each QWidget on QTimers. When I do this: The QPlatformNativeInterface nativeResourceForWindow("surface", windowHandle()) function does return different pointers (wl_surface ??). The Wayland protocol does appear to be creating multiple surfaces. The Wayland drawing including the wl_surface@17.commit() for the two QWidget paints use the same Walyland surface ?? Using the Weston --debug option in conjunction with "weston-debug scene-graph" only shows the one surface in use by the application. It seems like the qtwayland has somehow forced all drawing/interaction to the single native Wayland surface ?

@JonB Thank you for the detailed explanation. I will debug the program to make sure that I use the valid indexes while accessing the QList.

@JonB yeah,bingo.

@Christian-Ehrlicher Oh, right. How careless of me. I copyed the file deleting operation code and forget to delete the return true. This is awkward.I thought there is some mechanisam that I don't know... Thank you very much.

@artemious3 said in Creating QIODevice with infinite data: I'd like to know if you can see some problems with this implementation, On a cursory inspection... Let's say your audioData buffer size is 1024 bytes, for example, and the user requests a read of 2048 bytes (because your bytesAvailable says that is available). This line: currentDataPtr = std::copy(audioData, audioData + remainingBytes, targetData); will try to copy 2048 bytes out of a 1024 byte buffer. You should also look at the QIODevice::bytesAvailable() docs regarding what this should return.

@Qt-embedded-developer THE SOLUTION IS LINK THE PATH OF QT INSTALLATION DIRECTORY USING CMAKE_PREFIX_PATH

Hi, One thing you can try is to have your own implementation of the default_post.prf in the Mac mkspecs subfolder however that might be a bit overkill. I currently don't know if you can provide a custom Info.plist template as used by default.

@Christian-Ehrlicher Thanks for the quick reply!

@JoeCFD Yes, my plug-in is only intended to be used on macOS, in which case the host app will surely be using the Cocoa platform plug-in. And if the off chance it's not then my plug-in won't attempt to use anything from the Cocoa plug-in. So it looks like what I'd need to do is include the QCocoaDrag header files from the various different versions of the Qt source code. Is that right? (Am I allowed to distribute that if my plug-in is open source?)

@Johndavid You think @Ruzik is waiting here since 2011 for your reply?

@K-Str Looks like you've downloaded the wrong stuff. How did you install Qt? At the bottom of this page you find a download link for the Online Installer which grants access to Qt and QtCreator community Edition. https://www.qt.io/download-open-source

https://felgo.com/ Try this if what you want is just a black box Qt environment.

Aha, that clears it up, things seem to compile now. Thank you!

@rock37 Because your class apparently has no methods of its own. If you want the inherited methods too start iterating from 0. methodOffset() is the offset of the non-inherited methods. Also, in the printing part why are you doing it twice? If you get all 40 methods it will print them 40*40 times this way.

@jsulm Thanks, i will try that way.