General and Desktop

@buhtz It was just an illustration that you might be overcomplicating this, other apps just give you a tooltip and you get on with it, it's not always perfect :) But yes if you do want to change the text I think follow the QHelpEvent approach. Conceptual I imagine a solution where I can add two kinds tooltips to a QAction: One for elements with a label and one for elements without a label. That is just not supported. And methods are not virtual to allow subclass/override.

@Mamun I tried this, my printer is on and connected to laptop but it is showing idle and when I remove it is also idle , thanks for reply.

The Qt 6 examples with CMake in progress now. When it will be finished will publish it on Github. For now just have no free time for it.

No since this is only parsed by moc and written into the moc_foo.cpp file.

The most likely reason why the PDF is so large is because your chart is saved as a bitmap, i.e. individual pixels. PDFs can also store vector graphics which will be a lot more space efficient. But, I am not sure how this could be achieved with QPdfWriter. Bitmaps inside PDFs can also be stored in a compressed format. Maybe it would help drawing to a QPixmap, saving it as PNG (or similar) and embedding that file into the PDF. Again, I am not sure how this could be achieved with QPdfWriter.

The x86 architecture has some really weird rules for data races. There are even combinations that seem to be totally illogical at first (check out slide 29 here: https://www.cse.unsw.edu.au/~cs9242/23/lectures/07b-smp.pdf). During optimization compilers (and CPU cores themselves) can do instruction reordering because there are no dependencies between variables inside a single thread. Any data race can be really hard to debug (especially because it is usually not deterministic!). So, I agree with @Chris-Kawa: "Very bad. Fix it."

@Pl45m4 said in Custom Widget not showing in layout: always returning QSize(width(), height()); doesn't feel like the best solution ;-) I guess that QPushButton uses the actual text displayed (plus some padding) to calculate the size hint. QFontMetrics might help here.

@Calvin-H-C I assume you are using Designer to generate the UI code. The default uic generated code behaviour is to auto-connect by name. This can be suppressed by passing the -a or --no-autoconnection option to uic. In a qmake project file this could be achieved using the QMAKE_UIC_FLAGS. Your code must then connect everything manually.

You should be using composition instead of inheritance. Instead of template<typename T> class QtBase: public QtBaseSignals, public nonQtBase<T> { ... } you should write template<typename T> class QtBase : public QtBaseSignals { Q_OBJECT // this is totally necessary (don't know if it works with templates...) std::unique_ptr<nonQtBase<T>> data; ... } This should not be much of a problem as you are wrapping all functions already in order to be able to emit signals. The derived class would then also just inherit from the base: template<typename T> class QtDrv1 : public QtBase { ... } (You should drop the QtBaseSignals/QtDrv1Signals classes!) QtDrv1 will not have its own data member, but will use the one provided by QtBase. This is the good thing about polymorphism. However, when forwarding signals in your derived Qt classes you should always cast to the derived type, e.g. nonQtDrv1<T>, of data before accessing it.

@Abderrahmene_Rayene Than you for the reply. First I changed padding value, and later completely removed it; but no change in behavior. Similarly, I edited the .ui file and changed MinimumSectionSize value first; and later removed it; still not change in behaviour.

@Chris-Kawa Ok thank you very much, gonna have a look at that than. :) Have a nice day.

@mzimmers said: does my approach now make sense in general, or is this still an undesirable way to go about this? It's a valid solution. Whether or not it's best for your case is something you have to answer yourself.

See https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/widgets/qlabel.h?h=6.6.1

@ChrisW67 Thank you for help friend, You've guided me to the right thoughts.

@Pl45m4 Indeed, this worked. Another issue: the grid lines seem to still somehow be inconsistent with the widgets depending on how they're placed. Is there any better way to implement basic gridlines?