tass, хорошая статья и хорошо показывает возможности QML, но я все же добавлю каплю дёгтя.
а больше преследует цель показать, что QML является очень гибким и простым средством разработки.
Я считаю, что это заявление, которое проскальзывает в каждом посте есть попытка выдать желаемое за действительное. Я бы сказал по другому: QML должен стать очень гибким и простым средством разработки. Сейчас он сырой, очень сырой. И когда дело доходит до сложной логики, то доходит до таких танцев с бубном, что «сложный» C++ нервно курит в стороне.
Поясню: к примеру, попробуйте добавить к примеру выше, анимацию перемешивания элементов, когда вы делаете drop сохранив, при этом, функционал Flickable части GridView. Будет очень весело, да вот только сделать это надежно,невозможно с QtQuick 1.1.
Отдельного внимания заслуживают MouseArea, которые не умеют игнорировать события, для того, чтобы нижележащие элементы могли их обработать. Эта особенность раскрасит ваши серые будни, т.к. вам придется выдумывать недюжинные способы, чтобы это обойти.
Да и по мелочам там всякого хватает…
При этом, я не агитирую против QML, наоборот, это замечательная технология. Просто нужно будь в курсе, что многие вещи придется делать через ж… или писать свой элемент на C++ с последующим его экспортированием в QML(наличие такой возможности есть несомненный плюс QML)
Комментарий размещен скорее для читателей, а не автора, т.к. я уверен, что автор и без моего комментария это знает.
P.S.
и манипулируя свойством interactive
лучше манипулировать свойством preventStealing из MouseArea это позволит сохранить возможность прокрутки колесом.
Почему не упомянут Binding элемент? Да и вообще тема раскрыта узковато. Может стоить отойти от попсового стиля разбивать статьи на одну тему на N постов и выкладывать полноценный материал?
1. Я не автор, но в тезисе «делая правильную работу, деньги сами тебя найдут» есть небольшая неточность, т.к. найдут тебя не обязательно деньги. Просто условия всегда будут складываться так, чтобы ты мог выполнять эту работу. Если для этого требуются деньги, значит это будут деньги.
По поводу религиозной части: в религии выход из сансары существует, и он может быть найден\получен\заслужен при жизни, поэтому не стоит откладывать на следующую жизнь :)
не знаю, как там с точки зрения закона, но заказчик при нужде в повторной подписи договора просто вставил отсканенную подпись. Никто не хочет тратить время на подобное. Если я не прав и сделал что-то мега-противозаконное — буду рад узнать.
ну у меня прям в тарифах: «услуги валютного контроля 10$». И никаких проблем не было у меня. Другое дело, что некоторые банки(привет Альфа) не позволяют открыть только валютный счет; только парное открытие
Пожалуйста пишите в начале статьи о Вашем сервисе краткое резюме; о том, какую проблему он решает.
Не хочется ходить по ссылке, чтобы быстро понять о чем пойдет речь. Спасибо!
Теперь одна хитрость. Чтобы каждый раз не делать акты приёма-передачи, подписывать и сканировать их — можно в контракте прописать пункт о том, что оплата заказчиком инвойса (счёта) влечёт за собой принятие оказанных услуг.
Прикольно, не знал, что так можно. Я просто вставлял отсканенные подписи, не забивая голову заказчику всякой ерундой типо актов.
Но на самом деле, в этом случае произойдет вызов конструктора в первой строке, далее вызов конструктора копирования, который скопирует объект, а далее, при раскрутке стека вызовется деструктор
В этом, частном, примере сработает NRVO, и все будет не так как Вы описали.
Для C++11, как Вы правильно заметили, это тоже будет несколько отличаться при наличии move ctor
Никаких сказок. Кто-то может, кто-то нет. А тот кто может — тоже ошибается и это будет справедливо как для capture all lambds, так и для non-captured lambds(по умолчвнию). Просто ошибки будут разного характера. В комитете по стандартизации C++ обсуждался вопрос дефолтного захвата переменных([=] по дефолту) и в результате решили от этого отказаться. Т.е. поддержать это можно уже сейчас, но это выльется в проблемы связанные с this и прочими указателями. К тому же выгода от подобного, лично для меня, выглядит весьма сомнительной.
Я могу сказать Вам тоже самое. Если нужно продлить жизнь переменной нужно передавать её копию и никакой GC не нужен. Указатели-же. должны контролироваться программистом или должны быть обернуты в shared_ptr, и проблемы с ними будут решены.
Я не говорю уж о таких маразмах, как этот, например
В чем здесь маразм, в том, что автор по незнанию наткнулся на проблему вызванную ограничением языка? Именно поэтому в описании lambda, в стандарте, this выделен отдельно, т.к. трактовать его стоит особым образом.
То, о чем говорите Вы справедливо для this и не справедливо для остальной части языка.
Я считаю, что это заявление, которое проскальзывает в каждом посте есть попытка выдать желаемое за действительное. Я бы сказал по другому: QML должен стать очень гибким и простым средством разработки. Сейчас он сырой, очень сырой. И когда дело доходит до сложной логики, то доходит до таких танцев с бубном, что «сложный» C++ нервно курит в стороне.
Поясню: к примеру, попробуйте добавить к примеру выше, анимацию перемешивания элементов, когда вы делаете drop сохранив, при этом, функционал Flickable части GridView. Будет очень весело, да вот только сделать это надежно,невозможно с QtQuick 1.1.
Отдельного внимания заслуживают MouseArea, которые не умеют игнорировать события, для того, чтобы нижележащие элементы могли их обработать. Эта особенность раскрасит ваши серые будни, т.к. вам придется выдумывать недюжинные способы, чтобы это обойти.
Да и по мелочам там всякого хватает…
При этом, я не агитирую против QML, наоборот, это замечательная технология. Просто нужно будь в курсе, что многие вещи придется делать через ж… или писать свой элемент на C++ с последующим его экспортированием в QML(наличие такой возможности есть несомненный плюс QML)
Комментарий размещен скорее для читателей, а не автора, т.к. я уверен, что автор и без моего комментария это знает.
P.S.
лучше манипулировать свойством preventStealing из MouseArea это позволит сохранить возможность прокрутки колесом.
По поводу религиозной части: в религии выход из сансары существует, и он может быть найден\получен\заслужен при жизни, поэтому не стоит откладывать на следующую жизнь :)
Не хочется ходить по ссылке, чтобы быстро понять о чем пойдет речь. Спасибо!
Прикольно, не знал, что так можно. Я просто вставлял отсканенные подписи, не забивая голову заказчику всякой ерундой типо актов.
В этом, частном, примере сработает NRVO, и все будет не так как Вы описали.
Для C++11, как Вы правильно заметили, это тоже будет несколько отличаться при наличии move ctor
Я могу сказать Вам тоже самое. Если нужно продлить жизнь переменной нужно передавать её копию и никакой GC не нужен. Указатели-же. должны контролироваться программистом или должны быть обернуты в shared_ptr, и проблемы с ними будут решены.
В чем здесь маразм, в том, что автор по незнанию наткнулся на проблему вызванную ограничением языка? Именно поэтому в описании lambda, в стандарте, this выделен отдельно, т.к. трактовать его стоит особым образом.
То, о чем говорите Вы справедливо для this и не справедливо для остальной части языка.