Здравствуйте, monah_tuk, Вы писали:
_>Можете запостить фикс на документацию в геррит — пройдёт очень быстро. Через багтрекер — существенно медленнее (по понятным причинам). Уверяю, на эти действия времени уходит меньше, чем читать этот форум, а тем более — писать. А так да, в Qt есть косяки не только в документации. Но они фиксятся, плюс можно самому фиксить, а потом гордо наблюдать в логах гита своё имя
Какой фикс? Фикс с объяснениями того, что такое parent widget в хелпе про делегаты? Зачем? Что вы все курите?
Здравствуйте, monah_tuk, Вы писали:
_>Здравствуйте, _hum_, Вы писали:
__>>Здравствуйте, SaZ, Вы писали:
SaZ>>>Здравствуйте, _hum_, Вы писали:
__>>SaZ, вот вы опять выдумываете то, чего не было. Я не говорил, что Qt плох, я говорил, что документация к нему намного хуже MSDN-кой (той, что к MFC).
_>Можете запостить фикс на документацию в геррит — пройдёт очень быстро. Через багтрекер — существенно медленнее (по понятным причинам). Уверяю, на эти действия времени уходит меньше, чем читать этот форум, а тем более — писать. А так да, в Qt есть косяки не только в документации. Но они фиксятся, плюс можно самому фиксить, а потом гордо наблюдать в логах гита своё имя
извиняюсь, а что такое "геррит"? и "фикс", я так понимаю, это исправления, а у меня только замечание (я знаю, "как не должно быть", а не "как нужно сделать" )
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, monah_tuk, Вы писали:
_>>Можете запостить фикс на документацию в геррит — пройдёт очень быстро. Через багтрекер — существенно медленнее (по понятным причинам). Уверяю, на эти действия времени уходит меньше, чем читать этот форум, а тем более — писать. А так да, в Qt есть косяки не только в документации. Но они фиксятся, плюс можно самому фиксить, а потом гордо наблюдать в логах гита своё имя
SaZ>Какой фикс? Фикс с объяснениями того, что такое parent widget в хелпе про делегаты? Зачем? Что вы все курите?
я удивляюсь, как вам удается сочетать работу программистом и невозможность видеть за сказанным не набор слов, а смысл.
еще раз. в документации написано примерно следующее:
функция QLog10(float x, float err)
Возвращает значение десятичного логарифма. Параметр err используются для того, чтобы контролировать точность вычисления.
_hum_: почему не написано, чем конкретно является err (как именно он используется для "контроля вычисления" — он что, является абсолютной ошибкой вычисления?); SaZ: это же очевидно, err является вещественным числом! _hum_: это понятно, что числом. каким именно (например, абсолютной или относительной ошибкой вычисления)? SaZ: читайте мануал по типу float — там все написано.
monah_tuk :_hum_, можно сообщить об этом моменте на "геррит" SaZ: monah_tuk, какое сообщить?! зачем в этой функции объяснять, что значит вещественное число? что вы там курите?
Здравствуйте, _hum_, Вы писали:
__>извиняюсь, а что такое "геррит"? и "фикс", я так понимаю, это исправления, а у меня только замечание (я знаю, "как не должно быть", а не "как нужно сделать" )
Что такое геррит — гуглится, кратко — система для code review. Фикс — исправление. Если вы знаете только "как не должно быть", но не знаете, "как нужно делать", то ваши знания ошибочны. Потому что "как нужно делать" вполне себе может оказаться текущим вариантом.
Пример с логарифмом приводить не стоит, он высосан из пальца. Реальный пример с делегатом — куда нагляднее. Вам передали QWidget *parent, его нужно использовать в качестве родителя для вашего редактора. Всё! Для реализации вашего эдитора этого достаточно.
Если же вам хочется узнать, что именно скрывается за этим парентом, то вам нужно взять этот парент и уже работать с ним. Это другой контекст, он не относится к методу createEditor. Он относится именно к классу QWidget : public QObject. Которые так же хорошо документированы.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, monah_tuk, Вы писали:
_>>Можете запостить фикс на документацию в геррит — пройдёт очень быстро. Через багтрекер — существенно медленнее (по понятным причинам). Уверяю, на эти действия времени уходит меньше, чем читать этот форум, а тем более — писать. А так да, в Qt есть косяки не только в документации. Но они фиксятся, плюс можно самому фиксить, а потом гордо наблюдать в логах гита своё имя
SaZ>Какой фикс? Фикс с объяснениями того, что такое parent widget в хелпе про делегаты? Зачем? Что вы все курите?
Честно, ничего не курю. Я предложил следующее: что-то не нравится, есть возможность сделать "как надо" и отправить. Если твоё понимание "как надо" соответствует здравому смыслу, стандартам документации — примут и спасибо скажут. Я не утверждал, что нужно править именно этот кусок — мне там всё понятно, т.к. действую подобными твоим методам
Здравствуйте, _hum_, Вы писали:
_>>Можете запостить фикс на документацию в геррит — пройдёт очень быстро. Через багтрекер — существенно медленнее (по понятным причинам). Уверяю, на эти действия времени уходит меньше, чем читать этот форум, а тем более — писать. А так да, в Qt есть косяки не только в документации. Но они фиксятся, плюс можно самому фиксить, а потом гордо наблюдать в логах гита своё имя
__>извиняюсь, а что такое "геррит"?
https://codereview.qt-project.org/
__>и "фикс", я так понимаю, это исправления, а у меня только замечание (я знаю, "как не должно быть", а не "как нужно сделать" )
Сделайте "как нужно" — это и будет "фиксом" документации и отправьте на ревью (или "на инспекцию" — как приятнее на слух).
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, _hum_, Вы писали:
SaZ>Если вы знаете только "как не должно быть", но не знаете, "как нужно делать", то ваши знания ошибочны. Потому что "как нужно делать" вполне себе может оказаться текущим вариантом.
то есть, если я знаю, что здание не должно строиться без фундамента, но не знаю, каким именно этот фундамент должен быть, то, по-вашему, мои знания ошибочны? мды... очередной раз удивляюсь вашей логике...
SaZ>Пример с логарифмом приводить не стоит, он высосан из пальца. Реальный пример с делегатом — куда нагляднее. Вам передали QWidget *parent, его нужно использовать в качестве родителя для вашего редактора. Всё! Для реализации вашего эдитора этого достаточно.
это пример рецептурного подхода — возьми это что-то и отдай туда-то, как показано в примерах. шаг влево-шаг вправо — undefined behavior. а я ратую за системность — программисту должны даваться средства с пояснением их функций, а уж он сам решит, как их применять при построении программы.
и я уже выше говорил — нет, мне недостаточно этих данных, потому что я хочу размещать редактор своего делегата сам (в произвольном нужном мне месте таблицы), соответственно, должен знать, где располагается этот parent относительно изображения таблицы (дабы понять, где начало координат). а это, в свою очередь, зависит от того, кем является parent — если основным полем таблицы — одно, если фреймом — другое, если виджетом строки — третье, и т.п.
SaZ>Если же вам хочется узнать, что именно скрывается за этим парентом, то вам нужно взять этот парент и уже работать с ним. Это другой контекст, он не относится к методу createEditor. Он относится именно к классу QWidget : public QObject. Которые так же хорошо документированы.
а можно показать пример того, о чем вы говорите — можете найти в документации информацию о том, кем является этот парент (дабы ответить на вопрос, где расположено начало координат отрисовки эдитора относительно поля таблицы)?
__>SaZ, вот вы опять выдумываете то, чего не было. Я не говорил, что Qt плох, я говорил, что документация к нему намного хуже MSDN-кой (той, что к MFC). __>Еще раз, вот нужно мне узнать, что из себя в функции QItemDelegate::createEditor представляет параметр parent (например, меня интерeсует, является ли он указателем на QTableView или какие-то его подклассы и проч.). В нормальной доке либо напрямую написали бы, либо дали ссылки на эту инфу. В Qt-шной ничего подобного нет (приводить в данном случае ссылку на описание класса QWidget — это то же самое, что в документации к функции log(float x, float y) приводить ссылку на описание типа float)?
Документация в данном случае приводит предельно простое и исчерпывающее: нужно указать родительское окно — ни больше, ни меньше. Кого назначишь parent'ом, тот им и будет. Тут надо понимать, что Qt поддерживает иерархическую модель, когда родитель заботится об удалении своих child-объектов. Кроме того, для виджетов чайлд-объекты будут лежать в области окна родителя (edit-box, например). Вот инфа:
QObject::QObject ( QObject * parent = 0 )
Constructs an object with parent object parent.
The parent of an object may be viewed as the object's owner. For instance, a dialog box is the parent of the OK and Cancel buttons it contains.
The destructor of a parent object destroys all child objects.
Setting parent to 0 constructs an object with no parent. If the object is a widget, it will become a top-level window.
Constructs a widget which is a child of parent, with widget flags set to f.
If parent is 0, the new widget becomes a window. If parent is another widget, this widget becomes a child window inside parent. The new widget is deleted when its parent is deleted.
The widget flags argument, f, is normally 0, but it can be set to customize the frame of a window (i.e. parent must be 0). To customize the frame, use a value composed from the bitwise OR of any of the window flags.
If you add a child widget to an already visible widget you must explicitly show the child to make it visible.
Note that the X11 version of Qt may not be able to deliver all combinations of style flags on all systems. This is because on X11, Qt can only ask the window manager, and the window manager can override the application's settings. On Windows, Qt can set whatever flags you want.
В целом соглашусь с SaZ — в Qt отличная исчерпывающая документация с удобной навигацией. Причем, она содержит не только описание классов и модулей, но и описание концепций Qt (например, Signals & Slots, The Event System). Можно обойтись только ей — ни гугл, ни Stackoverflow не нужны. Причем это верно как для офлайн Qt Assistant, так и для онлайн документации.
Я начал с книги с веселой обложкой Жасмин Бланшет, Марк Саммерфилд. Qt 4: программирование GUI на C++. Взял оттуда в основные концепции библиотеки. Дальше начал сам использовать Qt на практике. После WinAPI было очень просто, боли при переходе не испытывал. Въехал быстро, потому что все логично, просто и понятно. При этом написание GUI занимает гораздо меньше времени, нежели с использованием WinAPI. После Qt использование WinAPI вызывает боль и печаль.
Здравствуйте, DiPaolo, Вы писали:
__>>SaZ, вот вы опять выдумываете то, чего не было. Я не говорил, что Qt плох, я говорил, что документация к нему намного хуже MSDN-кой (той, что к MFC). __>>Еще раз, вот нужно мне узнать, что из себя в функции QItemDelegate::createEditor представляет параметр parent (например, меня интерeсует, является ли он указателем на QTableView или какие-то его подклассы и проч.). В нормальной доке либо напрямую написали бы, либо дали ссылки на эту инфу. В Qt-шной ничего подобного нет (приводить в данном случае ссылку на описание класса QWidget — это то же самое, что в документации к функции log(float x, float y) приводить ссылку на описание типа float)?
DP>Документация в данном случае приводит предельно простое и исчерпывающее: нужно указать родительское окно — ни больше, ни меньше. Кого назначишь parent'ом, тот им и будет.
Reimplemented from QAbstractItemDelegate::createEditor().
Returns the widget used to edit the item specified by index for editing. The parent widget and style option are used to control how the editor widget appears.
подчеркнутое переводится как "родительский виджет и стайл-опции используются для контроля того, как виджет эдитора будет показываться". то есть, говорится о непосредственном влиянии этого параметра на графическое представление (а не только на банальное владение по иерархии).
и да, в банальных примерах со стандартными едиторами это не принципиально, а вот когда нужно что-то специфическое, например, организовать кнопку рядом с эдитором, да так, чтобы она не вылазила за пределы таблицы, вот тогда и видишь, что информации о родителе не хватает, так как в зависимости о того, кто он, будет разный расчет позиционирования этой самой кнопки.
иными словами, данный момент в документации с Qt показывает, что она может сбивать с толку — вместо того, чтобы отчетливо написать что-то типа "parent — владелец едитора, стайл опции — опции ячейки таблицы, для которой создается эдитор.", имеем, что имеем.
__>Returns the widget used to edit the item specified by index for editing. The parent widget and style option are used to control how the editor widget appears. __>[/q]
__>подчеркнутое переводится как "родительский виджет и стайл-опции используются для контроля того, как виджет эдитора будет показываться".
По мне, так все понятно. В зависимости от родительского виджета у тебя едитор и будет появляться в определенном месте и быть дочерним элементом того или иного виджета (или же вообще не иметь родителя, если передать 0).
Здравствуйте, DiPaolo, Вы писали:
__>>Returns the widget used to edit the item specified by index for editing. The parent widget and style option are used to control how the editor widget appears. __>>[/q]
__>>подчеркнутое переводится как "родительский виджет и стайл-опции используются для контроля того, как виджет эдитора будет показываться".
DP> По мне, так все понятно. В зависимости от родительского виджета у тебя едитор и будет появляться в определенном месте и быть дочерним элементом того или иного виджета (или же вообще не иметь родителя, если передать 0).
"что-то где-то как-то будет появляться". и это вы считаете информацией? в каком именно месте, и что делать, если я хочу это место изменить?
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Здравствуйте, koenjihyakkei, Вы писали:
K>>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>>После MFC + WinAPI, Qt просто мозг ломает капитально! Как изучать?
K>>Qt assistant + Google Driven Development(что непонятно смотришь в гугле, ответы есть на все вопросы). К тому же Qt на мой взгляд один из самых легких в освоении фреймворков.
МД>Да дело в том, что даже те же самые примеры они всё время какие то незаконченные. Или очень очень простые.
МД>Казалось бы, ну простой бы тривиальный пример привести для Qt + QML: при нажатии кнопки открывается окно, или какое то более сложное действие. Но я везде вижу из разряда чтото типа:
МД>onClick: root.index++
МД>Всё!!! Как будто других действий на нажатие кнопки придумать нельзя! Обалдеть примеры!
После прочтения всей нити треда сложилось впечатление, что вы не совсем понимаете то, что именно вы хотите сделать.
Зачем вам вообще нужен QtQuick/QML? Поясните пожалуйста этот момент. На мой взгляд эта технология ещё в статусе "proof-of-concept"; хотя Qt-разработчики, конечно, пытаются сделать из QtQuick/QML достаточно удобное и стабильное решение по созданию графических приложений и перетянуть на него пользователей фреймворка. Однако, как показывает практика, QtQuick/QML не слишком-то пришёлся по вкусу многим разработчикам. Вот в теме был перечислен список популярных программ, использующих старые проверенные временем Qt Widgets. Добавлю к этому списку ещё одно серьёзное приложение: IDA Pro. А теперь, можете ли вы представить себе интерфейс IDA Pro на
QtQuick/QML? Лично я не могу. Много ли вы знаете популярных программ, которые используют QtQuick/QML? Это во-первых. А во-вторых, опять же, по моему мнению, эта технология больше подходит для реализации мобильных приложений или анимированных kiosk-приложений, чем десктопных программ.
Поэтому, если вам требуется создать десктопное приложение с парой кнопочек, диалогами да полем ввода -- Qt Widgets ваш выбор. Вы избавляетесь от JavaScript-интерпретатора. Избавляетесь от десятков мегабайт библиотек, так как QtQuick/QML работает через OpenGL 2/OpenGL|ES 2, а поскольку реализация этих технологий в MS Windows оставляет желать лучшего, такую программу требуется снабдить специальными костылями от Qt-разработчиков: либо ANGLE, который будет транслировать OpenGL|ES в DirectX, либо LLVM openglsw32.dll, который будет заниматься программным рендерингом. Только таким образом будет достигнута корректная работа QtQuick/QML-приложения на какой-нибудь старой офисной машинке с давно устаревшей видеокарточкой. Всё это же, конечно, выливается в огромный размер дистрибутива программы, за 50МБ даже для простейшей кнопки или HelloWorld'а.
В почтовой рассылке Qt-разработчики часто советуют пользователям Qt использовать для построения десктопных приложений именно Qt Widgets.
В общем, обозначьте цели того, что именно вы хотите сделать. Qt слишком большой фреймворк, чтобы быстро его освоить. Поэтому, когда вы заявляете:
МД>После MFC + WinAPI, Qt просто мозг ломает капитально! Как изучать?
Уточняйте пожалуйста, какая именно часть этого фреймворка сломала капитально вам мозг. Потому что Qt это сеть, базы данных, работа с железом (Serial Port), кросс-платформенные обёртки над файлами и потоками, Bluetooth/GPS, работа с аудио/видео/камерами, целых две разных идеологии построения интерфейсов (Qt Widgets vs. Qt Quick) и ещё куча всякой всячины.
Кстати, в треде было заявляление, что нет литературы на русском. Тут: https://toster.ru/q/91237 я собрал небольшой списочек книжек, из которого посоветую вам первую книгу. В ней, прямо в первых главах рассмотрено создание простенького табличного процессора, на примере которого вы сразу поймёте, как строить подобные интерфейсы. Обязательно ознакомьтесь с этой книгой от создателей Qt. А вот Макс Шлее несколько обзорный, и лучше всего использовать его книгу как справочник.
По Qt Quick, дейстительно, информации в русскоязычном интернете катастрофически мало, но я посоветую вам прочитать такую замечательную книжку на английском: http://qmlbook.github.io/.
Ну и конечно же не забывайте читать документацию и просматривать примеры, идущие в комплекте с Qt. Документация у Qt одна из лучших. Необходимость использования литературы просто отпадает.
Здравствуйте, EXL, Вы писали:
EXL>Зачем вам вообще нужен QtQuick/QML? Поясните пожалуйста этот момент. На мой взгляд эта технология ещё в статусе "proof-of-concept";
Ну, этой технологии уже лет 6 или 7, поэтому "proof-of-concept" она перешагнула. EXL>Поэтому, если вам требуется создать десктопное приложение с парой кнопочек, диалогами да полем ввода -- Qt Widgets ваш выбор. Вы избавляетесь от JavaScript-интерпретатора. Избавляетесь от десятков мегабайт библиотек, так как QtQuick/QML работает через OpenGL 2/OpenGL|ES 2, а поскольку реализация этих технологий в MS Windows оставляет желать лучшего, такую программу требуется снабдить специальными костылями от Qt-разработчиков: либо ANGLE, который будет транслировать OpenGL|ES в DirectX, либо LLVM openglsw32.dll, который будет заниматься программным рендерингом. Только таким образом будет достигнута корректная работа QtQuick/QML-приложения на какой-нибудь старой офисной машинке с давно устаревшей видеокарточкой. Всё это же, конечно, выливается в огромный размер дистрибутива программы, за 50МБ даже для простейшей кнопки или HelloWorld'а.
После выходя 5.5 это почти все неактуально. QML приложения теперь нормально отображаются через RDP
Windows packages are all built with -opengl dynamic. No OpenGL-only or ANGLE-only builds are provided anymore.
Здравствуйте, Igore, Вы писали:
EXL>>Зачем вам вообще нужен QtQuick/QML? Поясните пожалуйста этот момент. На мой взгляд эта технология ещё в статусе "proof-of-concept"; I>Ну, этой технологии уже лет 6 или 7, поэтому "proof-of-concept" она перешагнула.
Был на конфе в Берлине в октябре 2014, в курилке узнал много интересного про QML. Начинали его делать ещё в Нокии, чтобы можно было низкоквалифицированными кадрами быстро клепать приложения с анимированными интерфейсами для постоянно штампующихся мобилок. Нокия никогда не блистала поддержкой своего софта, поэтому изначально в QtQuick/QML не были заложены возможности нормальной отладки.
Хотя качество QtQuick/QML уже на достаточно высоком уровне, но есть ряд фундаментальных проблем. Первая и главная — отсутствие полноценной поддержки со стороны различных IDE (кроме QtCreator'а). Вторая — трудоёмкое профилирование кода. Когда C++ бэкэнд пересекается с QML фронтендом — очень сложно понять, где именно и что просаживает производительность. Ребята из Qt стараются вылизвать свой профилировщик, но пока это ещё не уровень, пригодный для бизнес-проектов. Третья — на QML легко говнокодить. Т.е. понижая вводную планку для GUI-шников, нужно сильно повышать качество архитектуры. Написать что-то годное и поддерживаемое на QML очень тяжело/трудозатратно.
I>После выходя 5.5 это почти все неактуально. QML приложения теперь нормально отображаются через RDP I>
I>Windows packages are all built with -opengl dynamic. No OpenGL-only or ANGLE-only builds are provided anymore.
Вы сами RDP проверяли или это лишь догадка? Главная фича 5.5 в том, что они забыли положить .pdb-шники графический бэкэнд теперь линкуется динамически и можно в рантайме, при инициализации приложения, выбрать, какой именно загружать.
Здравствуйте, Igore, Вы писали:
I>Здравствуйте, EXL, Вы писали:
EXL>>Зачем вам вообще нужен QtQuick/QML? Поясните пожалуйста этот момент. На мой взгляд эта технология ещё в статусе "proof-of-concept"; I>Ну, этой технологии уже лет 6 или 7, поэтому "proof-of-concept" она перешагнула.
Да, я знаю это. Однако, с ней были постоянно какие-то сложности и перетряхивания. Сначала, во времена когда Qt был собственностью Nokia, в Qt 4 был реализован Qt Quick 1, который мог использовать нативный метод рендеринга (и работал он очень-очень шустро, поскольку предполагалось его использование в мобильных телефонах). Потом, с релизом Qt 5, появился Qt Quick 2, который работал только через OpenGL(|ES) 2, при этом совместимость с Qt Quick 1 была сломана и разработчикам приложений на этой технологии пришлось поправлять их под новые стандарты. Далее, уже в Qt 5/Qt Quick 2 снова появились какие-то проблемы и несовместимости. Точно помню ситуацию, когда разработчики плакались в блогах (по-моему на хабре), сетуя на то, что их Qt Quick-приложения, которые использовали Qt 5.1 (или Qt 5.2, уже не помню), перестали корректно работать и даже собираться в Qt 5.3.
Я клоню к тому, что хоть технологии и достаточно много лет, понятие инструмента для серьёзной разработки она, на мой взгляд, так и не перешагнула.
Кто-нибудь может назвать популярные десктопные или мобильные приложения на Qt Quick под основные (iOS/Android/Windows/OS X/Linux) платформы? Я вот таких и не знаю даже. Отмечу лишь игру от Google Labs — VoltAir, да QML Creator от независимого разработчика. Но всё это несколько не то. Google Labs, помнится, тоже не в восторге от Qt Quick были.
Знаю лишь одно действительно популярное мобильное приложение, использующее Qt под Android — это 2GIS. Оно, кстати, отечественное, что не может не радовать. Всем рекомендую его попробовать. Но они вроде как не используют Qt Quick/QML, да и вообще у них не ванильный Qt, а его отдельный форк, который компания самостоятельно поддерживает; следовательно под пример это приложение не подходит.
Кроме того существует отдельный мир, где Qt Quick/QML активно используется. Это различные, малопопулярные мобильные OS, где он по сути основа всего интерфейса. Их множество: MeeGo, Ubuntu Mobile, Sailfish OS, BlackBerry OS и др. Однако, там тоже не ванильный Qt Quick, а обильно приправленный специальными OS-зависимыми компонентами.
Так что буду рад, если кто покажет интересные приложения на том Qt Quick, который сейчас разрабатывает и продвигает дочерняя компания Digia — The Qt Company.
EXL>>Поэтому, если вам требуется создать десктопное приложение с парой кнопочек, диалогами да полем ввода -- Qt Widgets ваш выбор. Вы избавляетесь от JavaScript-интерпретатора. Избавляетесь от десятков мегабайт библиотек, так как QtQuick/QML работает через OpenGL 2/OpenGL|ES 2, а поскольку реализация этих технологий в MS Windows оставляет желать лучшего, такую программу требуется снабдить специальными костылями от Qt-разработчиков: либо ANGLE, который будет транслировать OpenGL|ES в DirectX, либо LLVM openglsw32.dll, который будет заниматься программным рендерингом. Только таким образом будет достигнута корректная работа QtQuick/QML-приложения на какой-нибудь старой офисной машинке с давно устаревшей видеокарточкой. Всё это же, конечно, выливается в огромный размер дистрибутива программы, за 50МБ даже для простейшей кнопки или HelloWorld'а. I>После выходя 5.5 это почти все неактуально. QML приложения теперь нормально отображаются через RDP I>
I>Windows packages are all built with -opengl dynamic. No OpenGL-only or ANGLE-only builds are provided anymore.
Интересно, спасибо. Дело движется, что не может не радовать!
Но всё равно, разве из этого следует, что приложения "отвяжутся" от ANGLE или opengl32sw.dll на слабых конфигурациях? Как я понимаю, с -opengl dynamic алгоритм выбора метода рендеринга при запуске приложения будет следующий: Try opengl32 and check if OpenGL 2.0 functions are available.
If this fails, try ANGLE.
If initialization fails either due to missing ANGLE libraries or some other reason, try opengl32sw.dll. In practice this will be a software rasterizer based implementation. To make it easy to get started, a pre-built version of Mesa llvmpipe is bundled with the binary packages of Qt 5.4.
А потому библиотеки всё-таки придётся "докинуть". Вот если бы оно во втором пункте начало рендерить в GDI, как в Qt Quick 1, это было бы идеологически правильный путь для MS Windows.
А ещё тут прочитал, что в официальных сборках Qt 5.5 под Windows наконец-то библиотека QtCore стала свободна от зависимости жирнейших ICU-библиотек (~30MB).
Оказывается, это у них баг на билд-ферме был с момента выпуска Qt 5.0.0 и тянулся вплоть до момента выпуска Qt 5.5.0. Вот ведь как бывает. https://bugreports.qt.io/browse/QTBUG-38259
Здравствуйте, Мёртвый Даун, Вы писали:
МД>После MFC + WinAPI, Qt просто мозг ломает капитально! Как изучать?
надо просто C# изучить. и удовольствие получите, и работать приятнее будет и о членовредительских by design языках только в кошмарных снах вспоминать будете
Здравствуйте, SaZ, Вы писали:
I>>Т.е. понижая вводную планку для GUI-шников, нужно сильно повышать качество архитектуры. Написать что-то годное и поддерживаемое на QML очень тяжело/трудозатратно.
Ну, тут уже сразу есть 2 слоя, чисто ui где могут говнокодить, и логика. Всё ui можно написать без единой строчки С++, а потом уже прикручивать к ней логику.
I>>После выходя 5.5 это почти все неактуально. QML приложения теперь нормально отображаются через RDP SaZ>Вы сами RDP проверяли или это лишь догадка?
Да, проверяли, поэтому новый проект решили начинать на QML, так же была решена проблема со squish-ом, он тоже прикручивается к QML. SaZ>Главная фича 5.5 в том, что они забыли положить .pdb-шники графический бэкэнд теперь линкуется динамически и можно в рантайме, при инициализации приложения, выбрать, какой именно загружать.
У нас своя сборка , незаметили, для меня "главная фича" этот баг https://bugreports.qt.io/browse/QTBUG-47614 , ждем 5.5.1.
По мне, так все понятно. В зависимости от родительского виджета у тебя едитор и будет появляться в определенном месте и быть дочерним элементом того или иного виджета (или же вообще не иметь родителя, если передать 0).
https://bugreports.qt.io/browse/QTBUG-47614 , ждем 5.5.1.
