Здравствуйте, _hum_, Вы писали:
__>и я уже выше говорил — нет, мне недостаточно этих данных, потому что я хочу размещать редактор своего делегата сам (в произвольном нужном мне месте таблицы), соответственно, должен знать, где располагается этот parent относительно изображения таблицы (дабы понять, где начало координат). а это, в свою очередь, зависит от того, кем является parent — если основным полем таблицы — одно, если фреймом — другое, если виджетом строки — третье, и т.п.
Тогда сами создавайте редактор в обработчике мышиных эвентов в делегате. Не завязывайтесь на createEditor.
SaZ>>Если же вам хочется узнать, что именно скрывается за этим парентом, то вам нужно взять этот парент и уже работать с ним. Это другой контекст, он не относится к методу createEditor. Он относится именно к классу QWidget : public QObject. Которые так же хорошо документированы.
__>а можно показать пример того, о чем вы говорите — можете найти в документации информацию о том, кем является этот парент (дабы ответить на вопрос, где расположено начало координат отрисовки эдитора относительно поля таблицы)?
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, _hum_, Вы писали:
__>>и я уже выше говорил — нет, мне недостаточно этих данных, потому что я хочу размещать редактор своего делегата сам (в произвольном нужном мне месте таблицы), соответственно, должен знать, где располагается этот parent относительно изображения таблицы (дабы понять, где начало координат). а это, в свою очередь, зависит от того, кем является parent — если основным полем таблицы — одно, если фреймом — другое, если виджетом строки — третье, и т.п.
SaZ>Тогда сами создавайте редактор в обработчике мышиных эвентов в делегате. Не завязывайтесь на createEditor.
зачем так сложно. можно же создать в createEditor, а потом просто в updateEditorGeometry перепозицонировать и перерисовать при необходимости. но речь, напоминаю, шла не о том, как сделать, а о том, что описание функции createEditor в документации qt корявое, сбивающее с толку.
SaZ>>>Если же вам хочется узнать, что именно скрывается за этим парентом, то вам нужно взять этот парент и уже работать с ним. Это другой контекст, он не относится к методу createEditor. Он относится именно к классу QWidget : public QObject. Которые так же хорошо документированы.
__>>а можно показать пример того, о чем вы говорите — можете найти в документации информацию о том, кем является этот парент (дабы ответить на вопрос, где расположено начало координат отрисовки эдитора относительно поля таблицы)?
SaZ>Где расположено? — http://doc.qt.io/qt-5/qstyleoptionviewitem.html
если вы про QStyleOptionViewItem::rect, то выше ж уже обсуждали: во-первых, в доке не написано, что именно в этом rect содержится ("This variable holds the area that should be used for various calculations and painting"), а во-вторых, даже если там координаты ячейки, то все равно нет информации о том, где в этой системе координат находятся границы таблицы (ведь, напоминаю, речь шла именно о том, что для отрисовки подсказки в моем примере мне нужно знать, где расположены границы таблицы) и без знания, кем является parent (основным виджетом таблицы или каким-то спец. виджетом), это выяснить в createEditor не представляется возможным. [это все к вопросу о том, почему дока по createEditor может вынудить читателя озадачиться вопросом, чем же на самом деле является parent]
SaZ>Либо, если вы сами пишите делегат, то вы знаете, для какой вьюхи он используется. Я вообще всегда в конструктор делегата передаю указатель на вьюху. Потому что парент — не обязательно вьюха, а, как вы верно заметили, любой виджет.
да, пришлось именно так и делать. но мне это решение не очень нравится, потому как происходит распараллеливание информации о вьюхе — с одной стороны мы привязываем делегат к вьюхе (через тот же setItemDelegate), и значит, у делегата, по идее, уже может быть информация о вьюхе, к которой он привязан, а с другой, я его еще и параллельно снабжаю этой информацией для своих нужд. и случись рассинхронизация (прилепи я этот же делегат к другой вьюхе) — начнется UB.
SaZ>Тогда, имея индекс — http://doc.qt.io/qt-5/qabstractitemview.html#visualRect
да, спасибо, эта функция удобнее, чем то, чем я пользовался — функциями типа columnViewportPosition.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, _hum_, Вы писали:
__>>не, знания того, что это наследник QWidget недостаточно, потому как представление таблицы, гипотетически, может быть организовано сложным образом, например, каждая строка может быть представлена в виде отдельного виджета (а потому информация о том, где же границы таблицы, так и остаться неизвестными).
SaZ>Достаточно, если вы следуете концепции Qt MVC. Если же нет — то тогда вам нужно свою реализацию всего.
SaZ>Если же каждая строка в неком абстрактном вью будет представлена в виде виджета, то вам всё равно придёт парент в виде QWidget. Какой именно — неважно. Потому что в противном случае нарушается принцип полиморфизма. А Qt очень хорошо следует ООП и паттернам.
не, вы снова забываете про мой иллюстративный пример (Image: 2b87ad284cf2.png ), в котором важно знать границы таблицы, а для этого надо знать, на каком именно родителе рисуется ячейка (ведь именно он задает систему координат для ее отрисовки и определяет границы области видимости)
SaZ>Если вы фрилансер или любите экспериментировать с экзотическими средами под С++, то стоит обратить внимание на экосистему Ultimate++...
SaZ>Захотелось людям поэкспериментировать — хорошо. Но для продакшн кода этому проекту врядли светит дорасти. И не только по техническим причинам.
Так и было поэкспериментировал. Пришел к выводу что для некоторых задач идеальный инструмент.
SaZ>Как там с поддержкой кросс-платформенности / WinRT? Удобно ли добавлять новые API c выходом новых версий винды? Есть ли комьюнити / поддержка?
Работает на window / linux. Комьюнити есть, баги правятся. WinRT не целевая платформа так не является десктопной.
Что вы имеете ввиде под новыми API — DirectX12. Если оно вам надо вы будете юзать готовый движок.
Ultimate++ только на десктопах и серверах работает от i486 до Xeon, пускается даже под Win95 на самом убогом железе и не требует доп. библиотек.
Позволяет решать очень широкий круг задач, дешево и быстро.
SaZ>И вот таких вопросов можно задать вагон. SaZ>Ответ на которые однозначно определяет кто есть кто.
Вот почему то эти вопросы никто не задаёт лидерам. Они продолжают гнуть свою линию и всех это устраивает.
К примеру java всё вроде отлично полный entrprise всё очень правильно и комьюнить, и поддержка, и фирма вроде серьёзная. Но системы работающие на java требют огромных ресурсов и частенько костылей в виде watchdog-ов т.к. начинаю по неизвестным причинам выедать всю имеющуюся память и люто тормозить. А рекомендации типа min 64Gb озу... Вобщем грусть и печаль.
SaZ>Ну не будут люди пересаживаться на самодельные мопеды с хорошо отлаженных автомобилей.
Так никто и не заставляет вас пересаживаться. Инструмент определяется задачами.
Главная задача программиста это не использование самой свежей студии, на самом топовом железе, и не создание приложений с самыи свежими api которые приводят к не совместимости с предыдущими системами на которых сидят основные массы. Главная задача выполнить поставленную задачу при фиксированном наборе ограничений.
Здравствуйте, _hum_, Вы писали:
__>не, вы снова забываете про мой иллюстративный пример (Image: 2b87ad284cf2.png ), в котором важно знать границы таблицы, а для этого надо знать, на каком именно родителе рисуется ячейка (ведь именно он задает систему координат для ее отрисовки и определяет границы области видимости)
Я всё помню. Посвторюсь: если нужна эта инфа, то сохраняйте её в поле своего делегата.
Здравствуйте, kov_serg, Вы писали:
_>Так и было поэкспериментировал. Пришел к выводу что для некоторых задач идеальный инструмент.
У меня сейчас сервер на Qt. Многие говорят, что извращение, но со своими задачами справляется идеально. И пул потоков есть, и веб реквесты, и json/xml/sql из коробки.
_>...WinRT не целевая платформа так не является десктопной. Что? Тут всё с вами понятно
_>Что вы имеете ввиде под новыми API — DirectX12. Если оно вам надо вы будете юзать готовый движок.
Тогда отпадает смысл в U++. Под новыми апи я имею в виду тот же метро.
_>Ultimate++ только на десктопах и серверах работает от i486 до Xeon, пускается даже под Win95 на самом убогом железе и не требует доп. библиотек. _>Позволяет решать очень широкий круг задач, дешево и быстро.
Этот круг значительно меньше, чем у Qt. При том, что читаемость кода ниже.
_>К примеру java всё вроде отлично полный entrprise всё очень правильно и комьюнить, и поддержка, и фирма вроде серьёзная. Но системы работающие на java требют огромных ресурсов и частенько костылей в виде watchdog-ов т.к. начинаю по неизвестным причинам выедать всю имеющуюся память и люто тормозить. А рекомендации типа min 64Gb озу... Вобщем грусть и печаль.
Ну так на джаве значительно ниже порог вхождения. Каждым инструментом надо уметь пользоваться. К примеру, многие веб-сервисы твиттера написаны на джаве. Есть балансировщик (на плюсах), который мониторит сервера. Как только java приложение понимает, что слишком много мусора, GC ест много времени, высокая фрагментация кучи и вообще, скоро всё ляжет, то приложение уведомляет балансировщик об этом. Балансировщик перестаёт отправлять запросы этому серверу. Сервер заканчивает обрабатывать все уже поступившие запросы и перезагружается. Далее оповещает балансировщик, что он снова готов к работе.
Понятно, что надо выбирать баланс между стоимостью разработки, стоимостью железа и желаемой производительностью. Так вот, в случае U++ всё печально, потому что стоимость разработки очень высокая (а именно — стоимость ответа разработчиков на нетривиальные вопросы).
_>Так никто и не заставляет вас пересаживаться. Инструмент определяется задачами.
Это в идеале. На практике, как правило, инструмент выбирается исходя из квалификации команды и предсказуемости поддержки/документирации/стабильности этого инструмента.
Вот когда портнут KDE на U++ — тогда можно будет сравнивать его с Qt. Пока же это бессмысленно.
_>Главная задача программиста это не использование самой свежей студии, на самом топовом железе, и не создание приложений с самыи свежими api которые приводят к не совместимости с предыдущими системами на которых сидят основные массы. Главная задача выполнить поставленную задачу при фиксированном наборе ограничений.
Вот именно. И в данном случае U++ — это ограничение. Qt прекрасно работает на многих embeded девайсах. А если уж совсем задр*****ть заморачиваться насчёт производительности, то откройте для себя boot-to-qt. Который стал возможен именно благодаря хорошо продуманной архитектуре Qt. А именно — чётких абстракций над различными платформами и железом. U++ до этого — как до луны.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, _hum_, Вы писали:
__>>не, вы снова забываете про мой иллюстративный пример (Image: 2b87ad284cf2.png ), в котором важно знать границы таблицы, а для этого надо знать, на каком именно родителе рисуется ячейка (ведь именно он задает систему координат для ее отрисовки и определяет границы области видимости)
SaZ>Я всё помню. Посвторюсь: если нужна эта инфа, то сохраняйте её в поле своего делегата.
вы, видимо, не следите за контекстом беседы в данном случае речь шла о вашем утверждении:
информации о том, что parent является QWidget, достаточно для отрисовки эдитора
я привел контраргумент, показывающий, что это не так, и что по этой причине приходится дополнительно запоминать информацию о классе преставления таблицы (что, как мне видится, не есть гуд)
Здравствуйте, DreamMaker, Вы писали:
МД>>После MFC + WinAPI, Qt просто мозг ломает капитально! Как изучать?
DM>надо просто C# изучить. и удовольствие получите, и работать приятнее будет и о членовредительских by design языках только в кошмарных снах вспоминать будете
Не понял сарказм про C#. Не могли бы объяснить подробнее?
