Pull to refresh
87
0
Денис Кормалев @tass

C++/Qt

Send message
Теперь будем продавать билеты с включённым обедом и без него.

Мне кажется что это порочная практика. Придется вводить цветовую дифференциацию штанов. ИМХО, проще либо все С, либо все БЕЗ.

Самый большой зал неплохо смотрелся вечером и пустым, но оказался ужасным днём. Видно и слышно было плохо, постоянные посторонние шумы. Определённые выводы мы для себя сделали, постараемся больше так не ошибаться.

Да. Особенно мешало наличие в этом же зале выставочной/рекреационной зоны, которая по сути являлась чуть ли не главным местом для общения тех, кто в данный момент не слушал доклады. И соответственно иногда в пылу беседы — тон повышался и мешали слушателям.

Но в целом, действительно прошло очень хорошо. Спасибо за конференцию.
пожалуйста, не надо придумывать такие названия. Оно не соответствует действительности. Есть асинхронные вызовы.
к сожалению, в абсолютном большинстве случаев — перенос логики в кумль приводит к сильному уменьшению поддерживаемости и расширяемости кода.
Хотя наверно где-то есть те самые 2% случаев когда все ок, но я их еще не встречал. А вот случаев, когда хватаешься за голову от увиденного и понимаешь что некоторые вещи дешевле переписать с нуля, чем пытаться впихнуть новую фичу — это навидался.
Откуда идет это желание сделать логику на кумле, который для это не предназначен? Плюсы же удобнее на порядок
как следует поступить лучше в данном случае?

очень много разных вариантов. Начиная от проперти у кнопки (к которой из стиля есть доступ через control) и заканчивая своим хранилищем подобных переменных (например на плюсах через q_property).
Опять-таки, видеть подпись у label логичней, имхо. Если так критично расположение одной строчки с text, аргументируйте, пожалуйста

Ну если логичнее видеть текст кнопки в описании ее стиля — то я даже не знаю что сказать. То, что описывается через style — это именно стилизация, то есть то, как выглядит кнопка. А ее логика (текст в данном случае тоже часть логики) — это сама кнопка.
Можно, опять-таки, не вижу здесь критичности.

Ну это просто как микроскоп для забивания гвоздей. QQuickItem — визуальный элемент.
Всю логику UI порой в принципе невозможно перенести в QML. В зависимости от работы в бэкенде, может и меняться UI.

Очень даже возможно. Обычно делается через кучу сигналов в бекенде, а в кумле эти сигналы слушаются и делаются нужные вещи. Только сигналы конечно не вида paintButtonInColor(), а вида someActionAllowed() и кумль уже сам там разбирается что ему надо сделать при этом. В идеале бекенд не должен знать вообще ничего о том, как устроен UI, иначе можно однажды упереться в абсолютную неподдерживаемость такого кода (когда там будут сотни зависимостей между бекендом и фронтендом и даже небольшое изменение фронтенда приведет к куче багов).
Подобное решение использовал, т.к. изначально хотел использовать знакомые по разработке в Android идиомы, там же в самой вёрстке логика не прописывается, верно (если не создавать кастомные классы для UI).

Было бы странно в андроиде использовать привычки из Qt, а в хаскелле привычки из паскаля. Все инструменты очень разные
медленно. Тяжело поддерживаемый код. Нет той гибкости, которая есть в плюсах.
ну и плюс кому действительно надо (например огромная система на четверке, которую писали 20 человеколет) — просто остаются на четверке. Legacy — оно такое
ну если для вас 8 лет — это очень часто, то я даже не знаю что сказать. Без таких обновлений мы бы погрязли в legacy-коде и идеях 20-летней давности.
Я не стал сильно вчитываться и читал больше по диагонали, но вкратце — я бы такой код не принял и отправил бы переделывать с нуля. Возможно еще много бы при этом сказал не очень красивых слов.
Ниже то, что совсем уж цепануло глаз.

Изначально делал приложение таким образом, чтобы для каждого окна был свой класс с привязанным к нему интерфейсом (использующим QML-файл). Когда мы открываем новое окно — создаётся экземпляр соответствующего класса, это окно отображается сверху, старое никуда не исчезает. Когда закрываем текущее окно, экземпляр класса удаляется, а предыдущее окно становится вновь видимым.

Это наверно один из худших вариантов, как можно работать с кумлем

Button {
width: mainWindow.width / 2.5
height: mainWindow.height / 10
x: 0
y: mainWindow.height — height
}

не надо так делать, пожалуйста. Вы сейчас убили очень много котят этими строками. Есть же анкоры.

font.pixelSize: (mainWindow.width>mainWindow.height)? parent.height/1.75: parent.height / 2.5

не стоит ради такой мелочи городить external reference

style: ButtonStyle {
background: ButtonBackground {}
label: ButtonLabel { text: «Тест» }
}

Конечно, зачем нам text у самой кнопки, к чему бы он нам

class Backend: public QQuickItem

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

mainWindow = engine.rootObjects().value(0);
lvList = mainWindow->findChild<QObject*>(«lvList»);
btnRequest = mainWindow->findChild<QObject*>(«btnRequest»);

это не просто зло, это зло в квадрате. Вся логика работы с UI должна быть в кумле
Qt достаточно часто обновляется, что, с одной стороны, хорошо, но, с другой стороны, порой делает разработку ночным кошмаром. Происходит это потому, что новые версии не имеют совместимости со своими предшественниками, часть функционала которых в лучшем случае устаревает, в худшем — становится более недоступной.

Простите, что? 5.3 не совместим с 5.2? Вы точно в этом уверены?
Несовместимость есть только между мажорными версиями, Четверка жила лет 8, пятерка только начала свой путь.
Когда кто-то пытается реализовать всю логику на кумле, да еще и с поддержкой сети — бог убивает одного котенка.
Виджеты вроде стилизуются под андроид. Quick Controls с андроидовскими стилями я думаю к 5.5 надо ожидать. Про иос вообще сказать ничего не могу
DevDays есть и в Европе и в Штатах. Там еще есть один косяк — саммит проводился всего 3 года, посещать его 10 лет было бы крайне проблематично. Даже для суровых бородатых дядей.
возродят (слот про амбассадорку есть в расписании саммита), но явно через одно место и в стиле диджии (то есть с какой-нить очередной коммерционализацией)
фиг знает. У меня всегда в креаторе открыто больше 10. Я бы сказал от 20 примерно и до бесконечности
для совместимости с кем? Если учесть что это полная прошивка, а не надстройка над текущей системой
вот на lgpl я согласен. Он гораздо приятнее. Но все это утопия в любом случае. Бизнес, ничего личного
мне она не нравится как разработчику своей закрытостью в плане смешения с другими лицензиями. А сказки про максимальную свободу для пользователя меня всегда смешили, да. Как и дядя Столман
GPL3 это очень закрытая лицензия, давайте будем честны. А уж про драйвера открытые это совсем смешно. Миры радеонов (то есть компового железа) и SoC слегка разные. Я (хоть и являюсь убежденным линуксоидом уже почти десять лет) не верю что будет open-source дрова для того же exynos например

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity