Вопрос: Какой самый адекватный способ въехать в Qt? И чтобы

был баланс между скоростью и качеством.

Боль: Геморойно, конечно, без сноровки и навыка клепать интерфейсы.

Не могу добавить QWidget в QWidget, и из доки непонятно, почему. Хотя могу родительскому QWidget назначить layout, и layout уже имеет метод addWidget.

Могу создать лейаут через QVBoxLayout *vBox = new QVBoxLayout(this), а через QLayout не могу. И сиди раскуривай примеры, которые еще написаны по-разному.

я въехал просто делая по доке

пример кода кидай, в чем трудность

Ты про examples в ide’шке?

Ну ты пишешь, что ты не можешь добавить какой-то виджет. Кидай конкретный пример кода, который ты ждешь, что будет работать, а не работает

ошибся, кидай*

AI Sch.
А, понял. Ну тут код максимально тривиальный. Наве...

Когда создаешь лейаут, переданный аргумент на родителя, автоматически делает setLayout в родителя

Я въезжал по урокам Ravesli, дальше когда их все написал, что-то свое сам садился делать

AI Sch.
А, понял. Ну тут код максимально тривиальный. Наве...

Первый виджет без парента - потенциальный мемори лик

На начальном этапе баланс невозможен, либо медленно но качественно, либо быстро, но некачественно. Причем первый вариант таки со временем приведёт к желаемому балансу, а второй к увольнению

Что такого надо не так понять в Qt, чтобы уволили?)

НАСЛЕДОВАНИЕ и Сигнал-Слот :)

А что можно сделать не так с ними?

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

Так если ты не понял, ты этим и не воспользуешься

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

тогда зачем тебе кьют?

На Qt потечь крайне сложно

элементарно... чес слово

Та легко, опять таки в примере выше, не соблюдать parent-child. Да и банально создать указатель не удалив его потом.

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

Если ты создаешь указатель с парентингом, Qt чистит его за тебя. Меньше шанса сотворить лик

object *a=func(); func() { object *o=new object(); return o; }

Так тут нет парентинга. Это вообще какой-то странный враппер над new

Не обязательно все будет написано на pure Qt. Стоит не забывать что Qt это фреймворк. Да с весьма обширным функционалом, но так или иначе - фреймворк. У нас остается голый язык, плюсы, к которому можно добросить сторонних либ, а то и вовсе других фреймворков. Даже тут в чате не раз советовали использовать функции из буста, как пример.

в реальных проектах много чего встречается. Из последнего например отработка deepurl. По документации QDesktopServices::setUrlHandler должен всё отрабатывать, и на айос отрабатывает, а на андроиде нет. Решилось после двух дней глубокой отладки самого кьюта, выяснения, что в андроиде этот момент просто не реализован, поиск наиболее оптимального варианта самостоятельного решения, реализация. И такое вылазит постоянно

Да я бывает юзаю stl решения в перемешку с Qt. Но на самом деле я рассматриваю Qt как омни фреймворк, на котором можно спокойно писать, даже не зная дебрей стандартной либы.

Блин, у меня сейчас так. На линуксе погано ведут себя вызовы к processEvents()

дело ведь не только в кьюте. Любая задача решается сотней способов и начинающий если гонится за скоростью выбирает далеко не лучшие способы зачастую.

В qt много подводных камней в виде багов, неочевидного поведения, часто приходится не один час в сурсах провести за разбором почему что-то не работает

Это я знаю, баги сам неоднократно встречал.

и не только баги. Нюансы работы компонентов тоже требуют времени на изучение

Так какой пайплайн изучения предлагаете?

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

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

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

Это архитектуры всратые. И вообще есть std::unique_ptr

https://github.com/desktop-app/lib_ui/blob/master/ui/wrap/vertical_layout.h