> Even if not using the QFormBuilder and a user change all the properties at a > widget using the Qt Designer we are subject to the same issue, aren't we?
More or less, that's why I said that QDesigner is full of special cases which address some issues. > More and more this looks to me like a bug that should be addressed. The raising awareness of issues caused by the lack of orthogonality between properties is a good thing. > Given this is not being done consistently across Qt and/or the meta > object system lacks these informations, this is all pointing towards > deprecating QFormBuilder as a "real" utility and being more like some > just quick-glue code lacking a robust use case. Well, in fact QFormBuilder is doing very simple thing and IMO it's doing it in the right way. We may of course deprecate it, which won't change the fact that Qt properties will remain non-orthogonal and will continue to cause issues. ________________________________________ From: Hugo Slepicka <[email protected]> Sent: Tuesday, October 29, 2019 5:48 PM To: Giuseppe D'Angelo Cc: Jaroslaw Kobus; Volker Hilsheimer; [email protected] Subject: Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI I agree with Giuseppe and I would like to add to it the fact that properties are restored in what I could guess as alphabetical order, which in itself already causes problems for custom widgets. That said, when developing custom widgets developers must pay attention to this fact of properties that are somewhat interlinked. It comes as a surprise that the core Qt code does not take that into consideration. More and more this looks to me like a bug that should be addressed. Even if not using the QFormBuilder and a user change all the properties at a widget using the Qt Designer we are subject to the same issue, aren't we? On Tue, Oct 29, 2019 at 4:14 AM Giuseppe D'Angelo via Development <[email protected]<mailto:[email protected]>> wrote: On 29/10/2019 11:32, Jaroslaw Kobus wrote: > Take any of QWidget's properties, e.g. sizePolicy, grep through qt sources > and search where setSizePolicy is used - QAbstractSlider::setOrientation(), > so "orientation" property of abstract slider influences "sizePolicy" - > non-orthogonality detected. > If you store both properties, and then read them - the result depend on the > read order. Sorry, I'm lost now. If you store them both and apply them in either order, shouldn't the result be correct no matter what? == If this is not true for some case: we have an API problem, and we can debate whether it's in the class featuring interlinked properties, or in the meta property system that is not clearly reflecting the dependencies, thus making a (de)serializer of such properties impossible to write correctly. And the latter has way more profound implications than just serializing the state of a QObject (e.g. thinking of IPC like DBus, QtRO, etc.). Thanks, -- Giuseppe D'Angelo | [email protected]<mailto:[email protected]> | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected]<mailto:[email protected]> https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
