Re[15]: Кто как изучал Qt? - Qt

Здравствуйте, EXL, Вы писали:

EXL>Так что буду рад, если кто покажет интересные приложения на том Qt Quick, который сейчас разрабатывает и продвигает дочерняя компания Digia — The Qt Company.
Таких не знаю, знаю что раньше было написано на QML, используют ли сейчас эти программы Qt и какой версии я

: один из интерфейс-ов cyberplat-a(платежные терминалы) в евросети вроде он есть, и в Свяной(enter) внутри компьютер с сенсорным экраном, можно полистать каталог выбрать продукцию, так же интерфейс Касперского.

Интересно кстати на чем написан интерфейс для больших киосков в макдональдсе.

EXL>Интересно, спасибо. Дело движется, что не может не радовать!
EXL>Но всё равно, разве из этого следует, что приложения "отвяжутся" от ANGLE или opengl32sw.dll на слабых конфигурациях? Как я понимаю, с -opengl dynamic алгоритм выбора метода рендеринга при запуске приложения будет следующий:
EXL>

EXL>Try opengl32 and check if OpenGL 2.0 functions are available.

EXL>If this fails, try ANGLE.

EXL>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.

EXL>

Скорей всего так и есть, для меня главное что теперь нет 2х отдельных сборок.

EXL>А потому библиотеки всё-таки придётся "докинуть". Вот если бы оно во втором пункте начало рендерить в GDI, как в Qt Quick 1, это было бы идеологически правильный путь для MS Windows.
Для Windows вроде и так идеологически верно angle который проксирует вызовы в DirectX.

Здравствуйте, EXL, Вы писали:

EXL>Кто-нибудь может назвать популярные десктопные или мобильные приложения на Qt Quick под основные (iOS/Android/Windows/OS X/Linux) платформы? Я вот таких и не знаю даже. Отмечу лишь игру от Google Labs — VoltAir, да QML Creator от независимого разработчика. Но всё это несколько не то. Google Labs, помнится, тоже не в восторге от Qt Quick были.

Я вот как раз начал писать один узкопрофильный аудиоплеер. Известным я, конечно, не стану, но в узких кругах штука очень востребована. Вот пока не могу определиться между виджетами, которые достаточно неплохо знаю и QML, в котором я пока полный ноль. С одной стороны, хочется "конфетку" с анимированными интерфейсами, а с другой не хочется тратить лишнее время на потенциальные косяки с QML. Склоняюсь к варианту двухпроцессного приложения, где гуи будет в одном потоке (со вставками QQuickWidget), а аудио бэкэнд в другом.

EXL>Знаю лишь одно действительно популярное мобильное приложение, использующее Qt под Android — это 2GIS. Оно, кстати, отечественное, что не может не радовать. Всем рекомендую его попробовать. Но они вроде как не используют Qt Quick/QML, да и вообще у них не ванильный Qt, а его отдельный форк, который компания самостоятельно поддерживает; следовательно под пример это приложение не подходит.

На вышеупомянутой конфе, чел из vikingsoft рассказывал, что ему уже достаточно часто попадаются десктопные энтерпрайз приложения. Конкретного ничего не назову, поэтому оснований мне верить особых нет

. Ещё знаю, что такой аутсорсер как luxoft активно ищет C++/QML программистов (всё лето активно звали к ним работать). Как я понимаю — делать фреймворк под всякие телевизоры/прочие девайсы для разработки встраиваемых интерактивных систем.

EXL>Интересно, спасибо. Дело движется, что не может не радовать!
EXL>Но всё равно, разве из этого следует, что приложения "отвяжутся" от ANGLE или opengl32sw.dll на слабых конфигурациях? Как я понимаю, с -opengl dynamic алгоритм выбора метода рендеринга при запуске приложения будет следующий:

Там, вроде, есть возможность софтварно рендерить всё это дело через какой-то кутэшный рендерер. Говорят, что работать будет всё, кроме шейдеров. Тыц.

Здравствуйте, _hum_, Вы писали:

__>"что-то где-то как-то будет появляться". и это вы считаете информацией? в каком именно месте, и что делать, если я хочу это место изменить?

Приведите конкретный пример, где вам нужно знать реальный тип QWidget *parent. А то вы всё говорите, что что-то хотите сделать. А что сделать — не ясно. Повторюсь, что в соответствии с документацией это может быть абсолютно любой виджет. Ваша задача, как разработчика делегата, разместить свой виджет поверх парента. В качестве подсказки вам вторым аргументом передали координаты ячейки, для которой запускается редактирование. У вашего же виджета есть волшебные методы move и resize. Координаты есть, парент есть — вперёд.

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, Мёртвый Даун, Вы писали:

МД>>После MFC + WinAPI, Qt просто мозг ломает капитально! Как изучать?

_>Лучше взгляни на это

Шило ещё то. Совершенно не юзабельное. Уже обсуждалось и на rsdn, и на хабре. Хотя, для программ, типа лабораторных в универе — самое то.

Здравствуйте, SaZ, Вы писали:

SaZ>Здравствуйте, kov_serg, Вы писали:

_>>Здравствуйте, Мёртвый Даун, Вы писали:

МД>>>После MFC + WinAPI, Qt просто мозг ломает капитально! Как изучать?

_>>Лучше взгляни на это

SaZ>Шило ещё то. Совершенно не юзабельное. Уже обсуждалось и на rsdn, и на хабре. Хотя, для программ, типа лабораторных в универе — самое то.
Вы сэр просто готовить не умеете.

Здравствуйте, kov_serg, Вы писали:

_>Вы сэр просто готовить не умеете.

Скорее, не вижу смысла. Хороший фрэймворк, особенно для гуи — это не только код, а ещё и инструменты + документация. В U++ возможности разработки кастомных контролов сводятся к велосипедостроению. Холиварить не буду, можете поискать темы на хабре/рсдн — там в комментариях более подробно расписаны недостатки.

Здравствуйте, SaZ, Вы писали:

SaZ>Здравствуйте, kov_serg, Вы писали:

_>>Вы сэр просто готовить не умеете.

SaZ>Скорее, не вижу смысла. Хороший фрэймворк, особенно для гуи — это не только код, а ещё и инструменты + документация. В U++ возможности разработки кастомных контролов сводятся к велосипедостроению. Холиварить не буду, можете поискать темы на хабре/рсдн — там в комментариях более подробно расписаны недостатки.

Что интнресно в U++ есть и инструменты и система документирования. Можете создать свой кастомный контрол и документацию и опубликовать в bazzar. При добавлении в проект подтянется ваш контрол и справка по нему.

Довольно давно пользуюсь этим фрейморком. Нареканий особых нет. По поводу велосипедо строения это вы зря. Очень просто делаются любые компоненты. Более всё очень просто раскладывается по независимым модулям (packages). Вообще не понимаю что вы имеете ввиду под разработкой кастомных контролов. В любом фреймворке это сводися к велосипедо строению или к использованию готовых.
Главный недостаток под winxp надо вручную скопировать dbghelp.dll от VisualStudio в директорию к Upp. Иначе IDE использует штатный dbghelp.dll из windows (старую как гавно мамонта) и отладки вам не видать.

>подробно расписаны недостатки
http://habrahabr.ru/post/194590/ ?
Недостатки есть у всех. Дайте ссылки на фатальные недостатки.

Вот например у всеми любиого C# досих пор

using(var res=CreateSomeResource()) { 
  ...
}

Эта незатейливая конструкция не является потоко безопасной. Т.е. ресурс может быть выделен, а Dispose никто вызывать не будет.

ps: Настоящий физик может писать Фортраном на любом языке.

Здравствуйте, SaZ, Вы писали:

SaZ>Здравствуйте, _hum_, Вы писали:

__>>"что-то где-то как-то будет появляться". и это вы считаете информацией? в каком именно месте, и что делать, если я хочу это место изменить?

SaZ>Приведите конкретный пример, где вам нужно знать реальный тип QWidget *parent. А то вы всё говорите, что что-то хотите сделать. А что сделать — не ясно.

например, организовать эдитор, у которого бы был элемент, выходящий за пределы поля ячейки, но при этом не выходящий за пределы границы таблицы (то есть, его геометрия зависела бы от того, в каком положении относительно границ таблицы располагается ячейка). как вариант:

SaZ>Повторюсь, что в соответствии с документацией это может быть абсолютно любой виджет. Ваша задача, как разработчика делегата, разместить свой виджет поверх парента. В качестве подсказки вам вторым аргументом передали координаты ячейки, для которой запускается редактирование. У вашего же виджета есть волшебные методы move и resize. Координаты есть, парент есть — вперёд.

во-первых, там во втором аргументе QStyleOptionViewItem, в котором по документации непонятно какие координаты содержатся — по крайней мере, ничего, кроме

QStyleOptionViewItem
[...]
Inherits: QStyleOption
[...]
QRect QStyleOption::rect

This variable holds the area that should be used for various calculations and painting.

я не нашел (примеры не в счет).
а во-вторых, даже если есть координаты ячейки, все равно координаты границы неизвестны, а потому перемещение "не выходя за пределы границы таблицы" не представляется возможным выполнить без знания того, кто же родитель (ну или более общее — как связаны координаты родителя с координатами поля таблицы).

и на всякий случай подчеркну еще раз — я не против того, чтобы так и было (чтоб в createEditor не было возможности позиционирования виджета эдитора, потому как для этого, как я понял, задуман updateEditorGeometry), я лишь против того, чтобы документация писалась так коряво, когда человек, впервые ее читающий, сбивается с толку фразами "parent используется для настройки того, как будет отображаться эдитор", а на деле это далеко не так (и даже примечаний на этот счет нет).
изначально-то с этого и началось — я указал, что документация к qt, несмотря на ее объемность, намного хуже написана, чем тот же msdn, а не вел речь про целесообразность организации схемы создания эдитора делегата.

Здравствуйте, Мёртвый Даун, Вы писали:

МД>Ну как я и говорил выше: чтото можно хотя бы чуть более сложнее чем "onClick: console.log(item.text)"?????????????????????????? Другие действия бывают какие-то????????????????? Зачем такие примеры вообще пишут???????

МД>как при нажатии кнопки в первом окне открыть второе окно??? Что еще может быть тривиальней?! Решаю эту задачу уже почти целый день! Ну как так? Что это за язык и библиотека чтобы для такого действия потратить день? С другими языками и библиотеками таких проблем почему та не было...

Понимаю и сочувствую. У меня впечатление было такое же.

Здравствуйте, SaZ, Вы писали:

SaZ>Я вот как раз начал писать один узкопрофильный аудиоплеер. Известным я, конечно, не стану, но в узких кругах штука очень востребована. Вот пока не могу определиться между виджетами, которые достаточно неплохо знаю и QML, в котором я пока полный ноль. С одной стороны, хочется "конфетку" с анимированными интерфейсами, а с другой не хочется тратить лишнее время на потенциальные косяки с QML.

со sciter знаком? html5-варианты рассматривал? c# не подходит?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>со sciter знаком?

Нет. Но считаю это оверхедом. Мне проще QML/QtQuick изучить. Контролы будут кастомные — боюсь на html+js реализация будет значительно более трудоёмкой.

BZ>html5-варианты рассматривал?

Да. Но считаю это оверхедом. Вспоминаются времена работы в одной аутсорсной компании, где десктопный гуи был на html.

BZ>c# не подходит?

Нет. Нужна кросс-платформенность. Включая мобильные платформы. Ядро будет на C++/Qt. Не вижу вообще никаких преимуществ C# перед C++14/Qt.

З.Ы. поскольку проект в первую очередь делается для личных нужд (бизнес-план есть, но монетизация очень слабенькая для того, чтобы браться за него серьёзно), то я выбираю инструмент исходя в первую очередь из своих навыков, а не из того, что больше подходит для задачи. На плюсах я напишу значительно лучше и быстрее, чем на шарпе.

Здравствуйте, _hum_, Вы писали:

__>например, организовать эдитор, у которого бы был элемент, выходящий за пределы поля ячейки, но при этом не выходящий за пределы границы таблицы (то есть, его геометрия зависела бы от того, в каком положении относительно границ таблицы располагается ячейка). как вариант:

__>Image: 2b87ad284cf2.png

Я уже говорил — вы хотите нетривиальную функциональность. Создаёте эдитор в ячейке + создаёте сверху виджеты, которые вам нужны.

__>во-первых, там во втором аргументе QStyleOptionViewItem, в котором по документации непонятно какие координаты содержатся — по крайней мере, ничего, кроме

Координаты вашей ячейки. Потому что это user-friendly, если ваш виджет впишется в ячейку. В противном случае вьюхе, вероятно, придётся растягивать столбцы.

__> а во-вторых, даже если есть координаты ячейки, все равно координаты границы неизвестны, а потому перемещение "не выходя за пределы границы таблицы" не представляется возможным выполнить без знания того, кто же родитель (ну или более общее — как связаны координаты родителя с координатами поля таблицы).

У вьюхи есть метод, чтобы по индексу получить координаты. Зная индекс текущей ячейки можно получить индекс и геометрию соседней. А саму вьюху можно передать параметром, через композицию, в делегат. Это нормально, т.к. один экземпляр делегата не нужно вешать на разные вьюхи.

__>...человек, впервые ее читающий, сбивается с толку фразами "parent используется для настройки того, ~~как~~ будет отображаться эдитор"...

Где (а точнее, на чём), а не как.

__>изначально-то с этого и началось — я указал, что документация к qt, несмотря на ее объемность, намного хуже написана, чем тот же msdn, а не вел речь про целесообразность организации схемы создания эдитора делегата.

Я так думал про мсдн, когда писал на чистом винапи. Другие документации вообще не переваривал. Но потом начал развивать свои знания, понял, что есть много замечательных библиотек, часто плохо документированных. А потом пришло осознание
того, что я просто ленюсь вникать во что-то новое. Я в себе это поборол.

Здравствуйте, SaZ, Вы писали:

SaZ>Здравствуйте, _hum_, Вы писали:

__>>например, организовать эдитор, у которого бы был элемент, выходящий за пределы поля ячейки, но при этом не выходящий за пределы границы таблицы (то есть, его геометрия зависела бы от того, в каком положении относительно границ таблицы располагается ячейка). как вариант:

__>>Image: 2b87ad284cf2.png

SaZ>Я уже говорил — вы хотите нетривиальную функциональность.

а по мне, так вполне естественную (а потому тривиальную) для таблиц

SaZ>Создаёте эдитор в ячейке + создаёте сверху виджеты, которые вам нужны.

где, в createEditor (речь же шла о нем)?

__>>во-первых, там во втором аргументе QStyleOptionViewItem, в котором по документации непонятно какие координаты содержатся — по крайней мере, ничего, кроме

SaZ>Координаты вашей ячейки. Потому что это user-friendly, если ваш виджет впишется в ячейку. В противном случае вьюхе, вероятно, придётся растягивать столбцы.

опять же, откуда у вас такая информация — можно ссылку на доку, которую вы так хвалили за полноту, где бы это черным по белому было написано,

__>> а во-вторых, даже если есть координаты ячейки, все равно координаты границы неизвестны, а потому перемещение "не выходя за пределы границы таблицы" не представляется возможным выполнить без знания того, кто же родитель (ну или более общее — как связаны координаты родителя с координатами поля таблицы).

SaZ>У вьюхи есть метод, чтобы по индексу получить координаты. Зная индекс текущей ячейки можно получить индекс и геометрию соседней. А саму вьюху можно передать параметром, через композицию, в делегат. Это нормально, т.к. один экземпляр делегата не нужно вешать на разные вьюхи.

да, но это уже получается обходной путь с привлечением сторонней информации, тогда как, по логике, ее же можно было взять и из parent, если бы было известно, что им является QTableView (подчеркиваю, я не говорю, что именно так надо было бы делать разработчикам qt, я лишь обращаю внимание на то, что пространное описание в документации может наводить именно на эту мысль, и тем самым дезориентировать программиста [это все к вопросу о корявости докумнетации]).

__>>...человек, впервые ее читающий, сбивается с толку фразами "parent используется для настройки того, ~~как~~ будет отображаться эдитор"...

SaZ>Где (а точнее, на чём), а не как.

ну, смотрим первоисточник и убеждаемся, что именно "как", а не "где"

QWidget * QItemDelegate::createEditor(QWidget * parent, const QStyleOptionViewItem & option, const QModelIndex & index) const

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, несмотря на ее объемность, намного хуже написана, чем тот же msdn, а не вел речь про целесообразность организации схемы создания эдитора делегата.

SaZ>Я так думал про мсдн, когда писал на чистом винапи. Другие документации вообще не переваривал. Но потом начал развивать свои знания, понял, что есть много замечательных библиотек, часто плохо документированных. А потом пришло осознание
SaZ>того, что я просто ленюсь вникать во что-то новое. Я в себе это поборол.

неохота переходить на новое и неприятие документации — совершенно разные вещи. в мсдн соотношение полезная информация/объем текста намного выше, чем в qt. там все сразу навиду и по делу. например, в описании функции — в столбец перечисление входящих параметров, их назначений, далее, возвращаемое значение, далее, примечения, далее пример. все! а в qt надо шарить глазами, чтобы найти, что же данный аргумент означает, и очень часто это так и не удается сделать из-за того, что все ограничивается фразой типа той, что в createEditor.

если проводить аналогию, то такое ощущение, что msdn писали специалисты, а qt-доки — самоучки-любители, не имеющие представления о системности изложения информации.

Здравствуйте, _hum_, Вы писали:

__>ее же можно было взять и из parent, если бы было известно, что им является QTableView (подчеркиваю, я не говорю, что именно так надо было бы делать разработчикам qt, я лишь обращаю внимание на то, что пространное описание в документации может наводить именно на эту мысль, и тем самым дезориентировать программиста [это все к вопросу о корявости докумнетации]).

Ммм, постойте. Но если я правильно вас понимаю, QWidget *parent в этом методе может быть не QTableView, а QListView, или QColumnView; или вообще QTreeView. А то и ваш какой-то там собственный *View. Вряд ли будет правильным с точки зрения технического писателя выделять именно QTableView.

В любом случае, вы можете отправить своё предложение по дополнению документации через Gerrit. Оно будет рассмотрено гораздо быстрее, чем предложение по коду.

Здравствуйте, Мёртвый Даун, Вы писали:

МД>Простой пример для наглядности:
МД>Псевдо (ибо еще в QML синтаксисе еще слабоват):

МД>Item {
МД> id: root
МД> signal clicked
МД> onClicked: root.clicked()
МД> Loader {
МД> id: loader
МД> source = "window.qml"
МД> }
МД>}

МД>По сравнию с MFC тут куча нелогичностей!
МД>1) В первых строках я читаю так: "Я нажал сам на себя и сам это обработал". Возможно фактически та это не так, но читается именно так!
Все правильно, так и задумано!

МД>Это не по MFC-ишному. Непонятно где обработчик и где его надо писать. Вообще ничо непонятно, блин!

Qml — декларативный язык, C++ — императивный.
Классический пример задания, демонстрирующего преимущества декларативного языка с точки зрения краткости и выразительности: нарисовать прямугольник с заданным соотношением сторон.
Qml:

Rectangle {
    width: 100
    height: width/2
}

На любом императивном языке достичь такого же результата будет в 10 раз длиннее и сложнее. Хоть на MFC, хоть на Qt/C++.

МД>Хмм... я ж не голословно написал. Сравниваю реалии. Тривиальные вещи отнимают массу времени. MFC почему то столько не отнимал.

Просто новую логику ухватить надо, далее она везде единая. Qt очень последовательная библиотека.

У меня был прямо противоположный опыт: после года на Qt надо было сделать что-то довольно простое на MFC (вроде специализированный прогресс-бар). Когда до меня наконец-то дошло как это сделать, я сначала не поверил, что так нелепо не логично оно может быть.

Здравствуйте, kov_serg, Вы писали:

_>http://habrahabr.ru/post/194590/ ?
_>...

Позволю себе процитировать оттуда первый абзац:

Если вы фрилансер или любите экспериментировать с экзотическими средами под С++, то стоит обратить внимание на экосистему Ultimate++...

Захотелось людям поэкспериментировать — хорошо. Но для продакшн кода этому проекту врядли светит дорасти. И не только по техническим причинам.
Как там с поддержкой кросс-платформенности / WinRT? Удобно ли добавлять новые API c выходом новых версий винды? Есть ли комьюнити / поддержка?
И вот таких вопросов можно задать вагон. Ответ на которые однозначно определяет кто есть кто. Ну не будут люди пересаживаться на самодельные мопеды с хорошо отлаженных автомобилей.

Здравствуйте, EXL, Вы писали:

EXL>Здравствуйте, _hum_, Вы писали:

__>>ее же можно было взять и из parent, если бы было известно, что им является QTableView (подчеркиваю, я не говорю, что именно так надо было бы делать разработчикам qt, я лишь обращаю внимание на то, что пространное описание в документации может наводить именно на эту мысль, и тем самым дезориентировать программиста [это все к вопросу о корявости докумнетации]).

EXL>Ммм, постойте. Но если я правильно вас понимаю, QWidget *parent в этом методе может быть не QTableView, а QListView, или QColumnView; или вообще QTreeView. А то и ваш какой-то там собственный *View. Вряд ли будет правильным с точки зрения технического писателя выделять именно QTableView.

QTableView было упомянуто только для конкретики. А в общем, достаточно было бы просто знать, что это указатель на виджет представления модели.

EXL>В любом случае, вы можете отправить своё предложение по дополнению документации через Gerrit. Оно будет рассмотрено гораздо быстрее, чем предложение по коду.

спасибо, буду иметь в виду.

	От:	Igore
	Дата:	02.10.15 07:04
	Оценка:

	От:	SaZ
	Дата:	02.10.15 07:45
	Оценка:

	От:	SaZ
	Дата:	02.10.15 07:51
	Оценка:

	От:	SaZ
	Дата:	02.10.15 07:52
	Оценка:

	От:	kov_serg
	Дата:	02.10.15 08:03
	Оценка:

	От:	EXL
	Дата:	03.10.15 17:26
	Оценка:

	От:	Skorodum
	Дата:	03.10.15 22:16
	Оценка:

	От:	_hum_
	Дата:	04.10.15 12:21
	Оценка:

	От:	_hum_
	Дата:	04.10.15 14:52
	Оценка: