This is an interesting issue with Qt Quick ListView, especially when working with variable-height delegates. The estimated delegate sizes can sometimes cause unexpected scroll positioning when jumping to items that are outside the visible area. Calling positionViewAtIndex() twice may help as a workaround, as the first call allows ListView to create nearby delegates and update its size estimates.

@Nathaniel said in QTabBar-like list of "x-clickable" buttons?: There's a common pattern in web UIs where they show a list of items via "buttons" (more precisely, "labels" in the Qt sense because the widget as a whole is not clickable) with a small, clickable "x" in the top-left corner. Clicking on the "x" removes the label from the list. The label is usually in a flat-button style with a thin border. In Qt, one might add labels to the list by choosing from a QComboBox. As far as I know, Qt has no native buttons/labels with this kind of functionality. However, it is similar to how QTabBar works with tabsClosable set to true. So maybe a list of such buttons could be implemented via an ordinary QTabBar and changing the styling. However, this is obviously an atypical use of QTabBar and it might take a lot of work to get the style right so it doesn't confuse the user; there's no QStackWidget being controlled by the tab bar. Is there a 3rd party library that might have such as QLabel subclass implemented already? I’d look for an existing Qt chip or tag widget with a close button, or use a custom widget if no suitable library is available.

Dear ImGui + Qt 6 + OpenGL 3.3 for Windows Source code: https://github.com/ivan-enzhaev/imgui-opengl-test-qt6 [image: a9b5340f-407f-4eb0-8a6d-7eae8a56edfa.png]

@SimonSchroeder I would venture that it is almost more intuitive for QStackedWidget 😅

Alternatively, you could make your application depend on the distro's copy of Qt That wouldn't work on most Linux distros, and the installed Qt would need to exactly match the verison of Qt I built my application with.

indexing by Google worked. :-) In a µC emulation project, where i want to change the emulated program as little as possible, i 'secretly' start a c++ thread on which i create and run the QApplication, but it fails with the "not the main thread" message. With the insight from your article i realized that creating two static QObjects during static initialization phase caused the problem. Replaced them with pointers, and: bingo, it worked. Thanks a lot for this article!

I was brought up to use make. A "sub-project" meant run a new make recursively from the makefile. If a compilation fails that returns a non-0 result to its make which then exits immediately returning non-0 to its parent make. You then have the - symbol in a makefile command and/or the -k argument to make for further control. Worked, and worked fine, for a century. Why do they need to complicate stuff? ;-)

What about the deprecation message? Have you tried using Qt Core extension? I'm not using VS Code. Please report back with your findings about the Qt Core extension and if it solved your problem, so that others that stumble across this post know about it.

You can try asking for review / information on Qt mailing lists. Also, some of the reviewers CCed on gerrit are active on this forum, if you get no review for a long time it might be good to politely ping them.

hey Joe - it doesn't seem to change the ACP chat window in Creator. I can zoom everything, of course, but that's not what I want.

If the font engine is destroyed when the QRawFont is, and the font engine isn't shared between different fonts, then it should be fine. And unfortunately for me, I don't know what fonts or how many fonts might be loaded, so I want to prevent two copies of the font data existing at once. Thanks for the help though!

Glad that fixed it. CMake’s Modules tree can end up half-installed sometimes (upgrade/path mix-up). Once CMakeCXXCompilerABI.cpp is back, AutoMoc is happy again. Good luck with DeepSkyStacker.

@SiFox Thank you ! :-)

Is that white background different in other apps ?