Комментарии 55
Не понял этот момент:
QRect(0,0 101x101) и вроде бы ширина (и высота) равны 101. Но самом деле это означает реально ширину (или высоту) 100px.
А 101 это количество пикселей, то есть количество от 0 до 100 , и это равно 101 штуке.
Для простоты рассмотрим QRect(0,0 1x1). Согласно тексту, 1 это количество пикселей от 0 до 0, равно 1. А реальная ширина 0px. Что понимается под шириной, если количество пикселей 1 соответствует ширине 0?
Да уж, Qt4… Попробуйте qml table view из набора Qt6 - удивитесь, насколько прощё всё это можно сделать :)
Попробуйте qml table view из набора Qt6
Если не трудно можете продемонстрировать? только без span (это другое)
Не совсем понял, что именно вы хотите увидеть. Посмотрите примеры интерфейсов на qml и почитайте документацию по qml table view + в целом про qml.
Не совсем понял, что именно вы хотите увидеть.
Я про вывод колонок (модели данных) в строке таблицы по шаблону (многорядно).
Насколько я знаю qml это скриптовая оболочка, которая использует Q_PROPERTY классов С++. И если в классах не реализован какой-то функционал, то откуда в Qml он появится.
Qml это не скриптовая оболочка, это полноценный язык разметки, совместимый с js и инфраструктурой qt (проперти, сигналы/слоты, биндинги). Это уже больше чем виджеты. Плюс аппаратный рендеринг.
Если не реализован какой-то функционал, то он просто пишется - в этом и заключается работа программиста. Просто всё что связано с отображением данных на порядок проще делать средствами qml, чем упарываться с переопределением paintEvent и ручным рисованием. А для хранения/модификации данных - старые добрые QAbstractIemModel и их наследники.
Я понимаю что у вас достаточно тривиальные сценарии использования, но если вам понадобится сделать анимации в интерфейсах, то на виджетах вы очень долго будете мучаться.
Спасибо за статью. Ностальжи. Помню начинал с ним работать, когда релизной версией был 4.6 вроде, работало оно более менее, но как вышел QT 5... Матерь божья, они абсолютно забили на поддержку документации (особенно по части обратно совместимости) и половина их примеров или не работали вовсе (из-за кривой работы компонентов или неправильно их использования), или уже давно имели множество альтернативных решений через другие компоненты. Как там с этим дела сейчас? Если я скажем захотел бы мобильное приложение написать на нем? И особенно интересно, как там сейчас дела со встроенным браузером? Помнится он мега криво работал, в плоть до 5.3 где я прекратил работу на с++ вовсе. Были ж времена бгг. Удивительно, как оно продолжает жить, когда на рынке есть много кроссплатформенных решений на разных яп'ах. Людей, что умеют 'приготовить' QT как надо, чтобы он был высокопроизводительным приложением без крит багов, единицы, как по мне (телеграм тому пример), надо им памятник ставить. Почему-то я не удивлен, что таблицы не изменились :)
Для меня история Qt представляется на сегодня таким образом: два норвежских студента за лет 5-7 написали 500-700 классов, а потом команда из нескольких тысяч сотрудников современного Qt не смогла даже понять, что там написано и занимается только продажей старого функционала, обзывая его Qt5,6,7,8.. Вопрос почему?
Там есть огромный хвост совместимости.
То есть код для Qt4 почти без правок соберется для Qt5 (с 6 не пробовал пока, хотя уже пора) и внезапно получит Opengl accelerated отрисовку.
Они огромную работу сделали и с Qt6 (QRhi), проблема в том что старый код (пользователей библиотеки) нельзя прям уж сильно ломать
Они огромную работу сделали и с Qt6 (QRhi)
Можете немного про огромную работу поведать? Я не тролю, я действительно практически хотел бы понять чего я потерял не используя Qt5,6 ,например в десктопном приложении. У меня используется SQlite база, интерфейс для пользователя, соединение с ЛК в интернете.
Если вас 4-ка устраивает, то не вижу особых проблем, работает и ладно.
По идее, Qt4 приложение не будет работать с Drag-n-Drop в новых macOS (старые API формально остались, не уверен про macOS 14, но они поломаные), но опять же не всем надо.
Qt5 мы используем, потому что они дали на Windows абстрацию OpenGL поверх OpenGL или DirectX (через ANGLE), что позволяет иметь один шейдерный код для трех вариантов HW Acceleration (OpenGL, DirectX11, DirectX9).
В Qt5 работают пальцевые жесты (на трекпаде или на тач-мониторе), ну не так чтобы вполне полностью, но можно использовать уже.
Qt6 должен дать одну шейдерную базу поверх DX11/12, OpenGL, Metal, Vulkan. Ждем Qt 6.7 с обещаной QRhiWidget. Наверное к 6.9 можно будет в продакшен потихоньку выпускать.
Это я все про Widgets-based приложения. QML нам не зашло - слишком много надо переписывать (кодовой базе 10+ лет)
В Qt4 нет поддержки HiDPI (кажется даже поддержки маковской ретины нет, но тут могу ошибиться).
Что, конечно, не очень важно для приложений без графики, но даже иконки на тулбарах будут выгядеть so 199x
Вы лучше скажите, чем по вашему Qt4 лучше чем Qt6? А то какие-то странные рассуждения получаются.
Вы лучше скажите, чем по вашему Qt4 лучше чем Qt6?
Вопрос абстрактный и бессмысленный уводящий во флуд. Я практик, мыслю категориями можно или нельзя.
И уже подозреваю на 99%, что в Qt6 ничего относительно QTableView не изменилось
Не изменилось потому что виджеты - зрелая технология для своего времени: отрисовка только на CPU (привет тормоза на 4к мониторах), отсутствие анимаций, отсутствие HiDPI.
Тут нужен был другой подход, и qml - как раз он. Я еще в 2014 общался с ребятами, которые делают qml. Там тоже был тернистый путь и менялись цели. Но про виджеты уже тогда сказали, что там ничего менять не нужно.
Вы говорите что вопрос абстрактный основываясь лишь на вашей конкретной задаче. А если посмотрите в окружающий мир, туда где используется Qt, то вы поймёте что немного застряли в прошлом. Это прекрасно, что вы старыми инструментами смогли неплохо решить свою задачу, но я про то что современными инструментами это всё намного тривиальнее делается.
Я много-го не прошу сделайте, если знаете, демку с таким функционалом. Если не знаете не продолжайте.
Вам надо именно вашу задачу решить? Если вас не устраивает то что есть в примерах и блоге qt (а там много), то я в принципе могу взяться, если вы оплатите моё рабочее время.
Не надо я уже для себя все решил уже и другим предлагаю если интересно бесплатно воспользоваться, чувствуете разницу?
А можно в общих чертах? Я знаю, что задача легко решается для таблицы с одной колонкой, в которой данные распиханы по разным ролям. Но как это сделать с многоколоночной таблицей - неочевидно, у TableView можно только делегаты по колонкам переопределять, нет элемента, который бы имел прямой доступ ко всем данным в строке.
Я знаю, что задача легко решается для таблицы с одной колонкой, в которой данные распиханы по разным ролям
Я такого не встречал. Модель данных работает штатно как и раньше, ее не трогаем.
QTableView у нас полностью свой, но работает по старому принципу. Для каждого поля (колонки) модели данных мы задаём на вьюпорте прямоугольник, куда отрисовываем содержимое из модели данных. Располагать прямоугольники мы можем, где угодно.
В общем-то и все.
Насчёт редактирования, то при щелчке мыши на ячейке, мы имеем координаты клика, по которому определяем прямоугольник ячейки и номер строки/колонки (модели данных) и передаём делегату по умолчанию ( или вами переопределенному) координаты ячейки куда себя (делегата) отрисовать. Все просто.
Элементарная прокси модель, которая склеивает 3 (или N) столбца в один и ручками два делегата: один для заголовка, обычный сплиттер. Второй для ячейки - сплиттер который через проперти привязан к делегату заголовка.
Без прокси модели - намного сложнее, скорее всего без сильного переписывания не обойтись.
проблема в том что старый код (пользователей библиотеки) нельзя прям уж сильно ломать
Если они в приватных классах что-то меняют, то пользователю библиотеки это фиолетово.
Если я скажем захотел бы мобильное приложение написать на нем?
К сожалению не готов сейчас портировать код под андроид или iOs (пока только под Виндой работаю).
Тему правда вентилировал для андроид. Но там нет возможности собирать проект прямо на андроид (как к примеру под Windows или Linux ), а так бы проблем бы вообще никаких не было.
И особенно интересно, как там сейчас дела со встроенным браузером?
Тут к сожалению не знаю от слова совсем. Смотря какой функционал браузера вам нужен. Современные браузеры сами знаете что за монстры.
Интересно, что же это за "много кроссплатформенных решений на разных яп'ах"? Кроме богомерзкой явы ничего и не вспоминается.
Присоединяюсь: я на С++ знаю только фреймворк Qt, ещё вроде wxWidgets есть. На С GTK и все...
Между чем выбирать то? Чем занимаются люди в институтах?
Есть ещё AvaloniaUI на C#, есть куча билбиотек на питоне, начиная со встроенного tk. Но нативно ничего не выглядит, везде какие-то косяки вылезают во внешнем виде или поведении. Собственно, по-моему кроме Qt ничего не выглядит достаточно нативно на десктопных платформах. С мобильными платформами ситуация по-лучше конечно.
(Есть ещё Delphi/Lazarus, которые выглядят хорошо, но в наши дни это уже эзотерика какая-то)
AvaloniaUI на C#, есть куча библиотек на питоне
Давайте ограничим список языком С++, открытыми исходниками и инструментом компилятор/линковщик. То что вы приводите уже интерпретаторы и вы становитесь заложником какой-то фирмы - будет она делать свою библиотеку кроссплатформенно? Ну например Microsoft? Уже звучит глупо.
Питон конечно кроссплатформенность будет поддерживать, но как и у любого интерпретатора если что-то заглючило, то ты заложник их ошибок. То есть тебя лишают свободы (образно говоря).
Кстати Delphi/Lazarus наверное хороший пример, там отрисовка нативная (насколько я помню), но begin/end просто невыносимо.
Ну например Microsoft? Уже звучит глупо.
Я не очень в теме, но по-моему Microsoft как раз заопенсорсила .NET настолько, что это сделало возможным кроссплатформенный (и опенсорсный) AvaloniaUI (который работает как на Mono, так и на .Net Core).
Изначальный аргумент был "много кроссплатформенных решений на разных яп'ах", а вы предлагаете ограничить дискуссию только С++.
Питон конечно кроссплатформенность будет поддерживать, но как и у любого интерпретатора если что-то заглючило, то ты заложник их ошибок. То есть тебя лишают свободы (образно говоря).
Мне не кажется, что интерпретируемость питона имеет какое-то существенное значение в этом плане. С той же вероятностью вы заложник багов компилятора или реализации стандартной бибилотеки в компилируемых языках, это больше зависит от популярности языка и размере комьюнити, которое его поддерживает.
С той же вероятностью вы заложник багов компилятора или реализации стандартной бибилотеки в компилируемых языках
Соглашусь, но я бы назвал это зависимостью первого уровня, а от интерпретирования команд зависимостью второго уровня и т.д.
Подозреваю, что сам питон пишется на С++ , компилируется и линкуется под разные платформы.
А почему при изменении высоты одной строки, меняются высоты всех остальных строк в таблице? По-моему это не совсем то поведение, которое нужно. В одной строке может быть много данных записано и чтобы их отобразить полностью мы увеличиваем высоту строки, а в других строках мало данных, но их высота тоже меняется и в итоге получаем много пустого неиспользуемого места
"А почему при изменении высоты одной строки, меняются высоты всех остальных строк в таблице?"
На мой взгляд так "правильнее" и главное для реализации проще. К тому же человеческий глаз очень положительно реагирует на симметрию.
Мы сразу чувствуем единообразие и у нас возникает доверие, что тут все упорядочено и проработано.
Если делать разную высоту строк, то визуально на первый взгляд будет что-то не то, и мозг будет цепляться за это. В общем это усложняет восприятие.
Хотя реализовать дополнительно такой вариант можно, но придется где-то хранить высоты строк, а если строк тысяча или более?...
переопределяем метод painEvent класса QTableView
Забавная опечатка, наверное, вы этим хотели выразить ту боль, которую вы испытали, пока получили рабочее решение :)
Доброго времени. Будет много букв.
А по другому не получается, то есть сделать чисто открытое наследование от QAbstractItemView можно, оно скомпилируется, но при сборке линковщик не найдет методы QAbstratItemViewPrivate
Не совсем понятно, что не получается? Если вы используете только члены и функции класса QAbstractItemView, то никакой проблемы нет при наследовании. Если же вы пытаетесь также использовать что-то из QAbstratItemViewPrivate, то полученный вами результат логичен.
Если кто знает как можно сделать свой класс , уналедованный от QAbstractItemView, чтобы можно было свободно его распространять без необходимости лезть в исходники Qt - буду безмерно признателен...
Вот пример наследования (да, пример на Qt5, но сути не меняет):
//myview.h
#include <QAbstractItemView>
class MyView : public QAbstractItemView
{
Q_OBJECT
Q_DISABLE_COPY(MyView)
public:
MyView(QWidget *parent = nullptr);
~MyView(){}
// QAbstractItemView interface
public:
virtual QRect visualRect(const QModelIndex& index) const override;
virtual void scrollTo(const QModelIndex& index, ScrollHint hint) override;
virtual QModelIndex indexAt(const QPoint& point) const override;
protected:
virtual QModelIndex moveCursor(CursorAction cursorAction, Qt::KeyboardModifiers modifiers) override;
virtual int horizontalOffset() const override;
virtual int verticalOffset() const override;
virtual bool isIndexHidden(const QModelIndex& index) const override;
virtual void setSelection(const QRect& rect, QItemSelectionModel::SelectionFlags command) override;
virtual QRegion visualRegionForSelection(const QItemSelection& selection) const override;
};
//myview.cpp
MyView::MyView(QWidget* parent)
: QAbstractItemView(parent)
{
}
QRect MyView::visualRect(const QModelIndex& index) const
{
return QRect();
}
void MyView::scrollTo(const QModelIndex& index, ScrollHint hint)
{
}
QModelIndex MyView::indexAt(const QPoint& point) const
{
return QModelIndex();
}
QModelIndex MyView::moveCursor(CursorAction cursorAction, Qt::KeyboardModifiers modifiers)
{
return QModelIndex();
}
int MyView::horizontalOffset() const
{
return 0;
}
int MyView::verticalOffset() const
{
return 0;
}
bool MyView::isIndexHidden(const QModelIndex& index) const
{
return false;
}
void MyView::setSelection(const QRect& rect, QItemSelectionModel::SelectionFlags command)
{
}
QRegion MyView::visualRegionForSelection(const QItemSelection& selection) const
{
return QRegion();
}Все спокойно собирается и работает.
Большинство классов Qt имеют внутри приватные части, в которых и прячется "логика" этих классов. Такие классы имеют в конце приписку Private. Вы никогда от других классов, кроме QAbstractItemView, не наследовались? Даже у QWidget есть такой класс - QWidgetPrivate.
С другой стороны один раз сделав сборку из исходников понимаешь, что процесс добавления своего функционала внутрь, отладка, сборка совсем не трудные операции
Конечно, не трудные. К тому же в нете достаточное количество мануалов по этому поводу, не говоря уже про наличии официального мануала от Qt.
Другое дело, сборка занимает сравнительно много времени и ресурсов на диске. Году так в 2015 у меня сборка Qt4.8.7 занимала ~2 часа времени, сейчас конечно намного быстрее. А по размеру - сейчас, например, сборка Qt6.6 в статик и debud_and_release занимает порядка 80Гб.
Тут используется таймер потому, что в событии moveMouseEvent нельзя сразу отрисовывать таблицу или хэдер.
Можно, кто ж запрещает то? Другое дело, что движение мыши по таблице вызывает ее перерисовку..
По поводу делегатов, то тут все просто: делегату передается прямоугольник ячейки и далее делегат сам все отрисовывает в ячейке как ему надо. Это про комбобоксы, всякие чекбоксы и т.д.
Это не только комбобоксы, всякие чекбоксы и т.д. Делегаты занимаются как раз отрисовкой всего содержимого ячейки для соответствующего QModelIndex. С помощью них можете все что угодно рисовать внутри ячеек. Даже то же, что вы описываете во второй части статьи.
Оказывается если мы видим через qDebug() такое: QRect(0,0 101x101) и вроде бы ширина (и высота) равны 101. Но самом деле это означает реально ширину (или высоту) 100px.
Я тут выше в своем комментарии несколько ошибся. Правильно так вычисляется ширина:
inline int QRect::width() const
{ return x2 - x1 + 1; }Почему именно так, то полагаю это из-за того, как происходит отрисовка. Это хорошо описано в доке и даже с картинками.
Ну и под конец -
фреймворк Qt и последние 10 лет ничего почти в нем не менялось.
тут вроде много Вам примеров привели, что поменялось и довольно существенно.
Так, например, в Qt5 кардинально пересмотрели работы мета-объектной сисиемы и moc-компилятора. В связи с чем перешли на новую сигнатуру функций QObject::connect(...). Как результат: теперь о невозможности произвести коннект разработчик узнает на этапе сборки проекта.
Дополню о Qt6.
С версии Qt6.5 под Win 11 начали использовать новое апи. И теперь стала возможна нативная поддержка системных темных тем, без танцев с бубном, так и переключение "день\ночь" при соответствующем переключении системной темы. Подробнее на их сайте Dark Mode on Windows 11 with Qt 6.5
Другое дело, сборка занимает сравнительно много времени и ресурсов на диске.
На самом деле gui ветка собирается минуту, если что-там немного подправить и минуты 4-5 полная переборка ветки.
Это про динамику (не статику)
class MyView : public QAbstractItemView
Ваш пример конечно нормально собирается, но вы не наследует приватный класс QAbstractViewItemPrivate.
Соответственно тут нет проблем, но нет и смысла. Вам надо в своем cpp иметь доступ к методам приватного класса QAbstractItemView, чтобы использовать приватный функционал.
Вы сможете конечно сделать так в myview cpp:
Q_D(QAbstractItemView);
И сможете использовать конструкцию d-> . Но это не решит полностью проблему сборки вашего проекта.
У меня есть тестовый небольшой проект для этого, я постараюсь скинуть ссылку в ближайшее время.
вы не наследует приватный класс QAbstractViewItemPrivate
Это да. Просто не совсем понятно, зачем его наследовать то? Виртуальных методов там нет. То есть я лично вижу 2 варианта:
1) Можем либо только что-то свое добавить. А смысл?
2) Либо изменить имеющиеся реализации. Но это приведет к тому, что придется еще и поддержать Qt'шные классы.
QTableView использует QAbstractViewItemPrivate. Для своего же класса, наследованного от QTableView, можете аналогично сделать приватный класс с требуемым функционалом. Аналогично как это и делает сам Qt.
Я правда не совсем понимаю необходимость создания таких приватных секций. Мне они в Qt доставляют только лишний гемор. Я решал схожую с вашей задачу и мне было проще переопределить нужные мне виртуальные функции. Но этот огрызок в приватной части, все равно остается, только уже мертвым грузом, который не выкинуть, но и его функционал мне не подходит.
Поэтому мне и интересно, зачем оно вам)
QTableView использует QAbstractViewItemPrivate. Для своего же класса, наследованного от QTableView, можете аналогично сделать приватный класс с требуемым функционалом. Аналогично как это и делает сам Qt
Да именно так и сделал в итоге и все вынес из исходников наружу. Все теперь нормально собирается вне исходников, то есть штатно, удобно и т.д.
Просто не совсем понятно, зачем его наследовать то?
Там есть несколько переменных типа offset (по цепочке у родителя QSrollArea... чего-то там), offset используется при скроллинге например у QTableView.
Я правда не совсем понимаю необходимость создания таких приватных секций
Тут я с одной стороны понимаю, это для того чтобы иметь возможность переписывать приватные классы как угодно, чтобы пользователь библиотек даже не заметил этого.
С другой стороны у QScrollAreaPrivate признак экспорта есть, то есть пользователь имеет доступ к его приватным методам извне. А у QAbstractItemView экспорта нет. Как-то не последовательно получается....
Единственно может имеется ввиду, что приватный интерфейс QAbstractItemViewPrivate надо понимать как на стадии разработки, то есть не устоявшийся, на стадии тестирования.
Тогда интересно как в Qt5,6 он тоже всё ещё на стадии тестирования?
Все спокойно собирается и работает.
Речь об этом примерно (myview.h):
#ifndef MYVIEW_H
#define MYVIEW_H
#include <QAbstractItemView>
//class QAbstractItemViewPrivate;
class MyViewPrivate;
class MyView : public QAbstractItemView
{
Q_OBJECT
public:
explicit MyView(QWidget *parent = 0);
virtual ~MyView();
// QAbstractItemView interface
public:
virtual QRect visualRect(const QModelIndex& index) const;
virtual void scrollTo(const QModelIndex& index, ScrollHint hint);
virtual QModelIndex indexAt(const QPoint& point) const;
protected:
virtual QModelIndex moveCursor(CursorAction cursorAction, Qt::KeyboardModifiers modifiers);
virtual int horizontalOffset() const;
virtual int verticalOffset() const;
virtual bool isIndexHidden(const QModelIndex& index) const;
virtual void setSelection(const QRect& rect, QItemSelectionModel::SelectionFlags command);
virtual QRegion visualRegionForSelection(const QItemSelection& selection) const;
signals:
public slots:
private:
Q_DECLARE_PRIVATE(MyView)
Q_DISABLE_COPY(MyView)
};
#endif // MYVIEW_H
myview.cpp:
#include "myview.h"
#include <private/qabstractitemview_p.h>
#include "myview_p.h"
MyView::MyView(QWidget *parent) :
QAbstractItemView(parent)
{
setSelectionMode( QAbstractItemView::SingleSelection );
Q_D( MyView );
// !! d->init(); ??????????????? выдает ошибку !!!!!
}
MyView::~MyView()
{
}
QRect MyView::visualRect(const QModelIndex& index) const
{
Q_D(const MyView);
return QRect();
}
..........
Не знаю как сюда подцепить файл с проектом, поэтому ссылка:
https://kkmspb.ru/development/Qt/private-classes-paradigma.php
Короче - почему не получается юзать приватный функционал Qt снаружи от исходников Qt
Не тот конструктор использован. В этом коде не инстанцируется MyViewPrivate. Если используется наследование приватной части pimpl, нужно использовать конструктор QAbstractItemView(QAbstractItemViewPrivate &, QWidget *parent = nullptr);
Да согласен с конструкторами не корректно написал. Вот два конструктора public и второй protected:
MyView::MyView(QWidget *parent) // public
:
QAbstractItemView( *new MyViewPrivate, parent) // ошибки линковки !!!!!!
// myview.obj:-1: error: LNK2001: unresolved external symbol
// "public: virtual void __thiscall QAbstractItemViewPrivate::_q_rowsRemoved(class QModelIndex const &,int,int)" (?_q_rowsRemoved@QAbstractItemViewPrivate@@UAEXABVQModelIndex@@HH@Z)
{
setSelectionMode( QAbstractItemView::SingleSelection );
}
MyView::MyView(MyViewPrivate &dd, QWidget *parent) // protected
: QAbstractItemView(dd, parent)
{
Q_D(MyView);
}
MyView::~MyView()
{
}Это сделано как в QTableView в.т.ч. Но ошибки линковки присутствуют. Собственно откуда можно линковщику найти реализацию _q_rowsRemoved , в библиотеках Qt их нет (точнее они не экспортируемые).
new MyViewPrivate логично не слинкуется
Хорошая новость:
class Q_GUI_EXPORT QAbstractScrollAreaPrivate: public QFramePrivateQ_GUI_EXPORT QAbstractScrollAreaPrivate это означает, что можно слепить свой QAbstratcItemView, а вот QAbstractScrollArea уже свой делать НЕ придется(методы его приватного класса как и его самого конечно-же ЭКСПОРТИРУЕМЫЕ).
Кстати далее по цепочке так:
class QFramePrivate : public QWidgetPrivate
class Q_GUI_EXPORT QWidgetPrivate : public QObjectPrivate
class Q_CORE_EXPORT QObjectPrivate : public QObjectData
Интересно как в Qt5,Qt6 с этим...
Короче проверил, оказывается действительно надо добавлять в свой проект клон QAbstractItemView (мы его преобразуем, с позволения Qt, в QpAbstractItemView) и далее все будет прекрасно собираться вне исходников Qt (то есть исходники Qt более не трогаем).
Проект уже обновлен на гитхабе (с версии 2.x.x уже можно качать и собирать в своих проектах)
https://github.com/PavelDorofeev/How-to-create-own-QTableView-with-new-capabilities
Всем успехов!
Пишем свой QTableView с нуля