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

Здравствуйте, _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-функций), что опять же упрощает жизнь;

см. выше

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

это хорошо

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

Я не фанат 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.