4 ms·

I hope they fix QtDesigner to not be hot garbage. Elementary operations such as trying to move some controls to a container that has zero size is totally unintu

by Crinus 7y ago

I hope they fix QtDesigner to not be hot garbage. Elementary operations such as trying to move some controls to a container that has zero size is totally unintuitive (you need to alt+drag to the container in the widget tree view - note that nothing else needs that) and not always possible (the widget tree view doesn't scroll so if the container is out of view you can't move stuff there - the fact that selecting something in the form automatically selects it in the widget tree view and scrolls it doesn't help at all there), or simply pasting widgets in a container without breaking the existing layout (literally, the program tells you to "break" the layout... meaning to remove the existing layout). Or something like making a widget invisible (the visible property is not exposed in the property editor and if you force it to be enabled and mark the widget as invisible then the widget doesn't show up in the editor :-P). And some widgets are simply missing or accessible through obscure ways (e.g. instead of QSplitter being in the Containers group in the widget box, it is only accessible by ctrl+clicking two controls under a parent container that has no layout and right clicking and selecting selecting Layout horizontally/vertically (two menus) - WTF, what is wrong with simply letting me drop QSplitter in the form and then place controls manually? I can already do that perfectly fine after i perform the magic incantation to bring it in - though of course i cannot change the splitter position from within the form editor, because that would be too convenient i suppose). I've seen form designers from open source projects written by a single developer in their free time that are more polished than that. The only thing worse is writing those UIs by hand.

jimbo1qaz 7y ago
I prefer writing UI by hand, rather than using Qt Designer. In C++, I figured out a few simple macros to automatically redefine `auto w` and `auto l` to refer to the parent widget and layout. Is there a reason Qt Designer generates .cpp files which append a child to the parent after the child is fully fleshed out, rather than when the child is first constructed? Does the latter approach create too many relayouts, or did it do that in the past? I tried to replicate that design quirk in my code, and had to use RAII to "add child to parent at end of scope", even though I don't want the destructors to run if an exception occurs during UI layout.
- slavik81 7y ago
  I doubt order matters much. Typically you call setupUI() and then show(), so the widget is hidden during initialization. I don't think any layout work actually occurs until the widget becomes visible.

by Crinus 7y ago

jimbo1qaz 7y ago

I prefer writing UI by hand, rather than using Qt Designer. In C++, I figured out a few simple macros to automatically redefine `auto w` and `auto l` to refer to the parent widget and layout. Is there a reason Qt Designer generates .cpp files which append a child to the parent after the child is fully fleshed out, rather than when the child is first constructed? Does the latter approach create too many relayouts, or did it do that in the past? I tried to replicate that design quirk in my code, and had to use RAII to "add child to parent at end of scope", even though I don't want the destructors to run if an exception occurs during UI layout.

slavik81 7y ago
I doubt order matters much. Typically you call setupUI() and then show(), so the widget is hidden during initialization. I don't think any layout work actually occurs until the widget becomes visible.