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) 2023 André Pönitz
|
|
|
|
|
// Copyright (C) 2023 The Qt Company Ltd.
|
|
|
|
|
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR BSD-3-Clause
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
#include <QMargins>
|
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
|
|
|
#include <QString>
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
#include <functional>
|
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
|
|
|
#include <initializer_list>
|
|
|
|
|
|
|
|
|
|
#if defined(UTILS_LIBRARY)
|
|
|
|
|
# define QTCREATOR_UTILS_EXPORT Q_DECL_EXPORT
|
|
|
|
|
#elif defined(UTILS_STATIC_LIBRARY)
|
|
|
|
|
# define QTCREATOR_UTILS_EXPORT
|
|
|
|
|
#else
|
|
|
|
|
# define QTCREATOR_UTILS_EXPORT Q_DECL_IMPORT
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
QT_BEGIN_NAMESPACE
|
|
|
|
|
class QBoxLayout;
|
|
|
|
|
class QFormLayout;
|
|
|
|
|
class QGridLayout;
|
|
|
|
|
class QGroupBox;
|
2024-05-22 13:49:57 +02:00
|
|
|
class QHBoxLayout;
|
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 QLabel;
|
|
|
|
|
class QLayout;
|
|
|
|
|
class QMargins;
|
|
|
|
|
class QObject;
|
|
|
|
|
class QPushButton;
|
|
|
|
|
class QSpinBox;
|
|
|
|
|
class QSplitter;
|
|
|
|
|
class QStackedWidget;
|
|
|
|
|
class QTabWidget;
|
|
|
|
|
class QTextEdit;
|
|
|
|
|
class QToolBar;
|
2024-05-22 13:49:57 +02:00
|
|
|
class QVBoxLayout;
|
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 QWidget;
|
|
|
|
|
QT_END_NAMESPACE
|
|
|
|
|
|
2024-07-17 16:25:40 +02:00
|
|
|
namespace Building {
|
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 NestId {};
|
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-06-04 11:13:36 +02:00
|
|
|
template <typename Id, typename Arg>
|
2024-05-22 13:49:57 +02:00
|
|
|
class IdAndArg
|
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
|
|
|
public:
|
2024-06-04 11:13:36 +02:00
|
|
|
IdAndArg(Id, const Arg &arg) : arg(arg) {}
|
|
|
|
|
const Arg arg; // FIXME: Could be const &, but this would currently break bindTo().
|
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 main dispatcher
|
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 doit(auto x, auto id, auto p);
|
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> class BuilderItem
|
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
|
|
|
{
|
|
|
|
|
public:
|
2024-05-22 13:49:57 +02:00
|
|
|
// Property setter
|
|
|
|
|
template <typename Id, typename Arg>
|
|
|
|
|
BuilderItem(IdAndArg<Id, Arg> && idarg)
|
2024-07-18 10:11:33 +02:00
|
|
|
: apply([&idarg](X *x) { doit(x, Id{}, idarg.arg); })
|
|
|
|
|
{}
|
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
|
|
|
// Nested child object
|
|
|
|
|
template <typename Inner>
|
|
|
|
|
BuilderItem(Inner && p)
|
2024-07-18 10:11:33 +02:00
|
|
|
: apply([&p](X *x) { doit(x, NestId{}, std::forward<Inner>(p)); })
|
|
|
|
|
{}
|
2024-07-17 16:25:40 +02:00
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
std::function<void(X *)> apply;
|
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
|
|
|
#define QTC_DEFINE_BUILDER_SETTER(name, setter) \
|
|
|
|
|
class name##_TAG {}; \
|
|
|
|
|
template <typename ...Args> \
|
|
|
|
|
inline auto name(Args &&...args) { \
|
|
|
|
|
return Building::IdAndArg{name##_TAG{}, std::tuple<Args...>{std::forward<Args>(args)...}}; \
|
|
|
|
|
} \
|
|
|
|
|
template <typename L, typename ...Args> \
|
|
|
|
|
inline void doit(L *x, name##_TAG, const std::tuple<Args...> &arg) { \
|
|
|
|
|
std::apply(&L::setter, std::tuple_cat(std::make_tuple(x), arg)); \
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // Building
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
namespace Layouting {
|
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
|
|
|
|
|
|
|
|
//////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// Basic
|
|
|
|
|
//
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Thing
|
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
|
|
|
public:
|
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 *ptr; // The product.
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Object : public Thing
|
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
|
|
|
public:
|
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
|
|
|
using Implementation = QObject;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Object>;
|
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
|
|
|
Object() = 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
|
|
|
Object(std::initializer_list<I> ps);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// Layouts
|
|
|
|
|
//
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class FlowLayout;
|
|
|
|
|
class Layout;
|
|
|
|
|
using LayoutModifier = std::function<void(Layout *)>;
|
|
|
|
|
// using LayoutModifier = void(*)(Layout *);
|
|
|
|
|
|
|
|
|
|
class QTCREATOR_UTILS_EXPORT Layout : public Object
|
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
|
|
|
public:
|
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
|
|
|
using Implementation = QLayout;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Layout>;
|
2024-05-22 13:49:57 +02:00
|
|
|
|
|
|
|
|
Layout() = default;
|
|
|
|
|
Layout(Implementation *w) { ptr = w; }
|
|
|
|
|
|
|
|
|
|
class LayoutItem
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
~LayoutItem();
|
|
|
|
|
LayoutItem();
|
|
|
|
|
LayoutItem(QLayout *l) : layout(l) {}
|
|
|
|
|
LayoutItem(QWidget *w) : widget(w) {}
|
|
|
|
|
LayoutItem(const QString &t) : text(t) {}
|
|
|
|
|
LayoutItem(const LayoutModifier &inner);
|
|
|
|
|
|
|
|
|
|
QString text;
|
|
|
|
|
QLayout *layout = nullptr;
|
|
|
|
|
QWidget *widget = nullptr;
|
|
|
|
|
int stretch = -1;
|
|
|
|
|
int spanCols = 1;
|
|
|
|
|
int spanRows = 1;
|
|
|
|
|
bool empty = false;
|
|
|
|
|
LayoutModifier ownerModifier;
|
|
|
|
|
//Qt::Alignment align = {};
|
|
|
|
|
};
|
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 span(int cols, int rows);
|
|
|
|
|
void noMargin();
|
|
|
|
|
void normalMargin();
|
|
|
|
|
void customMargin(const QMargins &margin);
|
2024-05-22 13:49:57 +02:00
|
|
|
void setColumnStretch(int cols, int rows);
|
|
|
|
|
void setSpacing(int space);
|
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 attachTo(QWidget *);
|
|
|
|
|
void addItemHelper(const LayoutItem &item);
|
|
|
|
|
void addItem(I item);
|
|
|
|
|
void addItems(std::initializer_list<I> items);
|
|
|
|
|
void 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
|
|
|
|
|
|
|
|
void flush();
|
2024-05-22 13:49:57 +02:00
|
|
|
void flush_() 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
|
|
|
void fieldGrowthPolicy(int policy);
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
QWidget *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
|
|
|
QFormLayout *asForm();
|
|
|
|
|
QGridLayout *asGrid();
|
|
|
|
|
QBoxLayout *asBox();
|
2024-05-22 13:49:57 +02:00
|
|
|
FlowLayout *asFlow();
|
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-only
|
|
|
|
|
int currentGridColumn = 0;
|
|
|
|
|
int currentGridRow = 0;
|
2024-05-22 13:49:57 +02:00
|
|
|
//Qt::Alignment align = {};
|
|
|
|
|
bool useFormAlignment = 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
|
|
|
std::vector<LayoutItem> pendingItems;
|
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 QTCREATOR_UTILS_EXPORT Column : public 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
|
|
|
public:
|
|
|
|
|
using Implementation = QVBoxLayout;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Column>;
|
2024-05-22 13:49:57 +02:00
|
|
|
|
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(std::initializer_list<I> ps);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Row : public 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
|
|
|
public:
|
|
|
|
|
using Implementation = QHBoxLayout;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Row>;
|
2024-05-22 13:49:57 +02:00
|
|
|
|
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(std::initializer_list<I> ps);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Form : public 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
|
|
|
public:
|
|
|
|
|
using Implementation = QFormLayout;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Form>;
|
2024-05-22 13:49:57 +02:00
|
|
|
|
|
|
|
|
Form();
|
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(std::initializer_list<I> ps);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Grid : public 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
|
|
|
public:
|
|
|
|
|
using Implementation = QGridLayout;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Grid>;
|
2024-05-22 13:49:57 +02:00
|
|
|
|
|
|
|
|
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
|
|
|
Grid(std::initializer_list<I> ps);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Flow : public 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
|
|
|
public:
|
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(std::initializer_list<I> ps);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT 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
|
|
|
public:
|
|
|
|
|
explicit Stretch(int stretch) : stretch(stretch) {}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
class QTCREATOR_UTILS_EXPORT Space
|
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
|
|
|
public:
|
|
|
|
|
explicit Space(int space) : space(space) {}
|
|
|
|
|
|
|
|
|
|
int space;
|
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 QTCREATOR_UTILS_EXPORT Span
|
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
|
|
|
public:
|
|
|
|
|
Span(int n, const Layout::I &item);
|
|
|
|
|
|
|
|
|
|
Layout::I item;
|
|
|
|
|
int spanCols = 1;
|
|
|
|
|
int spanRows = 1;
|
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
|
|
|
|
|
//
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Widget : public Object
|
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
|
|
|
public:
|
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
|
|
|
using Implementation = QWidget;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Widget>;
|
2024-05-22 13:49:57 +02:00
|
|
|
|
|
|
|
|
Widget() = default;
|
|
|
|
|
Widget(std::initializer_list<I> ps);
|
|
|
|
|
Widget(Implementation *w) { ptr = w; }
|
|
|
|
|
|
|
|
|
|
QWidget *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
|
|
|
|
|
|
|
|
void show();
|
2024-07-17 16:25:40 +02:00
|
|
|
void setSize(int, int);
|
2024-05-22 13:49:57 +02:00
|
|
|
void 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
|
|
|
void setWindowTitle(const QString &);
|
|
|
|
|
void setToolTip(const QString &);
|
2024-05-22 13:49:57 +02:00
|
|
|
void noMargin(int = 0);
|
|
|
|
|
void normalMargin(int = 0);
|
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 customMargin(const QMargins &margin);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Label : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
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
|
|
|
using Implementation = QLabel;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Label>;
|
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(std::initializer_list<I> ps);
|
|
|
|
|
Label(const QString &text);
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
void setText(const QString &);
|
|
|
|
|
};
|
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 QTCREATOR_UTILS_EXPORT Group : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
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
|
|
|
using Implementation = QGroupBox;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Group>;
|
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
|
|
|
|
|
|
|
|
Group(std::initializer_list<I> ps);
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
void setTitle(const QString &);
|
|
|
|
|
void setGroupChecker(const std::function<void(QObject *)> &);
|
|
|
|
|
};
|
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 QTCREATOR_UTILS_EXPORT SpinBox : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
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
|
|
|
using Implementation = QSpinBox;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<SpinBox>;
|
2024-05-22 13:49:57 +02:00
|
|
|
|
|
|
|
|
SpinBox(std::initializer_list<I> ps);
|
LayoutBuilder: Complete experimental implementation
This adds support for inheritance to the existing experimental
implementation in tests/manual/layoutbuilder/experimental
and gets rid of the tight coupling and qobject_casts in the
setter implementations. Plan is to use this (minus "bindings"
via *::Id / id()) for utils/layoutbuilder.{h,cpp} later.
The "binding" support via id() is still experimental, and in
its current version not really useful. A possible idea would
be to re-use the Tasking::Storage idea, but it's not quite
clear how to expose that "long distance" (i.e. across multiple,
unrelated top-level builders). However, this is not used in
in current uses of the "old" layoutbuilder, so this is not
blocking anything.
Some notes:
The *Interface hierarchy is not strictly needed, it could directly
act on things in the QObject hierarchy but would then need #includes
of all "buildable" classes, which can be avoided in the current
implementation. Besides, the indirection allows us to tweak and/or
add functionailty to the Qt classes in the indirecting code, that
does not necessarily have to match 1:1 to the underlyings Qt classes.
The std::function based callbacks are quite fat and not functionally
needed and could be dropped by "inlining" the relevant bits from
typical std::function implementations. However, these invariably seem
to end up calling functions through pointers to (ABI-compatible, but)
different types, which is for /user/ code formally undefined behavior
according to C++11 §5.2.10/6. To avoid a discussion whether doing
the same ourselves is tolerable or not, this uses std::function
and pays the price of the overhead.
Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
|
|
|
|
|
|
|
|
void setValue(int);
|
|
|
|
|
void onTextChanged(const std::function<void(QString)> &);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT PushButton : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
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
|
|
|
using Implementation = QPushButton;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<PushButton>;
|
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
|
|
|
|
|
|
|
|
PushButton(std::initializer_list<I> ps);
|
|
|
|
|
|
|
|
|
|
void setText(const QString &);
|
2024-05-22 13:49:57 +02:00
|
|
|
void onClicked(const std::function<void()> &, 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
|
|
|
class QTCREATOR_UTILS_EXPORT TextEdit : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
|
|
|
|
using Implementation = QTextEdit;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<TextEdit>;
|
2024-05-22 13:49:57 +02:00
|
|
|
using Id = 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
|
|
|
TextEdit(std::initializer_list<I> ps);
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
void setText(const QString &);
|
|
|
|
|
};
|
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 QTCREATOR_UTILS_EXPORT Splitter : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
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
|
|
|
using Implementation = QSplitter;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Splitter>;
|
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(std::initializer_list<I> items);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Stack : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
|
|
|
|
using Implementation = QStackedWidget;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<Stack>;
|
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() : Stack({}) {}
|
|
|
|
|
Stack(std::initializer_list<I> items);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT Tab : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
|
|
|
|
using Implementation = QWidget;
|
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(const QString &tabName, 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
|
|
|
const QString tabName;
|
|
|
|
|
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
|
|
|
class QTCREATOR_UTILS_EXPORT TabWidget : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
|
|
|
|
using Implementation = QTabWidget;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<TabWidget>;
|
2024-05-22 13:49:57 +02:00
|
|
|
|
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
|
|
|
TabWidget(std::initializer_list<I> items);
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT ToolBar : public 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
|
|
|
{
|
2024-05-22 13:49:57 +02:00
|
|
|
public:
|
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
|
|
|
using Implementation = QToolBar;
|
2024-07-17 16:25:40 +02:00
|
|
|
using I = Building::BuilderItem<ToolBar>;
|
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(std::initializer_list<I> items);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// Special
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class QTCREATOR_UTILS_EXPORT 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
|
|
|
public:
|
|
|
|
|
If(bool condition,
|
|
|
|
|
const std::initializer_list<Layout::I> ifcase,
|
|
|
|
|
const std::initializer_list<Layout::I> thencase = {});
|
|
|
|
|
|
|
|
|
|
const std::initializer_list<Layout::I> used;
|
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
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// Dispatchers
|
|
|
|
|
//
|
|
|
|
|
|
|
|
|
|
// We need one 'Id' (and a corresponding function wrapping arguments into a
|
|
|
|
|
// tuple marked by this id) per 'name' of "backend" setter member function,
|
|
|
|
|
// i.e. one 'text' is sufficient for QLabel::setText, QLineEdit::setText.
|
|
|
|
|
// The name of the Id does not have to match the backend names as it
|
|
|
|
|
// is mapped per-backend-type in the respective setter implementation
|
|
|
|
|
// but we assume that it generally makes sense to stay close to the
|
|
|
|
|
// wrapped API name-wise.
|
|
|
|
|
|
|
|
|
|
// These are free functions overloaded on the type of builder object
|
|
|
|
|
// and setter id. The function implementations are independent, but
|
|
|
|
|
// the base expectation is that they will forwards to the backend
|
|
|
|
|
// type's setter.
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
// Special dispatchers
|
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 BindToId {};
|
LayoutBuilder: Complete experimental implementation
This adds support for inheritance to the existing experimental
implementation in tests/manual/layoutbuilder/experimental
and gets rid of the tight coupling and qobject_casts in the
setter implementations. Plan is to use this (minus "bindings"
via *::Id / id()) for utils/layoutbuilder.{h,cpp} later.
The "binding" support via id() is still experimental, and in
its current version not really useful. A possible idea would
be to re-use the Tasking::Storage idea, but it's not quite
clear how to expose that "long distance" (i.e. across multiple,
unrelated top-level builders). However, this is not used in
in current uses of the "old" layoutbuilder, so this is not
blocking anything.
Some notes:
The *Interface hierarchy is not strictly needed, it could directly
act on things in the QObject hierarchy but would then need #includes
of all "buildable" classes, which can be avoided in the current
implementation. Besides, the indirection allows us to tweak and/or
add functionailty to the Qt classes in the indirecting code, that
does not necessarily have to match 1:1 to the underlyings Qt classes.
The std::function based callbacks are quite fat and not functionally
needed and could be dropped by "inlining" the relevant bits from
typical std::function implementations. However, these invariably seem
to end up calling functions through pointers to (ABI-compatible, but)
different types, which is for /user/ code formally undefined behavior
according to C++11 §5.2.10/6. To avoid a discussion whether doing
the same ourselves is tolerable or not, this uses std::function
and pays the price of the overhead.
Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
|
|
|
|
|
|
|
|
template <typename T>
|
2024-05-22 13:49:57 +02:00
|
|
|
auto bindTo(T **p)
|
|
|
|
|
{
|
2024-07-17 16:25:40 +02:00
|
|
|
return Building::IdAndArg{BindToId{}, p};
|
LayoutBuilder: Complete experimental implementation
This adds support for inheritance to the existing experimental
implementation in tests/manual/layoutbuilder/experimental
and gets rid of the tight coupling and qobject_casts in the
setter implementations. Plan is to use this (minus "bindings"
via *::Id / id()) for utils/layoutbuilder.{h,cpp} later.
The "binding" support via id() is still experimental, and in
its current version not really useful. A possible idea would
be to re-use the Tasking::Storage idea, but it's not quite
clear how to expose that "long distance" (i.e. across multiple,
unrelated top-level builders). However, this is not used in
in current uses of the "old" layoutbuilder, so this is not
blocking anything.
Some notes:
The *Interface hierarchy is not strictly needed, it could directly
act on things in the QObject hierarchy but would then need #includes
of all "buildable" classes, which can be avoided in the current
implementation. Besides, the indirection allows us to tweak and/or
add functionailty to the Qt classes in the indirecting code, that
does not necessarily have to match 1:1 to the underlyings Qt classes.
The std::function based callbacks are quite fat and not functionally
needed and could be dropped by "inlining" the relevant bits from
typical std::function implementations. However, these invariably seem
to end up calling functions through pointers to (ABI-compatible, but)
different types, which is for /user/ code formally undefined behavior
according to C++11 §5.2.10/6. To avoid a discussion whether doing
the same ourselves is tolerable or not, this uses std::function
and pays the price of the overhead.
Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <typename Interface>
|
|
|
|
|
void doit(Interface *x, BindToId, auto p)
|
|
|
|
|
{
|
|
|
|
|
*p = static_cast<Interface::Implementation *>(x->ptr);
|
|
|
|
|
}
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
class IdId {};
|
2024-07-17 16:25:40 +02:00
|
|
|
auto id(auto p) { return Building::IdAndArg{IdId{}, p}; }
|
LayoutBuilder: Complete experimental implementation
This adds support for inheritance to the existing experimental
implementation in tests/manual/layoutbuilder/experimental
and gets rid of the tight coupling and qobject_casts in the
setter implementations. Plan is to use this (minus "bindings"
via *::Id / id()) for utils/layoutbuilder.{h,cpp} later.
The "binding" support via id() is still experimental, and in
its current version not really useful. A possible idea would
be to re-use the Tasking::Storage idea, but it's not quite
clear how to expose that "long distance" (i.e. across multiple,
unrelated top-level builders). However, this is not used in
in current uses of the "old" layoutbuilder, so this is not
blocking anything.
Some notes:
The *Interface hierarchy is not strictly needed, it could directly
act on things in the QObject hierarchy but would then need #includes
of all "buildable" classes, which can be avoided in the current
implementation. Besides, the indirection allows us to tweak and/or
add functionailty to the Qt classes in the indirecting code, that
does not necessarily have to match 1:1 to the underlyings Qt classes.
The std::function based callbacks are quite fat and not functionally
needed and could be dropped by "inlining" the relevant bits from
typical std::function implementations. However, these invariably seem
to end up calling functions through pointers to (ABI-compatible, but)
different types, which is for /user/ code formally undefined behavior
according to C++11 §5.2.10/6. To avoid a discussion whether doing
the same ourselves is tolerable or not, this uses std::function
and pays the price of the overhead.
Change-Id: I6d40c1bd48cf065fcf211eaff8d9a2298bca20eb
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
2024-05-03 15:04:54 +02:00
|
|
|
|
|
|
|
|
template <typename Interface>
|
|
|
|
|
void doit(Interface *x, IdId, auto p)
|
|
|
|
|
{
|
|
|
|
|
*p = static_cast<Interface::Implementation *>(x->ptr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Setter dispatchers
|
|
|
|
|
|
|
|
|
|
|
2024-07-17 16:25:40 +02:00
|
|
|
QTC_DEFINE_BUILDER_SETTER(fieldGrowthPolicy, setFieldGrowthPolicy)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(groupChecker, setGroupChecker)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(openExternalLinks, setOpenExternalLinks)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(size, setSize)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(text, setText)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(textFormat, setTextFormat)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(textInteractionFlags, setTextInteractionFlags)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(title, setTitle)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(toolTip, setToolTip)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(windowTitle, setWindowTitle)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(wordWrap, setWordWrap);
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(orientation, setOrientation);
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(columnStretch, setColumnStretch)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(onClicked, onClicked)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(onLinkHovered, onLinkHovered)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(onTextChanged, onTextChanged)
|
|
|
|
|
QTC_DEFINE_BUILDER_SETTER(customMargins, setContentsMargins)
|
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
|
|
|
|
|
|
|
|
// Nesting dispatchers
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, const Layout &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, const Widget &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, QWidget *inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, QLayout *inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, const LayoutModifier &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, const QString &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, const Space &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, const Stretch &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, const If &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToLayout(Layout *layout, const Span &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
|
|
|
// ... can be added to anywhere later to support "user types"
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
QTCREATOR_UTILS_EXPORT void addToWidget(Widget *widget, const Layout &layout);
|
|
|
|
|
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToTabWidget(TabWidget *tabWidget, const Tab &inner);
|
|
|
|
|
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToSplitter(Splitter *splitter, QWidget *inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToSplitter(Splitter *splitter, const Widget &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToSplitter(Splitter *splitter, const Layout &inner);
|
|
|
|
|
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToStack(Stack *stack, QWidget *inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToStack(Stack *stack, const Widget &inner);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void addToStack(Stack *stack, const Layout &inner);
|
|
|
|
|
|
|
|
|
|
template <class Inner>
|
|
|
|
|
void doit_nested(Layout *outer, Inner && inner)
|
|
|
|
|
{
|
|
|
|
|
addToLayout(outer, std::forward<Inner>(inner));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void doit_nested(Widget *outer, auto inner)
|
|
|
|
|
{
|
|
|
|
|
addToWidget(outer, inner);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void doit_nested(TabWidget *outer, auto 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
|
|
|
addToTabWidget(outer, 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 doit_nested(Stack *outer, auto inner)
|
|
|
|
|
{
|
|
|
|
|
addToStack(outer, inner);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void doit_nested(Splitter *outer, auto inner)
|
|
|
|
|
{
|
|
|
|
|
addToSplitter(outer, inner);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <class Inner>
|
2024-07-17 16:25:40 +02:00
|
|
|
void doit(auto outer, Building::NestId, Inner && inner)
|
2024-05-22 13:49:57 +02:00
|
|
|
{
|
|
|
|
|
doit_nested(outer, std::forward<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
|
|
|
|
|
|
|
|
// Special layout items
|
|
|
|
|
|
2024-05-22 13:49:57 +02:00
|
|
|
QTCREATOR_UTILS_EXPORT void empty(Layout *);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void br(Layout *);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void st(Layout *);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void noMargin(Layout *);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void normalMargin(Layout *);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void withFormAlignment(Layout *);
|
|
|
|
|
QTCREATOR_UTILS_EXPORT void hr(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
|
|
|
QTCREATOR_UTILS_EXPORT LayoutModifier spacing(int space);
|
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
|
|
|
|
|
|
|
|
// Convenience
|
|
|
|
|
|
|
|
|
|
QTCREATOR_UTILS_EXPORT QWidget *createHr(QWidget *parent = nullptr);
|
|
|
|
|
|
|
|
|
|
} // Layouting
|