Комментарии 75
Отличное начинание, главное не останавливаться! Вы сказали насчёт предложений, сейчас вот слушаю (может быть еще услышу эту тему), но думаю будет интересно подробно обсудить тему qt governance
Я, пожалуй, для сохранения хронологического порядка сделал бы так :)
std::swap("Qt5: Symbian", "Qt5: модули Widgets, QtQuick1");
tass, ты в конце говорил про эксепшены. Сказал, что тебе нравятся как они сделаны в Java, аргументируя это тем, что возле каждого метода стоит название exception'а, который этот метод кидает.
Но в C++ ведь тоже можно указывать эксепшены, которые кидает метод, с помощью throw() спецификатора (хотя в C++11 jy убран). Да, конечно, ты можешь возразить, что несмотря на этот список, реально метод может кинуть и другие эксепшены, и что это и есть подводный камень. Но ведь в Java тоже так: эксепшены наследуемые от RuntimeException могут не указываться возле метода. И многие библиотеки кидают именно их.
p.s: к слову, лично мне очень не нравится то, как сделаны эксепшены в Java. Вернее, не нравится сам подход к их применению. Стандартная библиотека кишит ими, и все мыслимые и немыслимые методы их бросают, из-за чего код доходит до абсурда: try-блоки вокруг закрытия потока внутри finally другого try-блока. %)
Но в C++ ведь тоже можно указывать эксепшены, которые кидает метод, с помощью throw() спецификатора (хотя в C++11 jy убран). Да, конечно, ты можешь возразить, что несмотря на этот список, реально метод может кинуть и другие эксепшены, и что это и есть подводный камень. Но ведь в Java тоже так: эксепшены наследуемые от RuntimeException могут не указываться возле метода. И многие библиотеки кидают именно их.
p.s: к слову, лично мне очень не нравится то, как сделаны эксепшены в Java. Вернее, не нравится сам подход к их применению. Стандартная библиотека кишит ими, и все мыслимые и немыслимые методы их бросают, из-за чего код доходит до абсурда: try-блоки вокруг закрытия потока внутри finally другого try-блока. %)
Ты смешиваешь реализацию и подход :) Реализация в Java лучше, а сам подход использования эксепшенов мне не нравится. Меня тоже сильно напрягало их повсеместное использование в Java.
Ну, я не смотрел реализацию джава машины, впрочем, как и реализацию C++ компиляторов. Поэтому судить мне сложно. Просто хотел заметить, что указание исключений, которые бросаются методом — это не панацея. Что в Java, что в C++ — с этим есть проблема. Другое дело, что Java выводит stack traceback, что несколько облегчает локализацию проблемы. (но в случае Java не так сильно, как хотелось бы). :)
Это не панацея конечно, но тем не менее это здорово помогает. Особенно если экспшенов много кастомных и они широко используются в коде. В этом случае просто не получится забыть отловить или пробросить эксепшен далее. Эклипс заругается
НЛО прилетело и опубликовало эту надпись здесь
Просто обычно все C++ бинарники по крайней мере на production прицельно пострипаны и особо полезной информации из такого стектрейса не извлечёшь.
НЛО прилетело и опубликовало эту надпись здесь
Все же стоит признать, что иногда Хабр снова становится торт. В посте про подкаст минисрач про плюсы и про цикл релизов (ниже) :D
Предлагаю один из подкастов устроить в форме срача на тему засилия JS'а и невозможности работы Qt5 на всяком старье без openGL ES.
А кто с кем сраться то будет? :) Что я, что Денис вполне положительно относимся к этому.
А где нет OpenGL ES?
НЛО прилетело и опубликовало эту надпись здесь
Ну что значит не используем в статьях? В своем бложике в принципе использую их я. Да и разговорная речь от статей сильно отличается.
нужно в каталоге qtdocs сделать make с ключом qch_docs
Ребята, однозначно продолжайте!
Qt-components с Qt5 я тестил и у меня стили работали!
Даже QtCurve собирал :) Поэтому все теоретически ок, правда в Qt5 там проблемы некоторые с рендерингом.
а на какой платформе? я запустил на кедах и увидел вин95 стайл. Офигел и вырубил до лучших времен?
честно, не знаю как туда знак вопроса в конце попал. Это было утверждение конечно
На кедах и запускал. Был plastique style… у тебя по ходу он попытался плагин для oxygen стиля подцепить.
Запусти с ключем -style. Да и можно QtCurve собрать, он работает! Оо
Запусти с ключем -style. Да и можно QtCurve собрать, он работает! Оо
хм, надо будет еще раз глянуть. Правда у меня там на Qt5 у целевого проекта еще другие были проблемы, помимо компонентов, поэтому запустил, глянул что не ок и вырубил.
Но вообще я сейчас усиленно жду пока Дженс наконец вернется к проекту
Но вообще я сейчас усиленно жду пока Дженс наконец вернется к проекту
Мой мерж там уже пару месяцев висит. Иной раз думаю плюнуть и самому всё запилить :)
лучше все же дождаться. На такой стадии проекта — много разных форков может быть смертельно. Пусть уж будет все в одной ветке, глядишь что и вылезет. А ты не пробовал кстати писать Дженсу?
Меня больше интересует возможность теперь Aero запилить на основе QWindow и QPA.
github.com/gorthauer/qutim/blob/master/core/3rdparty/qtdwm/qtdwm.cpp
В принципе у меня в Qt5 есть winID и я так понимаю, что winEvent можно теперь так ловить.
doc-snapshot.qt-project.org/5.0/qwindow.html#nativeEvent
github.com/gorthauer/qutim/blob/master/core/3rdparty/qtdwm/qtdwm.cpp
В принципе у меня в Qt5 есть winID и я так понимаю, что winEvent можно теперь так ловить.
doc-snapshot.qt-project.org/5.0/qwindow.html#nativeEvent
Список пожеланий:
1. Структура QDeclarativePropertyMap с его QMetaObjectBuilder
2. Косяки type() и typeName() у QVariant
3. Наиболее удачные архитектурные паттерны при разработке десктопных приложений с QML
4. Архитектура SceneGraph
5. Новый синтаксис connect и лямбды
6. Что таки с QFtp — он deprecated или нет, если да то что вместо него (QNAM не предлагать, все примеры все равно с использованием QFtp)
1. Структура QDeclarativePropertyMap с его QMetaObjectBuilder
2. Косяки type() и typeName() у QVariant
3. Наиболее удачные архитектурные паттерны при разработке десктопных приложений с QML
4. Архитектура SceneGraph
5. Новый синтаксис connect и лямбды
6. Что таки с QFtp — он deprecated или нет, если да то что вместо него (QNAM не предлагать, все примеры все равно с использованием QFtp)
Я правильно понимаю, что стабильной поддержки мобильных платформ в Qt5 не будет — Symbian и Harmattan убрали, а iOS, Android, webOS и т.д. не доделали?
Ну на харматтан есть все надежды, но в целом — да. Но тут есть другой момент, архитектура QPA предпологает сильно упрощенное портирование (по сравнению с не-QPA подходом)
Ну то что не доделали, это и сам Qt5 еще не доделали, а потом я бы не стал говорить за весь Qt5,
конкретно в 5.0 ожидать полной поддержки, конечно, не стоит. А дальше время покажет.
конкретно в 5.0 ожидать полной поддержки, конечно, не стоит. А дальше время покажет.
Ну так когда там Melmeti появится, к концу года? Тогда уже наверное 5.1 подоспеет, а то и 5.2. Хрен знает что у них с циклом релизов будет.
Вообще цикл релизов у Trolltech сильно затормозился после их покупки. Не в последнюю очередь из-за усилий, затраченных на адаптацию под Symbian/Harmattan, создание SDK и так далее. Для сравнения, версию 4.7 готовили около 9 месяцев, а версию 4.8 (в которой, по большому счёту, нет принципиальных новшеств) — почти 15.
нет принципиальных новшеств? серьезно? А QPA уже не считается? Или работа по мультипоточности ОпенГЛя? Плюс надо учитывать, что очень много работы велось по исправлению багов в декларативе (и выходе версии 1.1 его).
НЛО прилетело и опубликовало эту надпись здесь
QPA (ну, точнее Qt Lighthouse), насколько я помню, начали делать гораздо раньше. Его, конечно, внедрили, но слегка сбоку. Полноценным запуском QPA, думаю, можно считать выход Qt 5.0 :)
Многопоточность OpenGL — может быть, хотя я не уверен, что это самый широко используемый и популярный модуль в Qt.
С HTTP там другая проблема. Они, конечно, сделали его многопоточность (причём, насколько я понимаю, это была работа одного или двух разработчиков длиной в месяц). Но при этом значительно сломали внутреннюю логику работы, причём так, что фиг поправишь. Если чуть подробнее, QNAM начал некорректно работать с отвалившимися по таймауту соединениями с Keep-Alive, причём так хитро, что хрен воспроизведёшь и хрен покроешь тестами. Но в нашем проекте в одном из мест на Qt 4.8 стабильно ошибка 99 :(
Многопоточность OpenGL — может быть, хотя я не уверен, что это самый широко используемый и популярный модуль в Qt.
С HTTP там другая проблема. Они, конечно, сделали его многопоточность (причём, насколько я понимаю, это была работа одного или двух разработчиков длиной в месяц). Но при этом значительно сломали внутреннюю логику работы, причём так, что фиг поправишь. Если чуть подробнее, QNAM начал некорректно работать с отвалившимися по таймауту соединениями с Keep-Alive, причём так хитро, что хрен воспроизведёшь и хрен покроешь тестами. Но в нашем проекте в одном из мест на Qt 4.8 стабильно ошибка 99 :(
ну дак и декларатив тоже начали делать раньше и в 4.7.0 он был не особо живой (да и в 4.7.4 откуда стартует 1.1 тоже не допилен), так что его тоже можно к 5.0 отнести, так что можно сказать что 4.7 от 4.8 по новшествам не сильно отличается :)
Ну и к тому же Qt Quick 1.1 таки тоже официально фича Qt 4.8, хотя его в 4.7.4 и бэкпортировали.
А обновление вебкита? И таки да, 4.8 уже меньшими силами же делалась, основной упор уже тогда на 5ую ветку был направлен. Поэтому я думаю, что цикл сократится. Точнее разные модули будут с разной скоростью релизится.
А обновление вебкита? И таки да, 4.8 уже меньшими силами же делалась, основной упор уже тогда на 5ую ветку был направлен. Поэтому я думаю, что цикл сократится. Точнее разные модули будут с разной скоростью релизится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подкаст «Заметки о Qt» — первый, пилотный, выпуск