General and Desktop

Hi, just a guess but maybe you need to enable the aarch64 architecture if you're crosscompiling, something like this: sudo dpkg --add-architecture arm64 sudo apt install libc6:arm64

@micha_eleric I had not noticed, but as @J-Hilk has said 400,000,000 is a lot of items to draw ;-) Not to mention, this is a lot for the user to look at/I'm not sure there are even that many pixels on the screen! But I guess you will see this is just a test. If you have a "lot" of add/move/delete operations to perform, you must either (a) do the operations in batches on a timer from a "queue" (at least conceptually), presumably from the UI thread, so that the UI has time to render them and remains responsive, or (b) if @SimonSchroeder's principle of "double-buffering"/mutexing works from a thread you would have to release the mutex periodically after batches performed so that the UI thread gets some time to process the updates without blocking on a mutex for too long.

@mdrost And a DirectConnection is by definition always blocking.

@Christian-Ehrlicher the user will not see well the button because they will have the finger on top of it blocking visibility.

Thank you all. I think ill be able to achieve this now. Also thanks for the suggestion I will dig deeper into that stuff.

https://poe.com/s/fqPkHzQlb2YKt6j9JeAE

@Pl45m4 said in Custom widget using and extending Qt's pImpl: It was just about the naming?! Is this the way? :) I would say yes.

@PValentine As @Christian-Ehrlicher has said, you cannot read the effects of stylesheet in Qt code. Try not to set font in code at the same time as using stylesheets. Are you aware there is a QTableView::item CSS selector? This affects all the table's items, there isn't a way of selecting individual ones.

@starkm42 Yes, if it is only multiple slots in a thread, including the main one, which access a resource then everything is occurring serially, no locking would be needed.

@JonB I have also considered whether it is an issue with Android permissions, but I don’t know where to get the answer.

@Pl45m4 said in QRemoteObjectHost connected nodes: @beecksche Dunno if it's the right signal but maybe https://doc.qt.io/qt-6/qremoteobjectnode.html#remoteObjectAdded https://doc.qt.io/qt-6/qremoteobjectnode.html#remoteObjectRemoved to keep track of the current connections yourself That's what I thought at first. But if I understand the documentation correctly, the signal is emitted on enableRemoting(). The QRemoteObjectSourceLocation argument also contains no information about a client, only the hostUrl and typename.

@Paul-Colby Thank you for that detailed answer. I'm using qmake so I guess for now I will stick with that "old" structure. But your answer is bookmarked for future use :)

Further to @Pl45m4's observation, look at the prototypes of the functions you used to pass QwtDoubleRect objects to and you probably see that they now take QRectF @rock37 , what is the connection between the title of this thread and the content of this thread?

@SGaist thank you for your help

Hi, The usual way would be to follow the implementation done by the other plugins. Then you have to deploy it using the same folder structure in your application folder and it should be made available as the other plugins. If not, then you can copy your plugin beside the others in the Qt installation.

Hi, In addition to @Pl45m4, you don't print any information if the opening of the serial port failed. Doing that will help track the issue.

@NightShadeI Possibly related is that, on Windows, QtCreator's model editor used to have the same defect until the recent upgrade to QtCreator 12. It would leave behind graphics artefacts as you moved elements around. There may be clues in the QtCreator sources. By model editor I mean what you get when you "Add new..." => Modeling => Model