General and Desktop

@Poldi I got it to link root cmake_minimum_required(VERSION 3.14) project(ProtobuffTutorial LANGUAGES CXX) set(CMAKE_AUTOUIC ON) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTORCC ON) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(QT NAMES Qt6 Qt5 REQUIRED COMPONENTS Core Protobuf) find_package(Qt${QT_VERSION_MAJOR} REQUIRED COMPONENTS Core Protobuf) add_subdirectory(proto) add_executable(ProtobuffTutorial main.cpp ) target_include_directories(ProtobuffTutorial PRIVATE "${CMAKE_CURRENT_BINARY_DIR}") target_link_libraries(ProtobuffTutorial Qt${QT_VERSION_MAJOR}::Core Qt${QT_VERSION_MAJOR}::Protobuf ${Protobuf_LIBRARIES} Proto ) include(GNUInstallDirs) install(TARGETS ProtobuffTutorial LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR} ) proto INCLUDE(FindProtobuf) FIND_PACKAGE(Protobuf REQUIRED) include_directories(${Protobuf_INCLUDE_DIR}) protobuf_generate_cpp(PROTO_SRC PROTO_HEADER message.proto) ADD_LIBRARY(Proto ${PROTO_HEADER} ${PROTO_SRC} ) target_sources (Proto PRIVATE message.proto ) include_directories(${CMAKE_CURRENT_BINARY_DIR}) target_include_directories(Proto PRIVATE ${CMAKE_CURRENT_BINARY_DIR})

@JohannesW said in Mix commercial and open source: Or are you not allowed to mix things under any circumstances, even if it only affects the development? You are not allowed to mix code that was developed with Qt commercial license(s) and such that was developed with Qt's LGPL offering. TQtC's concern being that you can develop a whole system with LGPL and then decide that you want to jump to commercial to close the source completely (i.e. to decide you don't want oblige the requirements of the LGPL at some point after the code is already developed). In any case you can use the LGPL to develop commercial software, simply don't mix the licenses.

If you take the qttools sources, you'll see that the classes are included directly in the projects using them.

@Chinny02 said in Run Terminal error?: However, only a part of my code is being shown in my run terminal. How can I fix this problem so that all required parts of my code show in run terminal? What required "parts" and which "terminal"? Please show/specify what you are doing exactly.

@Malcolmc said in Missing QSerialPort files.: Pity the use of this tool is not noted in the QSerialPort documentation. But the documentation mentions that the Qt serial port module is needed. See: CMake find_package(Qt6 REQUIRED COMPONENTS SerialPort) QMake QT += serialport https://doc.qt.io/qt-6/qserialport.html If you don't have it, of course it doesn't work. And whether you have installed it before, QSerialPort can't know. However how you install a module is described here: https://doc.qt.io/qt-6/get-and-install-qt.html

@ChrisW67 Sorry i have not updated the code over here.

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?)