Files
qt-creator/tests/manual/layoutbuilder/v2/lb.cpp

973 lines
22 KiB
C++
Raw Normal View History

LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
// Copyright (C) 2020 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
#include "lb.h"
#include <QDebug>
#include <QFormLayout>
#include <QGridLayout>
#include <QGroupBox>
#include <QLabel>
#include <QPushButton>
#include <QSpacerItem>
#include <QSpinBox>
#include <QSplitter>
#include <QStackedLayout>
#include <QStackedWidget>
#include <QStyle>
#include <QTabWidget>
#include <QTextEdit>
#include <QToolBar>
namespace Layouting {
// That's cut down qtcassert.{c,h} to avoid the dependency.
#define QTC_STRINGIFY_HELPER(x) #x
#define QTC_STRINGIFY(x) QTC_STRINGIFY_HELPER(x)
#define QTC_STRING(cond) qDebug("SOFT ASSERT: \"%s\" in %s: %s", cond, __FILE__, QTC_STRINGIFY(__LINE__))
#define QTC_ASSERT(cond, action) if (Q_LIKELY(cond)) {} else { QTC_STRING(#cond); action; } do {} while (0)
#define QTC_CHECK(cond) if (cond) {} else { QTC_STRING(#cond); } do {} while (0)
template <typename X>
X::Implementation *access(const X *x)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
return static_cast<X::Implementation *>(x->ptr);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
template <typename X>
void apply(X *x, std::initializer_list<typename X::I> ps)
{
for (auto && p : ps)
p.apply(x);
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
// FlowLayout
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
class FlowLayout : public QLayout
{
public:
explicit FlowLayout(QWidget *parent, int margin = -1, int hSpacing = -1, int vSpacing = -1)
: QLayout(parent), m_hSpace(hSpacing), m_vSpace(vSpacing)
{
setContentsMargins(margin, margin, margin, margin);
}
FlowLayout(int margin = -1, int hSpacing = -1, int vSpacing = -1)
: m_hSpace(hSpacing), m_vSpace(vSpacing)
{
setContentsMargins(margin, margin, margin, margin);
}
~FlowLayout() override
{
QLayoutItem *item;
while ((item = takeAt(0)))
delete item;
}
void addItem(QLayoutItem *item) override { itemList.append(item); }
int horizontalSpacing() const
{
if (m_hSpace >= 0)
return m_hSpace;
else
return smartSpacing(QStyle::PM_LayoutHorizontalSpacing);
}
int verticalSpacing() const
{
if (m_vSpace >= 0)
return m_vSpace;
else
return smartSpacing(QStyle::PM_LayoutVerticalSpacing);
}
Qt::Orientations expandingDirections() const override
{
return {};
}
bool hasHeightForWidth() const override { return true; }
int heightForWidth(int width) const override
{
int height = doLayout(QRect(0, 0, width, 0), true);
return height;
}
int count() const override { return itemList.size(); }
QLayoutItem *itemAt(int index) const override
{
return itemList.value(index);
}
QSize minimumSize() const override
{
QSize size;
for (QLayoutItem *item : itemList)
size = size.expandedTo(item->minimumSize());
int left, top, right, bottom;
getContentsMargins(&left, &top, &right, &bottom);
size += QSize(left + right, top + bottom);
return size;
}
void setGeometry(const QRect &rect) override
{
QLayout::setGeometry(rect);
doLayout(rect, false);
}
QSize sizeHint() const override
{
return minimumSize();
}
QLayoutItem *takeAt(int index) override
{
if (index >= 0 && index < itemList.size())
return itemList.takeAt(index);
else
return nullptr;
}
private:
int doLayout(const QRect &rect, bool testOnly) const
{
int left, top, right, bottom;
getContentsMargins(&left, &top, &right, &bottom);
QRect effectiveRect = rect.adjusted(+left, +top, -right, -bottom);
int x = effectiveRect.x();
int y = effectiveRect.y();
int lineHeight = 0;
for (QLayoutItem *item : itemList) {
QWidget *wid = item->widget();
int spaceX = horizontalSpacing();
if (spaceX == -1)
spaceX = wid->style()->layoutSpacing(
QSizePolicy::PushButton, QSizePolicy::PushButton, Qt::Horizontal);
int spaceY = verticalSpacing();
if (spaceY == -1)
spaceY = wid->style()->layoutSpacing(
QSizePolicy::PushButton, QSizePolicy::PushButton, Qt::Vertical);
int nextX = x + item->sizeHint().width() + spaceX;
if (nextX - spaceX > effectiveRect.right() && lineHeight > 0) {
x = effectiveRect.x();
y = y + lineHeight + spaceY;
nextX = x + item->sizeHint().width() + spaceX;
lineHeight = 0;
}
if (!testOnly)
item->setGeometry(QRect(QPoint(x, y), item->sizeHint()));
x = nextX;
lineHeight = qMax(lineHeight, item->sizeHint().height());
}
return y + lineHeight - rect.y() + bottom;
}
int smartSpacing(QStyle::PixelMetric pm) const
{
QObject *parent = this->parent();
if (!parent) {
return -1;
} else if (parent->isWidgetType()) {
auto pw = static_cast<QWidget *>(parent);
return pw->style()->pixelMetric(pm, nullptr, pw);
} else {
return static_cast<QLayout *>(parent)->spacing();
}
}
QList<QLayoutItem *> itemList;
int m_hSpace;
int m_vSpace;
};
/*!
\namespace Layouting
\inmodule QtCreator
\brief The Layouting namespace contains classes and functions to conveniently
create layouts in code.
Classes in the namespace help to create create QLayout or QWidget derived class,
instances should be used locally within a function and never stored.
\sa Layouting::Widget, Layouting::Layout
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
*/
/*!
\class Layouting::Layout
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
\inmodule QtCreator
The Layout class is a base class for more specific builder
classes to create QLayout derived objects.
*/
/*!
\class Layouting::Widget
\inmodule QtCreator
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
The Widget class is a base class for more specific builder
classes to create QWidget derived objects.
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
*/
/*!
\class Layouting::LayoutItem
\inmodule QtCreator
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
The LayoutItem class is used for intermediate results
while creating layouts with a concept of rows and spans, such
as Form and Grid.
*/
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
Layout::LayoutItem::LayoutItem() = default;
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
Layout::LayoutItem::~LayoutItem() = default;
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
Layout::LayoutItem::LayoutItem(const LayoutModifier &inner)
{
ownerModifier = inner;
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
/*!
\fn template <class T> LayoutItem(const T &t)
\internal
Constructs a layout item proxy for \a t.
T could be
\list
\li \c {QString}
\li \c {QWidget *}
\li \c {QLayout *}
\endlist
*/
// Object
Object::Object(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
static QWidget *widgetForItem(QLayoutItem *item)
{
if (QWidget *w = item->widget())
return w;
if (item->spacerItem())
return nullptr;
if (QLayout *l = item->layout()) {
for (int i = 0, n = l->count(); i < n; ++i) {
if (QWidget *w = widgetForItem(l->itemAt(i)))
return w;
}
}
return nullptr;
}
static QLabel *createLabel(const QString &text)
{
auto label = new QLabel(text);
label->setTextInteractionFlags(Qt::TextSelectableByMouse);
return label;
}
using LayoutItem = Layout::LayoutItem;
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
static void addItemToBoxLayout(QBoxLayout *layout, const LayoutItem &item)
{
if (QWidget *w = item.widget) {
layout->addWidget(w);
} else if (QLayout *l = item.layout) {
layout->addLayout(l);
} else if (item.stretch != -1) {
layout->addStretch(item.stretch);
} else if (!item.text.isEmpty()) {
layout->addWidget(createLabel(item.text));
} else if (item.empty) {
// Nothing to do, but no reason to warn, either.
} else {
QTC_CHECK(false);
}
}
static void addItemToFlowLayout(FlowLayout *layout, const LayoutItem &item)
{
if (QWidget *w = item.widget) {
layout->addWidget(w);
} else if (QLayout *l = item.layout) {
layout->addItem(l);
// } else if (item.stretch != -1) {
// layout->addStretch(item.stretch);
} else if (item.empty) {
// Nothing to do, but no reason to warn, either
} else if (!item.text.isEmpty()) {
layout->addWidget(createLabel(item.text));
} else {
QTC_CHECK(false);
}
}
/*!
\class Layouting::Space
\inmodule QtCreator
\brief The Space class represents some empty space in a layout.
*/
/*!
\class Layouting::Stretch
\inmodule QtCreator
\brief The Stretch class represents some stretch in a layout.
*/
// Layout
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
void Layout::span(int cols, int rows)
{
QTC_ASSERT(!pendingItems.empty(), return);
pendingItems.back().spanCols = cols;
pendingItems.back().spanRows = rows;
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
void Layout::noMargin()
{
customMargin({});
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
void Layout::normalMargin()
{
customMargin({9, 9, 9, 9});
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
void Layout::customMargin(const QMargins &margin)
{
access(this)->setContentsMargins(margin);
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
/*!
Attaches the constructed layout to the provided QWidget \a w.
This operation can only be performed once per LayoutBuilder instance.
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
*/
void Layout::attachTo(QWidget *widget)
{
flush();
widget->setLayout(access(this));
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
/*!
Adds the layout item \a item as sub items.
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
*/
void Layout::addItem(I item)
{
item.apply(this);
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
void Layout::addItemHelper(const LayoutItem &item)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
if (QBoxLayout *lt = asBox())
addItemToBoxLayout(lt, item);
else if (FlowLayout *lt = asFlow())
addItemToFlowLayout(lt, item);
else
pendingItems.push_back(item);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
/*!
Adds the layout items \a items as sub items.
*/
void Layout::addItems(std::initializer_list<I> items)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
for (const I &item : items)
item.apply(this);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
/*!
Starts a new row containing \a items. The row can be further extended by
other items using \c addItem() or \c addItems().
\sa addItem(), addItems()
*/
void Layout::addRow(std::initializer_list<I> items)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
for (const I &item : items)
item.apply(this);
flush();
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void Layout::setSpacing(int spacing)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setSpacing(spacing);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void Layout::setColumnStretch(int column, int stretch)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
if (auto grid = qobject_cast<QGridLayout *>(access(this))) {
grid->setColumnStretch(column, stretch);
} else {
QTC_CHECK(false);
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void addToWidget(Widget *widget, const Layout &layout)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
layout.flush_();
access(widget)->setLayout(access(&layout));
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void addToLayout(Layout *layout, const Widget &inner)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
LayoutItem item;
item.widget = access(&inner);
layout->addItemHelper(item);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void addToLayout(Layout *layout, QWidget *inner)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
LayoutItem item;
item.widget = inner;
layout->addItemHelper(item);
}
void addToLayout(Layout *layout, QLayout *inner)
{
LayoutItem item;
item.layout = inner;
layout->addItemHelper(item);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void addToLayout(Layout *layout, const Layout &inner)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
inner.flush_();
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
LayoutItem item;
item.layout = access(&inner);
layout->addItemHelper(item);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void addToLayout(Layout *layout, const LayoutModifier &inner)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
inner(layout);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void addToLayout(Layout *layout, const QString &inner)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
LayoutItem item;
item.text = inner;
layout->addItemHelper(item);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void empty(Layout *iface)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
LayoutItem item;
item.empty = true;
iface->addItemHelper(item);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void hr(Layout *layout)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
layout->addItemHelper(createHr());
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void br(Layout *iface)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
iface->flush();
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void st(Layout *iface)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
LayoutItem item;
item.stretch = 1;
iface->addItemHelper(item);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void noMargin(Layout *iface)
{
iface->noMargin();
}
void normalMargin(Layout *iface)
{
iface->normalMargin();
}
QFormLayout *Layout::asForm()
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
return qobject_cast<QFormLayout *>(access(this));
}
QGridLayout *Layout::asGrid()
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
return qobject_cast<QGridLayout *>(access(this));
}
QBoxLayout *Layout::asBox()
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
return qobject_cast<QBoxLayout *>(access(this));
}
FlowLayout *Layout::asFlow()
{
return dynamic_cast<FlowLayout *>(access(this));
}
void Layout::flush()
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
if (pendingItems.empty())
return;
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
if (QGridLayout *lt = asGrid()) {
for (const LayoutItem &item : std::as_const(pendingItems)) {
Qt::Alignment a;
if (currentGridColumn == 0 && useFormAlignment) {
// if (auto widget = builder.stack.at(builder.stack.size() - 2).widget) {
// a = widget->style()->styleHint(QStyle::SH_FormLayoutLabelAlignment);
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
if (item.widget)
lt->addWidget(item.widget, currentGridRow, currentGridColumn, item.spanRows, item.spanCols, a);
else if (item.layout)
lt->addLayout(item.layout, currentGridRow, currentGridColumn, item.spanRows, item.spanCols, a);
else if (!item.text.isEmpty())
lt->addWidget(createLabel(item.text), currentGridRow, currentGridColumn, item.spanRows, item.spanCols, a);
currentGridColumn += item.spanCols;
// Intentionally not used, use 'br'/'empty' for vertical progress.
// currentGridRow += item.spanRows;
}
++currentGridRow;
currentGridColumn = 0;
pendingItems.clear();
return;
}
if (QFormLayout *fl = asForm()) {
if (pendingItems.size() > 2) {
auto hbox = new QHBoxLayout;
hbox->setContentsMargins(0, 0, 0, 0);
for (size_t i = 1; i < pendingItems.size(); ++i)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
addItemToBoxLayout(hbox, pendingItems.at(i));
while (pendingItems.size() > 1)
pendingItems.pop_back();
pendingItems.push_back(hbox);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
if (pendingItems.size() == 1) { // Only one item given, so this spans both columns.
const LayoutItem &f0 = pendingItems.at(0);
if (auto layout = f0.layout)
fl->addRow(layout);
else if (auto widget = f0.widget)
fl->addRow(widget);
} else if (pendingItems.size() == 2) { // Normal case, both columns used.
LayoutItem &f1 = pendingItems[1];
const LayoutItem &f0 = pendingItems.at(0);
if (!f1.widget && !f1.layout && !f1.text.isEmpty())
f1.widget = createLabel(f1.text);
// QFormLayout accepts only widgets or text in the first column.
// FIXME: Should we be more generous?
if (f0.widget) {
if (f1.layout)
fl->addRow(f0.widget, f1.layout);
else if (f1.widget)
fl->addRow(f0.widget, f1.widget);
} else {
if (f1.layout)
fl->addRow(createLabel(f0.text), f1.layout);
else if (f1.widget)
fl->addRow(createLabel(f0.text), f1.widget);
}
} else {
QTC_CHECK(false);
}
// Set up label as buddy if possible.
const int lastRow = fl->rowCount() - 1;
QLayoutItem *l = fl->itemAt(lastRow, QFormLayout::LabelRole);
QLayoutItem *f = fl->itemAt(lastRow, QFormLayout::FieldRole);
if (l && f) {
if (QLabel *label = qobject_cast<QLabel *>(l->widget())) {
if (QWidget *widget = widgetForItem(f))
label->setBuddy(widget);
}
}
pendingItems.clear();
return;
}
QTC_CHECK(false); // The other layouts shouldn't use flush()
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void Layout::flush_() const
{
const_cast<Layout *>(this)->flush();
}
void withFormAlignment(Layout *iface)
{
iface->useFormAlignment = true;
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
// Flow
Flow::Flow(std::initializer_list<I> ps)
{
ptr = new FlowLayout;
apply(this, ps);
flush();
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
// Row & Column
Row::Row(std::initializer_list<I> ps)
{
ptr = new QHBoxLayout;
apply(this, ps);
flush();
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
Column::Column(std::initializer_list<I> ps)
{
ptr = new QVBoxLayout;
apply(this, ps);
flush();
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
// Grid
Grid::Grid()
{
ptr = new QGridLayout;
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
Grid::Grid(std::initializer_list<I> ps)
{
ptr = new QGridLayout;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
flush();
}
// Form
Form::Form()
{
ptr = new QFormLayout;
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
Form::Form(std::initializer_list<I> ps)
{
auto lt = new QFormLayout;
ptr = lt;
lt->setFieldGrowthPolicy(QFormLayout::AllNonFixedFieldsGrow);
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
flush();
}
void Layout::fieldGrowthPolicy(int policy)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
if (auto lt = asForm())
lt->setFieldGrowthPolicy(QFormLayout::FieldGrowthPolicy(policy));
}
QWidget *Layout::emerge() const
{
const_cast<Layout *>(this)->flush();
QWidget *widget = new QWidget;
widget->setLayout(access(this));
return widget;
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
// "Widgets"
Widget::Widget(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void Widget::setSize(int w, int h)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->resize(w, h);
}
void Widget::setLayout(const Layout &layout)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setLayout(access(&layout));
}
void Widget::setWindowTitle(const QString &title)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setWindowTitle(title);
}
void Widget::setToolTip(const QString &title)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setToolTip(title);
}
void Widget::show()
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->show();
}
void Widget::noMargin(int)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
customMargin({});
}
void Widget::normalMargin(int)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
customMargin({9, 9, 9, 9});
}
void Widget::customMargin(const QMargins &margin)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setContentsMargins(margin);
}
QWidget *Widget::emerge() const
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
return access(this);
}
// Label
Label::Label(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
Label::Label(const QString &text)
{
ptr = new Implementation;
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
setText(text);
}
void Label::setText(const QString &text)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setText(text);
}
// Group
Group::Group(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void Group::setTitle(const QString &title)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setTitle(title);
access(this)->setObjectName(title);
}
void Group::setGroupChecker(const std::function<void (QObject *)> &checker)
{
checker(access(this));
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
// SpinBox
SpinBox::SpinBox(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void SpinBox::setValue(int val)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setValue(val);
}
void SpinBox::onTextChanged(const std::function<void (QString)> &func)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
QObject::connect(access(this), &QSpinBox::textChanged, func);
}
// TextEdit
TextEdit::TextEdit(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void TextEdit::setText(const QString &text)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setText(text);
}
// PushButton
PushButton::PushButton(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
void PushButton::setText(const QString &text)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
access(this)->setText(text);
}
void PushButton::onClicked(const std::function<void ()> &func, QObject *guard)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
QObject::connect(access(this), &QAbstractButton::clicked, guard, func);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
// Stack
// We use a QStackedWidget instead of a QStackedLayout here because the latter will call
// "setVisible()" when a child is added, which can lead to the widget being spawned as a
// top-level widget. This can lead to the focus shifting away from the main application.
Stack::Stack(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
}
void addToStack(Stack *stack, const Widget &inner)
{
access(stack)->addWidget(inner.emerge());
}
void addToStack(Stack *stack, const Layout &inner)
{
inner.flush_();
access(stack)->addWidget(inner.emerge());
}
void addToStack(Stack *stack, QWidget *inner)
{
access(stack)->addWidget(inner);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
// Splitter
Splitter::Splitter(std::initializer_list<I> ps)
{
ptr = new Implementation;
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
access(this)->setOrientation(Qt::Vertical);
apply(this, ps);
}
void addToSplitter(Splitter *splitter, QWidget *inner)
{
access(splitter)->addWidget(inner);
}
void addToSplitter(Splitter *splitter, const Widget &inner)
{
access(splitter)->addWidget(inner.emerge());
}
void addToSplitter(Splitter *splitter, const Layout &inner)
{
inner.flush_();
access(splitter)->addWidget(inner.emerge());
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
// ToolBar
ToolBar::ToolBar(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
access(this)->setOrientation(Qt::Horizontal);
}
// TabWidget
TabWidget::TabWidget(std::initializer_list<I> ps)
{
ptr = new Implementation;
apply(this, ps);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
Tab::Tab(const QString &tabName, const Layout &inner)
: tabName(tabName), inner(inner)
{}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
void addToTabWidget(TabWidget *tabWidget, const Tab &tab)
{
access(tabWidget)->addTab(tab.inner.emerge(), tab.tabName);
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
// Special If
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
If::If(bool condition,
const std::initializer_list<Layout::I> ifcase,
const std::initializer_list<Layout::I> thencase)
: used(condition ? ifcase : thencase)
{}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
void addToLayout(Layout *layout, const If &inner)
{
for (const Layout::I &item : inner.used)
item.apply(layout);
}
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
// Specials
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
QWidget *createHr(QWidget *parent)
{
auto frame = new QFrame(parent);
frame->setFrameShape(QFrame::HLine);
frame->setFrameShadow(QFrame::Sunken);
return frame;
}
Span::Span(int n, const Layout::I &item)
: item(item), spanCols(n)
{}
void addToLayout(Layout *layout, const Span &inner)
{
LayoutItem item;
layout->addItem(inner.item);
QTC_ASSERT(!layout->pendingItems.empty(), return);
layout->pendingItems.back().spanCols = inner.spanCols;
layout->pendingItems.back().spanRows = inner.spanRows;
}
LayoutModifier spacing(int space)
{
return [space](Layout *iface) { iface->setSpacing(space); };
}
void addToLayout(Layout *layout, const Space &inner)
{
if (auto lt = layout->asBox())
lt->addSpacing(inner.space);
}
void addToLayout(Layout *layout, const Stretch &inner)
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
{
if (auto lt = layout->asBox())
lt->addStretch(inner.stretch);
LayoutBuilder: Complete experimental implementation This adds support for inheritance to the existing experimental implementation in tests/manual/layoutbuilder/experimental and gets rid of the tight coupling and qobject_casts in the setter implementations. Plan is to use this (minus "bindings" via *::Id / id()) for utils/layoutbuilder.{h,cpp} later. The "binding" support via id() is still experimental, and in its current version not really useful. A possible idea would be to re-use the Tasking::Storage idea, but it's not quite clear how to expose that "long distance" (i.e. across multiple, unrelated top-level builders). However, this is not used in in current uses of the "old" layoutbuilder, so this is not blocking anything. Some notes: The *Interface hierarchy is not strictly needed, it could directly act on things in the QObject hierarchy but would then need #includes of all "buildable" classes, which can be avoided in the current implementation. Besides, the indirection allows us to tweak and/or add functionailty to the Qt classes in the indirecting code, that does not necessarily have to match 1:1 to the underlyings Qt classes. The std::function based callbacks are quite fat and not functionally needed and could be dropped by "inlining" the relevant bits from typical std::function implementations. However, these invariably seem to end up calling functions through pointers to (ABI-compatible, but) different types, which is for /user/ code formally undefined behavior according to C++11 §5.2.10/6. To avoid a discussion whether doing the same ourselves is tolerable or not, this uses std::function and pays the price of the overhead. Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
}
// void createItem(LayoutItem *item, QWidget *t)
// {
// if (auto l = qobject_cast<QLabel *>(t))
// l->setTextInteractionFlags(l->textInteractionFlags() | Qt::TextSelectableByMouse);
// item->onAdd = [t](LayoutBuilder &builder) { doAddWidget(builder, t); };
// }
} // Layouting