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

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

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

МД>Окэй, конкретно мой случай, QML:

МД>1) есть окно с кнопкой (window1.qml)
МД>2) есть второе окно (window2.qml)

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

А это разве не оно?

Button {
    text: "Test dialog"
    onClicked: {
        var component = Qt.createComponent("Popup.qml");
        if (component.status === Component.Ready) {
        var dialog = component.createObject(parent,{popupType: 1});
        dialogConnection.target = dialog
        dialog.show();
   }
}

__>Но в качестве отправной я бы выделил "Макс Шлее Qt4 Профессиональное программирование на С++".
Уже версия 5.3 описана в очередном издании.
Но все равно отстает...

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

__>>Но в качестве отправной я бы выделил "Макс Шлее Qt4 Профессиональное программирование на С++".
LVV>Уже версия 5.3 описана в очередном издании.
LVV>Но все равно отстает...

судя по отзывам, принципиальных отличий изданий нет

LVV>>Уже версия 5.3 описана в очередном издании.
LVV>>Но все равно отстает...

__>судя по отзывам, принципиальных отличий изданий нет
QtCreator описан довольно подробно — чего в 4 версии не было.

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

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

МД>>После MFC + WinAPI, Qt просто мозг ломает капитально! Как изучать?
__>Я тоже, к сожалению, так и не нашел нормальной литературы на русском.

Так ни на каком нету языке! В том то и дело!

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

LVV>>>Уже версия 5.3 описана в очередном издании.
LVV>>>Но все равно отстает...

__>>судя по отзывам, принципиальных отличий изданий нет
LVV>ЙеСкуфещк описан довольно подробно — чего в 4 версии не было.

да уж, "новизна"

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

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

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

МД>>>После MFC + WinAPI, Qt просто мозг ломает капитально! Как изучать?
__>>Я тоже, к сожалению, так и не нашел нормальной литературы на русском.

МД>Так ни на каком нету языке! В том то и дело!
Ну, я пока в англоязычном контенте глубоко не копался, потому говорить ничего не буду. Но наверное, да, и там будут разрозненные фрагменты, которые придется собирать по кусочкам в цельное представление.

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

МД>Ну, QML вообще какие то обкуренные люди придумали... Там мозг вообще отказывается воспринимать даже исходники. (Хотя, впрочем как и в самом Qt).

QML — это надстройка над JS. Заточенная по Qt. Что вы там видите укуренного я не понимаю (хотя и не курю). JS по вашему — сложный язык? Не нравится — не учите, вас же никто не заставляет их использовать

.
Видимо, skype/google earth/itunes (win)/Kaspersky/Maya/VCL/VirtualBox и много других интересных проектов используют Qt потому, что они не оценили всю мощь, стабильность и красоту давно мёртвого mfc?

А какая у Qt документация — вообще сказка.

МД>(Как же в MFC всё просто и логично!)

Вы ещё скажите, что в turbo vision всё просто и логично. Я понимаю, что сложно учить что-то новое. Но в случае с Qt — это оправдано. Qt намного удобнее и проще в использовании, и написана значительно лучше, чем MFC.

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

SaZ>А какая у Qt документация — вообще сказка.

О, да. "Сказка". Помни свой шок, когда прочел в справке

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.

То есть, вместо того, чтобы мне сказать, что из себя представляют аргументы функции (например, какой именно виджет будет считаться родительским), мне общими фразами говорят, для чего они используются. Это почти то же самое, как в описании к функции log(x,y) прочесть "x,y используются для вычисления значения логарифма".

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

__>То есть, вместо того, чтобы мне сказать, что из себя представляют аргументы функции (например, какой именно виджет будет считаться родительским), мне общими фразами говорят, для чего они используются. Это почти то же самое, как в описании к функции log(x,y) прочесть "x,y используются для вычисления значения логарифма".

Попробуйте, для разнообразия, почитать документацию. Я понимаю, что это тяжело, не современно, что надо как в mfc- познавать всё методом научного тыка... В доке же можно прямо по типам параметров кликать, чтобы перейти на нужные страницы.
Что такое "делегат" в рамках QtMVC: http://doc.qt.io/qt-5/model-view-programming.html
QWidget, QStyleOptionViewItem, QModelIndex.

А ещё можно программировать "через точечку/стрелочку" и почитать, что же за такие структуры вам передают.

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

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

__>>То есть, вместо того, чтобы мне сказать, что из себя представляют аргументы функции (например, какой именно виджет будет считаться родительским), мне общими фразами говорят, для чего они используются. Это почти то же самое, как в описании к функции log(x,y) прочесть "x,y используются для вычисления значения логарифма".

SaZ>Попробуйте, для разнообразия, почитать документацию. Я понимаю, что это тяжело, не современно, что надо как в mfc- познавать всё методом научного тыка... В доке же можно прямо по типам параметров кликать, чтобы перейти на нужные страницы.
SaZ>Что такое "делегат" в рамках QtMVC: http://doc.qt.io/qt-5/model-view-programming.html
SaZ>QWidget, QStyleOptionViewItem, QModelIndex.

SaZ>А ещё можно программировать "через точечку/стрелочку" и почитать, что же за такие структуры вам передают.

SaZ, вот вы опять выдумываете то, чего не было. Я не говорил, что Qt плох, я говорил, что документация к нему намного хуже MSDN-кой (той, что к MFC).
Еще раз, вот нужно мне узнать, что из себя в функции QItemDelegate::createEditor представляет параметр parent (например, меня интерeсует, является ли он указателем на QTableView или какие-то его подклассы и проч.). В нормальной доке либо напрямую написали бы, либо дали ссылки на эту инфу. В Qt-шной ничего подобного нет (приводить в данном случае ссылку на описание класса QWidget — это то же самое, что в документации к функции log(float x, float y) приводить ссылку на описание типа float)?

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

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

МД>>Ну, QML вообще какие то обкуренные люди придумали... Там мозг вообще отказывается воспринимать даже исходники. (Хотя, впрочем как и в самом Qt).

SaZ>QML — это надстройка над JS. Заточенная по Qt. Что вы там видите укуренного я не понимаю (хотя и не курю). JS по вашему — сложный язык? Не нравится — не учите, вас же никто не заставляет их использовать

.

JS — тоже со своими фишками, но по крайней мере логичный! В Qt — по моему всё алогично и непривычно!

Простой пример для наглядности:

Псевдо (ибо еще в QML синтаксисе еще слабоват):

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

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

2) Я как раз и хочу залоадить ЭТОТ элемент "window.qml" и показать, а лоадер оказывается в нем самом. Как так? Непонимаю!
Т.е., что логичней?
Так:
MyLoader->load(Item) // в нормальных библиотеках делают всегда так
или так:
хмм... даже немогу записать... мозг на раскаряку от такой (НЕ)логики... "Я хочу загрузить то, что я загружаю... или загружается..."... Жесть!

SaZ>Видимо, skype/google earth/itunes (win)/Kaspersky/Maya/VCL/VirtualBox и много других интересных проектов используют Qt потому, что они не оценили всю мощь, стабильность и красоту давно мёртвого mfc?

SaZ>А какая у Qt документация — вообще сказка.

У Вас наверное какая то своя Qt, спец версия?! У Qt документации нет вообще, от слова совсем. Про примеры там даже и незнают.

МД>>(Как же в MFC всё просто и логично!)

SaZ>Вы ещё скажите, что в turbo vision всё просто и логично. Я понимаю, что сложно учить что-то новое. Но в случае с Qt — это оправдано. Qt намного удобнее и проще в использовании, и написана значительно лучше, чем MFC.

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

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

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

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

SaZ>По примерам в интернете (то, что попроще), по статьям, по опен сорс проектам. Так, в общем-то большинство технологий осваиваются.
SaZ>Главное — писать код. Придумайте себе задачу (табличку вывести со статистикой по компу, например), сделайте, выложите на код ревью.
SaZ>QML я бы сразу не изучал, начал бы с основ QtCore + QtNetwork. Но если уж хочется — вот неплохой пример: http://www.ics.com/blog/multilayered-architecture-qt-quick

Да кто ж спорит, но почему то не раз слышал, что чтобы успешно писать с Qt — надо какой-то особый склад ума иметь.

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

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

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

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

SaZ>>По примерам в интернете (то, что попроще), по статьям, по опен сорс проектам. Так, в общем-то большинство технологий осваиваются.
SaZ>>Главное — писать код. Придумайте себе задачу (табличку вывести со статистикой по компу, например), сделайте, выложите на код ревью.
SaZ>>QML я бы сразу не изучал, начал бы с основ QtCore + QtNetwork. Но если уж хочется — вот неплохой пример: http://www.ics.com/blog/multilayered-architecture-qt-quick

МД>Да кто ж спорит, но почему то не раз слышал, что чтобы успешно писать с Qt — надо какой-то особый склад ума иметь.

Мёртвый Даун, вы речь про QML или Qt? Если про последний, то там ничего такого "ломающего голову", вроде, нет. Первые бросающиеся в глаза принципиальные отличия от MFC:
— нет разделения на системный объект окна и объект класса окна (что намного упрощает жизнь — не надо следить за тем, чтобы создание и удаление одного не происходило раньше/позже другого) — вместо этого все представляется одним объектом — виджетом (он сам рисует графическое изображение окна);
— связи между виджетами строятся большей частью не на механизме системных сообщений, а на механизме сигналов-слотов (варианта версии callback-функций), что опять же упрощает жизнь;
— вводится такое понятие как менеджер раскладки, который позволяет отвязаться от фиксированной привязки расположения дочерних виджетов в окне родительского;
— существенное внимание уделяется архитектуре модель-представление — вводятся стандартные средства для разработки наиболее типичных моделей данных (многомерных вложенных таблиц) и представлений для них (таблиц, деревьев);
...

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

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

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

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

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

SaZ>>>По примерам в интернете (то, что попроще), по статьям, по опен сорс проектам. Так, в общем-то большинство технологий осваиваются.
SaZ>>>Главное — писать код. Придумайте себе задачу (табличку вывести со статистикой по компу, например), сделайте, выложите на код ревью.
SaZ>>>QML я бы сразу не изучал, начал бы с основ QtCore + QtNetwork. Но если уж хочется — вот неплохой пример: http://www.ics.com/blog/multilayered-architecture-qt-quick

МД>>Да кто ж спорит, но почему то не раз слышал, что чтобы успешно писать с Qt — надо какой-то особый склад ума иметь.

__>Мёртвый Даун, вы речь про QML или Qt?

Именно в этом посте про QML. Но Qt тоже отчасти это касается, хотя в нем както уже боле мене разобрался... Но мозг ломать от этого всё равно не перестает...

__>- нет разделения на системный объект окна и объект класса окна (что намного упрощает жизнь — не надо следить за тем, чтобы создание и удаление одного не происходило раньше/позже другого) — вместо этого все представляется одним объектом — виджетом (он сам рисует графическое изображение окна);

Это с трудом вписывается в архитектуру ОС Windows. Но это не проблема Windows, просто... оно так устроено.

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

см. выше

__>- вводится такое понятие как менеджер раскладки, который позволяет отвязаться от фиксированной привязки расположения дочерних виджетов в окне родительского;

это хорошо

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

Я не фанат MVC, наверное даже противник...

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

__>SaZ, вот вы опять выдумываете то, чего не было. Я не говорил, что Qt плох, я говорил, что документация к нему намного хуже MSDN-кой (той, что к MFC).
__>Еще раз, вот нужно мне узнать, что из себя в функции QItemDelegate::createEditor представляет параметр parent (например, меня интерeсует, является ли он указателем на QTableView или какие-то его подклассы и проч.). В нормальной доке либо напрямую написали бы, либо дали ссылки на эту инфу. В Qt-шной ничего подобного нет (приводить в данном случае ссылку на описание класса QWidget — это то же самое, что в документации к функции log(float x, float y) приводить ссылку на описание типа float)?

меня интерeсует, является ли он указателем на QTableView или какие-то его подклассы и проч.

Если интересует — то может взять parent->metaObject() и посмотреть. Но с точки зрения MVC вас это не должно интересовать. Это просто некий абстрактный widget, который вы должны использовать как parent для своего редактора. Потому что там может быть всё что угодно. На то он и MVC.

это то же самое, что в документации к функции log(float x, float y) приводить ссылку на описание типа float)?

Для меня навигация по типам аргументов является нормальной. Документация автогенерируется и нет смысла искусственно кастрировать какие-либо описания. Это очень удобно, когда всё выдержано в одном стиле.

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

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

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

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

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

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

SaZ>>>>По примерам в интернете (то, что попроще), по статьям, по опен сорс проектам. Так, в общем-то большинство технологий осваиваются.
SaZ>>>>Главное — писать код. Придумайте себе задачу (табличку вывести со статистикой по компу, например), сделайте, выложите на код ревью.
SaZ>>>>QML я бы сразу не изучал, начал бы с основ QtCore + QtNetwork. Но если уж хочется — вот неплохой пример: http://www.ics.com/blog/multilayered-architecture-qt-quick

МД>>>Да кто ж спорит, но почему то не раз слышал, что чтобы успешно писать с Qt — надо какой-то особый склад ума иметь.

__>>- нет разделения на системный объект окна и объект класса окна (что намного упрощает жизнь — не надо следить за тем, чтобы создание и удаление одного не происходило раньше/позже другого) — вместо этого все представляется одним объектом — виджетом (он сам рисует графическое изображение окна);

МД>Это с трудом вписывается в архитектуру ОС Windows. Но это не проблема Windows, просто... оно так устроено.

Это хорошо, что теперь программисту не нужно задумываться над тем, на какой ОС будет запущена его прога (хотя, конечно, за это приходится платить меньшей эффективностью).

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

МД>см. выше

Прекрасно вкладывалось и в том же MFC, просто ими там не часто пользовались. Опять же, теперь программисту не нужно работать на таком низком уровне как системные очереди сообщений и т.п. Все поднимается на более высокий логический уровень сигналов и событий.

__>>- вводится такое понятие как менеджер раскладки, который позволяет отвязаться от фиксированной привязки расположения дочерних виджетов в окне родительского;

МД>это хорошо

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

МД>Я не фанат MVC, наверное даже противник...

Ну, в этом случае используйте контролы — в них модели с представлениями "слиты" в один объект, и нет особой надобности обращаться к ним по-отдельности...

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

МД>JS — тоже со своими фишками, но по крайней мере логичный! В Qt — по моему всё алогично и непривычно!

Любой язык логичный с чьей либо точки зрения. Даже Перл. Используйте то, что вам нравится.

МД>Простой пример для наглядности:
МД>...
МД>По сравнию с MFC тут куча нелогичностей!

Попробуйте теперь тоже самое сделать средствами C++ и у вас сразу всё получится.
А вообще, не буду спорить, я ни mfc ни qml особо не использовал на практике. Я больше в чистом WinAPI и классических QWidget'ах шарю.

МД>хмм... даже немогу записать... мозг на раскаряку от такой (НЕ)логики... "Я хочу загрузить то, что я загружаю... или загружается..."... Жесть!

Повторю то, что писал выше — познакомьтесь сначала с библиотекой Qt, не касаясь QtQuick / QML (кстати, это разные вещи, которые просто используются вместе). Qt — это намного больше, чем красивые окошки. Я сейчас сервера на Qt пишу.

МД>У Вас наверное какая то своя Qt, спец версия?! У Qt документации нет вообще, от слова совсем. Про примеры там даже и незнают.

У меня — официальная документация: http://doc.qt.io/qt-5/reference-overview.html
Так же в дистрибутиве идёт qt demo + куча примеров. Которые можно скомпилировать в два клика и посмотреть.

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

По-моему вы троллите

. Или слишком долго работали с одной лишь MFC. Тривиальные вещи отнимают очень мало времени, если уметь пользоваться инструментом. Фанатам ассемблера тоже тяжело со старта всякие WCF понимать.

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

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

По-моему наоборот, MFC и winapi ломает мозг после Qt.
В Qt (Widgets) наверно единственный недостаток — у виджетов не так уж много событий (в терминах Qt это signals), как в том же винапи или winforms. Ну канеш они это сделали на сигналах, а сигналы выполняются гдето в 1000 раз медленнее чем message map в mfc.
В винформс ты кидаешь компонентов на формочку а потом кликаешь на молнию и вот тебе куча событий. А в кутэ обломишься. Придется читать доки курить.

Ну иногда кое-что сделано недостаточно гибко, но это легко объяснимо, кутэ родом у линупса, а там у них своя атмосфера, то что скажем было в дельфи в 95ом, там появилось только эдак в 2010.

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

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

__>>SaZ, вот вы опять выдумываете то, чего не было. Я не говорил, что Qt плох, я говорил, что документация к нему намного хуже MSDN-кой (той, что к MFC).
__>>Еще раз, вот нужно мне узнать, что из себя в функции QItemDelegate::createEditor представляет параметр parent (например, меня интерeсует, является ли он указателем на QTableView или какие-то его подклассы и проч.). В нормальной доке либо напрямую написали бы, либо дали ссылки на эту инфу. В Qt-шной ничего подобного нет (приводить в данном случае ссылку на описание класса QWidget — это то же самое, что в документации к функции log(float x, float y) приводить ссылку на описание типа float)?

SaZ>

SaZ>меня интерeсует, является ли он указателем на QTableView или какие-то его подклассы и проч.

SaZ>Если интересует — то может взять parent->metaObject() и посмотреть.

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

SaZ>Но с точки зрения MVC вас это не должно интересовать. Это просто некий абстрактный widget, который вы должны использовать как parent для своего редактора. Потому что там может быть всё что угодно. На то он и MVC.

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

SaZ>

SaZ>это то же самое, что в документации к функции log(float x, float y) приводить ссылку на описание типа float)?

SaZ>Для меня навигация по типам аргументов является нормальной. Документация автогенерируется и нет смысла искусственно кастрировать какие-либо описания. Это очень удобно, когда всё выдержано в одном стиле.

о-е. да читайте вы внимательнее. вы мне на замечание, что по параметру QWidget* parent в функции QItemDelegate::createEditor нет информации, начали говорить, что вся информация есть по гиперссылке на QWidget. вот я вам и ответил, что ссылаться в данном случае на QWidget то же самое, что в вопросе о том, что такое x у функции log(float x, float y) сослаться на инфу о типе float.

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

SaZ>>Но с точки зрения MVC вас это не должно интересовать. Это просто некий абстрактный widget, который вы должны использовать как parent для своего редактора. Потому что там может быть всё что угодно. На то он и MVC.
__>в хорошей документации (а речь именно об этом) мне должны предоставить максимум релевантной информации, а уж нужна она или нет читающему, решать ему самому.
__>в данном случае мне нужна была эта информация, чтобы понять, на что ориентироваться при размещении нестандартного окна редактора (задача о редактировании сразу нескольких ячеек таблицы).
Нельзя на такое закладываться, никто тебе не гарантирует что в следующей версии они не добавят новый слой абстракции и parent будет указывать на тот же виджет. Поэтому parent это просто parent. Нужна таблица, пиши ui_->myCoolTable.

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

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

За то после VCL все легко и интуитивно

Управляю вселенной не привлекая внимания санитаров.

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

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

Вот что бывает, когда начинаешь учить что-то неправильно.
Qt — ГОРАЗДО более прямой продукт, чем MFC.
Лично я начинал учить во времена, когда Qt ещё был версии 1.44
Последовательность была такая.
1) Собрал "hello world" (ихний пример).
2) Потом у них был какой-то учебник (с компилируемыми примерами),
который показывал как программа создаётся шаг-за-шагом, всего десять шагов.
3) Потом в папочке examples лежат примеры, как выглядит каждый виджет.
Их можно собирать, смотреть на то, что получилось, и немного корёжить.
Самой большой умственной проблемой было привыкнуть к moc-компилятору.
На всё ушло около недели. Осваивал под Линуксом.

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

__>о, ну да, чтобы узнать про функцию, мне нужно заниматься кодингом — круто.
В документации написано достаточно. Если вас интересуют детали, которые относятся к внутреннему устройству фреймворка, а не к вашему коду, то да, я вас разочарую — надо читать/писать код. И это везде так.

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

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

__>о-е. да читайте вы внимательнее. вы мне на замечание, что по параметру QWidget* parent в функции QItemDelegate::createEditor нет информации, начали говорить, что вся информация есть по гиперссылке на QWidget. вот я вам и ответил, что ссылаться в данном случае на QWidget то же самое, что в вопросе о том, что такое x у функции log(float x, float y) сослаться на инфу о типе float.

Если вы знакомы с моделью памяти в Qt (а это фундаментальные основы фреймворка), о том, что у объекта может быть родитель и владение, то нет смысла об этом упоминать каждый раз в документации к каждому методу. Это очевидно.
И вообще, это нормальная ситуация, когда для того, чтобы сделать правильно и аккуратно какую-либо мелочь, нужно читать не только описание конкретного метода, но и иметь представление об архитектуре фреймворка.

Здорово, что в конечном счёте у вас получится результат. Это — главное. Предлагаю не развивать бессмысленную дискуссию

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

I>Нельзя на такое закладываться, никто тебе не гарантирует что в следующей версии они не добавят новый слой абстракции и parent будет указывать на тот же виджет. Поэтому parent это просто parent. Нужна таблица, пиши ui_->myCoolTable.

Да даже сейчас там вьюпорт присылается, если я не ошибаюсь.

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

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

SaZ>>>Но с точки зрения MVC вас это не должно интересовать. Это просто некий абстрактный widget, который вы должны использовать как parent для своего редактора. Потому что там может быть всё что угодно. На то он и MVC.
__>>в хорошей документации (а речь именно об этом) мне должны предоставить максимум релевантной информации, а уж нужна она или нет читающему, решать ему самому.
__>>в данном случае мне нужна была эта информация, чтобы понять, на что ориентироваться при размещении нестандартного окна редактора (задача о редактировании сразу нескольких ячеек таблицы).
I>Нельзя на такое закладываться, никто тебе не гарантирует что в следующей версии они не добавят новый слой абстракции и parent будет указывать на тот же виджет. Поэтому parent это просто parent. Нужна таблица, пиши ui_->myCoolTable.

извиняюсь, а зачем тогда вообще давать программисту переопределять виртуальную функцию, в которой нельзя пользоваться ее параметрами?

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

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

__>>о, ну да, чтобы узнать про функцию, мне нужно заниматься кодингом — круто.
SaZ>В документации написано достаточно. Если вас интересуют детали, которые относятся к внутреннему устройству фреймворка, а не к вашему коду, то да, я вас разочарую — надо читать/писать код. И это везде так.

__>>в хорошей документации (а речь именно об этом) мне должны предоставить максимум релевантной информации, а уж нужна она или нет читающему, решать ему самому.
SaZ>Если не нужна — просто не кликайте по ссылке с описанием конкретного аргумента.

__>>в данном случае мне нужна была эта информация, чтобы понять, на что ориентироваться при размещении нестандартного окна редактора (задача о редактировании сразу нескольких ячеек таблицы).
SaZ>Ориентируйтесь на передаваемые аргументы — сделали виджет с парентом (который вам дали), разместили в соответствии с iteminfo. Всё. А про редактирование сразу нескольких ячеек я писал — это очень нетипичная ситуация и тут придётся повозиться руками, чтобы написать свой эдитор.

__>>о-е. да читайте вы внимательнее. вы мне на замечание, что по параметру QWidget* parent в функции QItemDelegate::createEditor нет информации, начали говорить, что вся информация есть по гиперссылке на QWidget. вот я вам и ответил, что ссылаться в данном случае на QWidget то же самое, что в вопросе о том, что такое x у функции log(float x, float y) сослаться на инфу о типе float.

SaZ>Если вы знакомы с моделью памяти в Qt (а это фундаментальные основы фреймворка), о том, что у объекта может быть родитель и владение, то нет смысла об этом упоминать каждый раз в документации к каждому методу. Это очевидно.
SaZ>И вообще, это нормальная ситуация, когда для того, чтобы сделать правильно и аккуратно какую-либо мелочь, нужно читать не только описание конкретного метода, но и иметь представление об архитектуре фреймворка.

SaZ>Здорово, что в конечном счёте у вас получится результат. Это — главное. Предлагаю не развивать бессмысленную дискуссию

да, SaZ, видимо, мы с вами по-разному мыслим, потому дискуссия, действительно, похожа на разговор глухого со слепым.

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

__>извиняюсь, а зачем тогда вообще давать программисту переопределять виртуальную функцию, в которой нельзя пользоваться ее параметрами?
Что значит нельзя? Ты их должен использовать(но правильно), этого parent-a ты должен передать создаваемым тобой элементам, чтобы при уничтожении его, твои элементы тоже уничтожались. Ты хочешь исползовать переданные данные не так как это предусматривали создаетели Qt MVC, ну ты конечно можешь это сделать, но если что то ты ССЗБ

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

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

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

__>>извиняюсь, а зачем тогда вообще давать программисту переопределять виртуальную функцию, в которой нельзя пользоваться ее параметрами?
I>Что значит нельзя? Ты их должен использовать(но правильно), этого parent-a ты должен передать создаваемым тобой элементам, чтобы при уничтожении его, твои элементы тоже уничтожались. Ты хочешь исползовать переданные данные не так как это предусматривали создаетели Qt MVC, ну ты конечно можешь это сделать, но если что то ты ССЗБ

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

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

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

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

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

__>SaZ, вот вы опять выдумываете то, чего не было. Я не говорил, что Qt плох, я говорил, что документация к нему намного хуже MSDN-кой (той, что к MFC).

Можете запостить фикс на документацию в геррит — пройдёт очень быстро. Через багтрекер — существенно медленнее (по понятным причинам). Уверяю, на эти действия времени уходит меньше, чем читать этот форум, а тем более — писать. А так да, в Qt есть косяки не только в документации. Но они фиксятся, плюс можно самому фиксить, а потом гордо наблюдать в логах гита своё имя

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

МД>Да кто ж спорит, но почему то не раз слышал, что чтобы успешно писать с Qt — надо какой-то особый склад ума иметь.

Представьте себе, то же самое слышал про MFC

А вот про Qt впервые от Вас (хотя то, что я сказал, Вы, скорее всего, тоже, но от меня)

Судя по треду, чувствуеся еле уловимый запах жирка. Вы привыкли к технологии MFC, я, когда нужно было, мозг на ней поломал. Теперь через призму данной технологии вы хотите изучать другую, с иными подходами. Это равносильно как брать C++ и писать на нём чисто в C стиле — можно, но смысл? Или пытаться ругаться на какой-то RTOS типа ThreadX или FreeRTOS, что они не такие как Windows (TM) или Linux, и что вот это и это не так там, и там (О БОЖЕ!) нет исполняемых файлоы!!!!!!!11111адын

Далее, вы берёте сразу QML, который, по сути, ещё настройка над QtWidgets и иже с ними, а там больше синтаксис в стиле JS, что уже другой язык, что тоже вызывает некоторый диссонанс. Начните постепенно. Как минимум изучите семплы самого Qt, которые идут в комплекте. QML — в самую последнюю очередь.

Советовать как открыть окно в QML не буду, самому пока было достаточно QtWidgets.

Здравствуйте, 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>Какой фикс? Фикс с объяснениями того, что такое 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.

QWidget::QWidget ( QWidget * parent = 0, Qt::WindowFlags f = 0 )

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 вызывает боль и печаль.

Дальше я уже пользовался только офлайн документацией Qt Assistant. Сейчас могу сказать, что книгу читать не обязательно — документация исчерпывающая. Те же азы и базовые концепции там отлично описаны. Можно начать с Programming with Qt — разделы Object Model, Object Trees & Ownership The Meta-Object System, Signals & Slots. Дальше можно перейти на GUI, если надо — Layout Management, The Qt 4 Main Window Classes, Model/View Programming. Это основа. Потом можно изучать интересующие темы.

(Ссылки на доку для Qt4, т.к. под рукой была дока именно на нее. Можно начать с нее, можно с Qt5.)

Также советую параллельно с написанием кода ознакомиться и придерживаться Qt code style guidelines — Coding Conventions.

Потом можно и исходники Qt читать для ознакомления с деталями реализации.

PS вот еще пара полезных вещей:
Container Classes, особенно Algorithmic Complexity.
Threads and QObjects, Starting Threads with QThread, Reentrancy and Thread-Safety.

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

__>>SaZ, вот вы опять выдумываете то, чего не было. Я не говорил, что Qt плох, я говорил, что документация к нему намного хуже MSDN-кой (той, что к MFC).
__>>Еще раз, вот нужно мне узнать, что из себя в функции QItemDelegate::createEditor представляет параметр parent (например, меня интерeсует, является ли он указателем на QTableView или какие-то его подклассы и проч.). В нормальной доке либо напрямую написали бы, либо дали ссылки на эту инфу. В Qt-шной ничего подобного нет (приводить в данном случае ссылку на описание класса QWidget — это то же самое, что в документации к функции log(float x, float y) приводить ссылку на описание типа float)?

DP>Документация в данном случае приводит предельно простое и исчерпывающее: нужно указать родительское окно — ни больше, ни меньше. Кого назначишь parent'ом, тот им и будет.

в документации написано:

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 показывает, что она может сбивать с толку — вместо того, чтобы отчетливо написать что-то типа "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]

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

Здравствуйте, 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 одна из лучших. Необходимость использования литературы просто отпадает.

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

DP>Потом можно и исходники Qt читать для ознакомления с деталями реализации.
Если пошел разговор об исходниках, то нужно почитать еще это:
D-Pointer или тоже самое на русском

DP>PS вот еще пара полезных вещей:
DP>Threads and QObjects, Starting Threads with QThread,
C потоками обязательно к прочтению:
youre-doing-it-wrong и threading-without-the-headache

Здравствуйте, 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.

https://wiki.qt.io/New_Features_in_Qt_5.5

Здравствуйте, 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>Windows packages are all built with -opengl dynamic. No OpenGL-only or ANGLE-only builds are provided anymore.

I>https://wiki.qt.io/New_Features_in_Qt_5.5

Вы сами RDP проверяли или это лишь догадка? Главная фича 5.5 в том, что ~~они забыли положить .pdb-шники~~ графический бэкэнд теперь линкуется динамически и можно в рантайме, при инициализации приложения, выбрать, какой именно загружать.

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

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

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

Здравствуйте, 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>Windows packages are all built with -opengl dynamic. No OpenGL-only or ANGLE-only builds are provided anymore.

I>https://wiki.qt.io/New_Features_in_Qt_5.5

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

А потому библиотеки всё-таки придётся "докинуть". Вот если бы оно во втором пункте начало рендерить в 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.

Здравствуйте, 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. Оно будет рассмотрено гораздо быстрее, чем предложение по коду.

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

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

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

Это не обязательно будет наследник от QAbstractItemView. Потому что внутри вьюхи может быть вьюпорт, а может и не быть. Единственное универсальное знание, это то, что это 100% наследник QWidget. Не более. И из этого надо исходить.

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

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

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

SaZ>Это не обязательно будет наследник от QAbstractItemView. Потому что внутри вьюхи может быть вьюпорт, а может и не быть. Единственное универсальное знание, это то, что это 100% наследник QWidget. Не более. И из этого надо исходить.
не, знания того, что это наследник QWidget недостаточно, потому как представление таблицы, гипотетически, может быть организовано сложным образом, например, каждая строка может быть представлена в виде отдельного виджета (а потому информация о том, где же границы таблицы, так и остаться неизвестными).

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

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

Достаточно, если вы следуете концепции Qt MVC. Если же нет — то тогда вам нужно свою реализацию всего.

Если же каждая строка в неком абстрактном вью будет представлена в виде виджета, то вам всё равно придёт парент в виде QWidget. Какой именно — неважно. Потому что в противном случае нарушается принцип полиморфизма. А Qt очень хорошо следует ООП и паттернам.

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

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

Тогда сами создавайте редактор в обработчике мышиных эвентов в делегате. Не завязывайтесь на createEditor.

SaZ>>Если же вам хочется узнать, что именно скрывается за этим парентом, то вам нужно взять этот парент и уже работать с ним. Это другой контекст, он не относится к методу createEditor. Он относится именно к классу QWidget : public QObject. Которые так же хорошо документированы.

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

Где расположено? — http://doc.qt.io/qt-5/qstyleoptionviewitem.html
Либо, если вы сами пишите делегат, то вы знаете, для какой вьюхи он используется. Я вообще всегда в конструктор делегата передаю указатель на вьюху. Потому что парент — не обязательно вьюха, а, как вы верно заметили, любой виджет.
Тогда, имея индекс — http://doc.qt.io/qt-5/qabstractitemview.html#visualRect

Здравствуйте, 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, Вы писали:

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

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

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

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++ до этого — как до луны.

	От:	Мёртвый Даун
	Дата:	28.09.15 10:45
	Оценка:

	От:	koenjihyakkei
	Дата:	28.09.15 10:53
	Оценка:	+1

	От:	_hum_
	Дата:	28.09.15 10:53
	Оценка:

	От:	Мёртвый Даун
	Дата:	28.09.15 11:15
	Оценка:

	От:	SaZ
	Дата:	28.09.15 11:28
	Оценка:

От:	Anton Batenev	https://github.com/abbat
Дата:	29.09.15 07:31
Оценка:

От:	monah_tuk	http://htrd.su
Дата:	29.09.15 23:51
Оценка:

	От:	DiPaolo
	Дата:	01.10.15 05:54
	Оценка:	4 (2) +2