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)
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
\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
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*!
|
2024-05-22 13:49:57 +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
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*!
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
// 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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
|
|
|
|
/*!
|
2024-05-22 13:49:57 +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
|
|
|
*/
|
2024-05-22 13:49:57 +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
|
|
|
|
|
|
|
|
/*!
|
2024-05-22 13:49:57 +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
|
|
|
*/
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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);
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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);
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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;
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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;
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
{
|
2024-05-22 13:49:57 +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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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;
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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));
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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));
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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));
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
{
|
2024-05-22 13:49:57 +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)) {
|
2024-05-22 13:49:57 +02:00
|
|
|
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);
|
2024-05-22 13:49:57 +02:00
|
|
|
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();
|
2024-05-22 13:49:57 +02:00
|
|
|
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;
|
|
|
|
|
}
|
2024-05-22 13:49:57 +02:00
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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();
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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));
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-07-17 16:25:40 +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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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));
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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();
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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({});
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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});
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
{
|
2024-05-22 13:49:57 +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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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);
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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
|
|
|
|
2024-05-22 13:49:57 +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;
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
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
|
|
|
{
|
2024-05-22 13:49:57 +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
|