« Rev
@ProCxx   264
Fwd »


Andrei
У кьюти была своя замечательная узкая область.
Denis
Речь не об этом. Кьюти хорош для гуёв. Наверное. Но для всего остального он не нужен.
А, если в этом смысле, абсолютно согласен. Нужно было объяснить 😊 Для каждой задачи свой инструментарий.
Andrei
Писать сеть на кьюти и привыкать к этому — очень плохая практика.
Anonymous
Он для гуев, да, но не подключать же доп. библиотеки для сети, если qt умеет с ней работать
Andrei
У меня свой взгляд на чем её писать, но вообще говоря да, при выборе между кьюти и асио, асио предпочтительнее
Andrei
Он для гуев, да, но не подключать же доп. библиотеки для сети, если qt умеет с ней работать
Сейчас объясню. Я всегда вижу проблему такую: чем более универсальный инструмент, тем более он во-первых негибкий, во-вторых менее производительный.
Denis
Нужно же оценивать объективно, нужна ли скорость разработки (стоит ли тратиться на изучение новых библиотек), производительность работы ПО и т.д.
Andrei
Использование кьюти заставляет меня писать всё в стиле кьюти. В то время как сеть я предпочел бы писать в одном стиле. Гуи в другом, бизнес-логику в третьем
Andrei
В этом проявляется негибкость.
Andrei
А потеря производительности проявляется в том, что более общее решение всегда содержит лишние случаи, которые тебе не нужны в работе
Andrei
В то время как написанный код под задачу делает только то, что тебе надо.
Andrei
Это c++-way
Andrei
Я вообще негативно отношусь к сторонним зависимостям. Даже к бусту. Но я подхожу разумно.
Andrei
Понятно что мультииндекс я велосипедить не буду
Andrei
С другой стороны фанбои библиотек тащат их в проект увеличивая время сборки, размер и проьоемы с лицензиями
Andrei
Когда этого можно и не делать.
Andrei
Ну, и так вышло что везде где я работал я не занимался кровавым энтерпрайзом на плюсах, а занимался задачами близкими к системному программированию.
Andrei
Когда у меня была возможность самому с нуля задизайнить всё что надо.
Andrei
Начиная с 11-х плюсов меня устраивает stl целиком и полностью. Сейчас я могу написать практически любой сложности проект с минимальными зависимостями.
Andrei
Кстати, в том чтоткасается гуи, я предпочитаю html-based дизайн. Потому что программисты верстать не умеют.
Andrei
Зато умеют дизайнеры и html им как родной.
Andrei
И этот тренд мне нравится. Как гуи в скайпе, как гуи в антивирусах и так далее.
Anonymous
Насчет перегруженности полностью согласен. Qt действительно тянет и-то что нужно и чего не надо. А как насчет кросплатформенности? Вот я искал библиотеки для написания гуя, из популярных нашел лишь qt и wxwidgets. Остальное либо под одну платформу, либо ноунейм.
Andrei
Они позволяют тебе оформлять гуй в виде html-я и связывать DOM с плюсовым кодом.
Andrei
Есть возможность вообще делать веб-консоль.
Andrei
Для этого нужно только lightweight http сервер разврнуть.
Andrei
На этом подходе есть Wt бибилиотека
Andrei
Но она большая.
Andrei
Я обычно сам делаю. Хттп сервер поднять с обработчиком джсона на плюсах для меня дело часа.
Anonymous
Вот это интересно. C html работать намного удобнее. Я правильно понимаю, для дизайна ведь можно будет использовать css?
Andrei
Да
Andrei
И даже js.
Richard
Вполне отличный подход. Я тоже склоняюсь к тому, чтобы интерфейс был на HTML. Получить хороший результат проще и быстрее, чем на какой-нибудь библиотеке вроде Qt. Может с QtQuick это и быстро, но все же.
🦥Alex Fails
Htmlayout збс вещь
Anonymous
Спасибо за наводку. Может стоит на них перейти пока не поздно. Qt как другой язык, подобный плюсам
Andrei
На Dr. Web пока работал имел дело там и с HTMLayout, на нем там пользовательский гуй сделан в стендэлоуне. И с Wt, на нем сделан энтрепрайз сьют, а я писал на нём внутреннюю контрольную панель для облачного сервиса.
миша
А на кросплатформенные приложения на иос/андроид qtquick не годится?
Denis
Сейчас все поклонники Qt пойдут в HTML 😂
Stanislav
не тянет
Andrei
Ну это пока.
Stanislav
за 5 лет хтмл+жс настолько задолбал, что ну его нах
Andrei
Просто я видел воркфлоу исправления багов в гуи в компании с кьюти, и его же в компании с хтмлем
Andrei
В кьюти баг на гуи заводится на дизайнера юай, он его перезаводит на программиста объясняя что надо сделать, а вечнозанятыф программист потом что-то правит, иногда неправильно.
Andrei
В случае html баг заведенный на дизайнера им же самим тут же правится в html-е и без пересборки попадает в новый билд ресурсов.
Stanislav
для этого всеж qml и завезли
Andrei
Ага. Вот только с улицы проще нанять дизайнера привычного к цсс, хтмл, жс
John
дизайнер != верстальщик
Andrei
Согласен. Верстальщика.
John
к тому что всё же некоторое разделение обязанностей есть, но тут всё конечно от конторы зависит
Andrei
Ну да. Обычно "дизайнер ui" и верстальщик это одно и то же лицо.
John
я с Qt не работал ниразу, там так же как под андроидом интерфейс в xml ?
John
понятно, лучше погуглю:)
Stanislav
я с Qt не работал ниразу, там так же как под андроидом интерфейс в xml ?
если брать классический подход, и через дизайнер, то в xml сохранит, потом генерит С++ код
John
спасибо
Andrei
То есть пересборка требуется.
миша
Qtшники! Прошу подскажите На кросплатформенные приложения на иос/андроид qtquick не годится?
帕沙
По поводу сети на Qt
帕沙
Удобно
帕沙
Кроссплатформенно и не надо лишние библиотеки тащить
Andrei
А кьюти это не бибилиотеку тащить?
Andrei
И да, я уже сказал про импритинг.
帕沙
Её всё равно же тащить
帕沙
Для gui
Andrei
Как выясняется не обязательно.
Andrei
А библиотек сетевых куча разных
Andrei
И удобство это очень субъективный критерий.
Andrei
Я и асио видел и zeromq
Andrei
И черта в ступе.
帕沙
А библиотек сетевых куча разных
То есть тащить и Qt и сетевую?
帕沙
Я и асио видел и zeromq
Асио это который звук?
Andrei
boost::asio
Andrei
Какой звук?
Stanislav
ну вот примут асио в С++17 ничо тащить не надо будет)
Andrei
Не примут, конечно, но дело не в этом.
« Rev
@ProCxx   264
Fwd »