Теперь будем продавать билеты с включённым обедом и без него.
Мне кажется что это порочная практика. Придется вводить цветовую дифференциацию штанов. ИМХО, проще либо все С, либо все БЕЗ.
Самый большой зал неплохо смотрелся вечером и пустым, но оказался ужасным днём. Видно и слышно было плохо, постоянные посторонние шумы. Определённые выводы мы для себя сделали, постараемся больше так не ошибаться.
Да. Особенно мешало наличие в этом же зале выставочной/рекреационной зоны, которая по сути являлась чуть ли не главным местом для общения тех, кто в данный момент не слушал доклады. И соответственно иногда в пылу беседы — тон повышался и мешали слушателям.
Но в целом, действительно прошло очень хорошо. Спасибо за конференцию.
к сожалению, в абсолютном большинстве случаев — перенос логики в кумль приводит к сильному уменьшению поддерживаемости и расширяемости кода.
Хотя наверно где-то есть те самые 2% случаев когда все ок, но я их еще не встречал. А вот случаев, когда хватаешься за голову от увиденного и понимаешь что некоторые вещи дешевле переписать с нуля, чем пытаться впихнуть новую фичу — это навидался.
очень много разных вариантов. Начиная от проперти у кнопки (к которой из стиля есть доступ через control) и заканчивая своим хранилищем подобных переменных (например на плюсах через q_property).
Опять-таки, видеть подпись у label логичней, имхо. Если так критично расположение одной строчки с text, аргументируйте, пожалуйста
Ну если логичнее видеть текст кнопки в описании ее стиля — то я даже не знаю что сказать. То, что описывается через style — это именно стилизация, то есть то, как выглядит кнопка. А ее логика (текст в данном случае тоже часть логики) — это сама кнопка.
Можно, опять-таки, не вижу здесь критичности.
Ну это просто как микроскоп для забивания гвоздей. QQuickItem — визуальный элемент.
Всю логику UI порой в принципе невозможно перенести в QML. В зависимости от работы в бэкенде, может и меняться UI.
Очень даже возможно. Обычно делается через кучу сигналов в бекенде, а в кумле эти сигналы слушаются и делаются нужные вещи. Только сигналы конечно не вида paintButtonInColor(), а вида someActionAllowed() и кумль уже сам там разбирается что ему надо сделать при этом. В идеале бекенд не должен знать вообще ничего о том, как устроен UI, иначе можно однажды упереться в абсолютную неподдерживаемость такого кода (когда там будут сотни зависимостей между бекендом и фронтендом и даже небольшое изменение фронтенда приведет к куче багов).
Подобное решение использовал, т.к. изначально хотел использовать знакомые по разработке в Android идиомы, там же в самой вёрстке логика не прописывается, верно (если не создавать кастомные классы для UI).
Было бы странно в андроиде использовать привычки из Qt, а в хаскелле привычки из паскаля. Все инструменты очень разные
ну и плюс кому действительно надо (например огромная система на четверке, которую писали 20 человеколет) — просто остаются на четверке. Legacy — оно такое
Я не стал сильно вчитываться и читал больше по диагонали, но вкратце — я бы такой код не принял и отправил бы переделывать с нуля. Возможно еще много бы при этом сказал не очень красивых слов.
Ниже то, что совсем уж цепануло глаз.
Изначально делал приложение таким образом, чтобы для каждого окна был свой класс с привязанным к нему интерфейсом (использующим QML-файл). Когда мы открываем новое окно — создаётся экземпляр соответствующего класса, это окно отображается сверху, старое никуда не исчезает. Когда закрываем текущее окно, экземпляр класса удаляется, а предыдущее окно становится вновь видимым.
Это наверно один из худших вариантов, как можно работать с кумлем
Qt достаточно часто обновляется, что, с одной стороны, хорошо, но, с другой стороны, порой делает разработку ночным кошмаром. Происходит это потому, что новые версии не имеют совместимости со своими предшественниками, часть функционала которых в лучшем случае устаревает, в худшем — становится более недоступной.
Простите, что? 5.3 не совместим с 5.2? Вы точно в этом уверены?
Несовместимость есть только между мажорными версиями, Четверка жила лет 8, пятерка только начала свой путь.
DevDays есть и в Европе и в Штатах. Там еще есть один косяк — саммит проводился всего 3 года, посещать его 10 лет было бы крайне проблематично. Даже для суровых бородатых дядей.
возродят (слот про амбассадорку есть в расписании саммита), но явно через одно место и в стиле диджии (то есть с какой-нить очередной коммерционализацией)
мне она не нравится как разработчику своей закрытостью в плане смешения с другими лицензиями. А сказки про максимальную свободу для пользователя меня всегда смешили, да. Как и дядя Столман
GPL3 это очень закрытая лицензия, давайте будем честны. А уж про драйвера открытые это совсем смешно. Миры радеонов (то есть компового железа) и SoC слегка разные. Я (хоть и являюсь убежденным линуксоидом уже почти десять лет) не верю что будет open-source дрова для того же exynos например
Мне кажется что это порочная практика. Придется вводить цветовую дифференциацию штанов. ИМХО, проще либо все С, либо все БЕЗ.
Да. Особенно мешало наличие в этом же зале выставочной/рекреационной зоны, которая по сути являлась чуть ли не главным местом для общения тех, кто в данный момент не слушал доклады. И соответственно иногда в пылу беседы — тон повышался и мешали слушателям.
Но в целом, действительно прошло очень хорошо. Спасибо за конференцию.
Хотя наверно где-то есть те самые 2% случаев когда все ок, но я их еще не встречал. А вот случаев, когда хватаешься за голову от увиденного и понимаешь что некоторые вещи дешевле переписать с нуля, чем пытаться впихнуть новую фичу — это навидался.
очень много разных вариантов. Начиная от проперти у кнопки (к которой из стиля есть доступ через control) и заканчивая своим хранилищем подобных переменных (например на плюсах через q_property).
Ну если логичнее видеть текст кнопки в описании ее стиля — то я даже не знаю что сказать. То, что описывается через style — это именно стилизация, то есть то, как выглядит кнопка. А ее логика (текст в данном случае тоже часть логики) — это сама кнопка.
Ну это просто как микроскоп для забивания гвоздей. QQuickItem — визуальный элемент.
Очень даже возможно. Обычно делается через кучу сигналов в бекенде, а в кумле эти сигналы слушаются и делаются нужные вещи. Только сигналы конечно не вида paintButtonInColor(), а вида someActionAllowed() и кумль уже сам там разбирается что ему надо сделать при этом. В идеале бекенд не должен знать вообще ничего о том, как устроен UI, иначе можно однажды упереться в абсолютную неподдерживаемость такого кода (когда там будут сотни зависимостей между бекендом и фронтендом и даже небольшое изменение фронтенда приведет к куче багов).
Было бы странно в андроиде использовать привычки из Qt, а в хаскелле привычки из паскаля. Все инструменты очень разные
Ниже то, что совсем уж цепануло глаз.
Это наверно один из худших вариантов, как можно работать с кумлем
не надо так делать, пожалуйста. Вы сейчас убили очень много котят этими строками. Есть же анкоры.
не стоит ради такой мелочи городить external reference
Конечно, зачем нам text у самой кнопки, к чему бы он нам
Ни к чему, можно просто QObject. Тем более что все равно он идет как контекстное свойство, даже не как кумльный элемент
это не просто зло, это зло в квадрате. Вся логика работы с UI должна быть в кумле
Простите, что? 5.3 не совместим с 5.2? Вы точно в этом уверены?
Несовместимость есть только между мажорными версиями, Четверка жила лет 8, пятерка только начала свой путь.