История изменений

Давайте честно, Qt это говно. Хотя-бы потому что нет нормальной системы отслеживания ошибок.
Может быть там есть соглашение о кодах возврата и кодах ошибок, которое можно использовать для единообразной и логичной отработки отказов?
Или там есть эксепшены, которые позволяют сделать ленивую обработку ошибок, каскадирование и разворот стэка?
Или там все объекты автоматные и не позволяют выполнять методы вне конкретных и чётко описанных состояний, а также имеют четкую систему отслеживания состояний и распространения ошибки?
Подождите, там есть классная штука! При ошибках в ран-тайм на консоль высыпаются сообщения об ошибках! Вот это я понимаю, технология!
И ещё, у объектов есть куча методов типа isReadable,isWritable,isЧтоТоable. Типа хочешь записать - проверь можно-ли, если нельзя - можешь выполнить код, который отработает такую ситуацию, к примеру выведет в консоль сообщение «типа ошибка».
А чего только стоят сигналы, которые в случае присоединения слота по BlockingConnection являются синхронными функциями, в случае QueedConnection отложенными асинхронными
(Хотя у них хорошо получилось организовать реактивность ModelViewFramework с помощью этих самых сигналов) ?
И как следствие жуткая помесь side-эффектов, порождаемых разными участками кода. Вот этот участок кода меняет конфигурацию создаваемого объекта, и будет выполнен в конструкторе в функции main, а вот этот участок вызывается в слоте и будет выполнен только в момент работы EventLoop. Вот этот метод мы делаем обычным синхронным методом, вот этот будет реализован в виде слота, а вот это у нас виртуальная функция-обработчик события, которая будет вызываться из EventLoop когда мы запостим своё сообщение через PostEvent.
Ребята вместо того чтобы разрабатывать логичные и понятные примитивы, из которых можно как из кирпичиков строить своё приложение, а также логичное и понятное центральное ядро - попытались предоставить функционал для решения «типичных», как им казалось задач. Вот к примеру, реализовали они у себя «конечные автоматы», а для чего? Эти автоматы малопригодны для чего-либо кроме как для решения тех проблем, которые появились у них при создании интерфейса со сложной автоматной логикой. Почему они не реализовали, к примеру что-то типа boost::program_options, которую сегодня на хабре(не к ночи будь упомянут) нахваливали, а сделали только куцый парсер конфиг-файлов в виде QSettings?
Пытались прыгнуть выше чем библиотечка для построения GUI? Как-то не вышло. И всякие попытки сделать на ней что-то, отличное от стандартного desktop-gui будут напоминать упорное жевание кактуса и кучу магии.

Давайте честно, Qt это говно. Хотя-бы потому что нет нормальной системы отслеживания ошибок.
Может быть там есть соглашение о кодах возврата и кодах ошибок, которое можно использовать для единообразной и логичной отработки отказов?
Или там есть эксепшены, которые позволяют сделать ленивую обработку ошибок, каскадирование и разворот стэка?
Или там все объекты автоматные и не позволяют выполнять методы вне конкретных и чётко описанных состояний, а также имеют четкую систему отслеживания состояний и распространения ошибки?
Подождите, там есть классная штука! При ошибках в ран-тайм на консоль высыпаются сообщения об ошибках! Вот это я понимаю, технология!
И ещё, у объектов есть куча методов типа isReadable,isWritable,isЧтоТоable. Типа хочешь записать - проверь можно-ли, если нельзя - можешь выполнить код, который отработает такую ситуацию, к примеру выведет в консоль сообщение «типа ошибка».
А чего только стоят сигналы, которые в случае присоединения слота по BlockingConnection являются синхронными функциями, в случае QueedConnection отложенными асинхронными
(Хотя у них хорошо получилось организовать реактивность ModelViewFramework с помощью этих самых сигналов) ?
И как следствие жуткая помесь side-эффектов, порождаемых разными участками кода. Вот этот участок кода меняет конфигурацию создаваемого объекта, и будет выполнен в конструкторе в функции main, а вот этот участок вызывается в слоте и будет выполнен только в момент работы EventLoop. Вот этот метод мы делаем обычным синхронным методом, вот этот будет реализован в виде слота, а вот это у нас виртуальная функция-обработчик события, которая будет вызываться из EventLoop когда мы запостим своё сообщение через PostEvent.
Ребята вместо того чтобы разрабатывать логичные и понятные примитивы, из которых можно как из кирпичиков строить своё приложение, а также логичное и понятное центральное ядро - попытались предоставить функционал для решения «типичных», как им казалось задач. Вот к примеру, реализовали они у себя «конечные автоматы», а для чего? Библиотека же эта малопригодна для чего-либо кроме как для решения тех проблем, которые появились у них при создании интерфейса со сложной автоматной логикой. Почему они не реализовали, к примеру что-то типа boost::program_options, которую сегодня на хабре(не к ночи будь упомянут) нахваливали, а сделали только куцый парсер конфиг-файлов в виде QSettings?
Пытались прыгнуть выше чем библиотечка для построения GUI? Как-то не вышло. И всякие попытки сделать на ней что-то, отличное от стандартного desktop-gui будут напоминать упорное жевание кактуса и кучу магии.