Комментарии 35
1. Топик про язык описания пользовательского интерфейса для Qt.
2. В профиле автора значится «разработчик qutIM».
3. Скриншоты очень напоминают контакт-лист мессенджера.
Так это что, концепты нового интерфейса для qutIM? :)
2. В профиле автора значится «разработчик qutIM».
3. Скриншоты очень напоминают контакт-лист мессенджера.
Так это что, концепты нового интерфейса для qutIM? :)
Отличный пост.
Сравнивая с XAML увидел в Qt лаконичность и красоту форматирования.
Сравнивая с XAML увидел в Qt лаконичность и красоту форматирования.
Читается легко, конечный результат великолепен. Спасибо!
Ну, во-первых, спасибо. Очень интересно, хотя многое непонятно (aka непривычно).
> Как мы видим, доступ к элементам модели осуществляется очень просто.
Ничего не вижу. :) Где именно там доступ к модели?
> Как мы видим, доступ к элементам модели осуществляется очень просто.
Объект создаётся по имени модуля в котором он объявлен?
> Как мы видим, доступ к элементам модели осуществляется очень просто.
Ничего не вижу. :) Где именно там доступ к модели?
> Как мы видим, доступ к элементам модели осуществляется очень просто.
Объект создаётся по имени модуля в котором он объявлен?
В какой стадии находится проект QT QML? Это еще бета версия?
Мне одному кажется, что использовать Javascript в простой программе — дурацкая идея? Получится тяжелый бинарник, и программа будет тормозить.
С использованием QT программа уже лёгкой не будет, так что не страшно.
сколько же можно ломать стереотипы?
вот вам пример программы написанной, на Qt www.smlabs.net/tsmuxer.html
скачайте версию, которая не требует наличия Qt. 2,5 метра — это не легкая ???
По поводу скорости и производительности, вот тут www.smlabs.net/client.html в самом низу страницы видео-пример как Qt приложение работает на очень очень маломощном устройстве (PowerPC 405, 200Мгц, 32 Оперативной памяти, в которых развернута файловая система с линуксом — RamFS, из этих 32 метров доступно около 20, а код в PPC405 занимает раза в два больше места, чем на обычной x86).
У кого есть Стрим-ТВ, тот узнал конечно интерфейс.
Обратите внимание, что декодируется видео (конечно аппаратным декодером, но при этом задействован и центральный процессор (30-40 процентов)). Также обратите внимание на прозрачность, столбик с элементами имеет уменьшающуюся прозрачность, тоже большая нагрузка.
А использование Javascript и Web-технологий вообще в простой программе (да и программе вообще) — это не дурацкая идея — это новый уровень развития разработки ПО, и Qt делают ставку на это направление (WebKit, QML, Qscript). Смысл в том, что это позволяет отделить логику от отображения (это очень давно уже делают, как пример: MFC — одно из самых старых решений в этом плане), QML и Declarative Interface — это как раз эволюция в этом направлении.
вот вам пример программы написанной, на Qt www.smlabs.net/tsmuxer.html
скачайте версию, которая не требует наличия Qt. 2,5 метра — это не легкая ???
По поводу скорости и производительности, вот тут www.smlabs.net/client.html в самом низу страницы видео-пример как Qt приложение работает на очень очень маломощном устройстве (PowerPC 405, 200Мгц, 32 Оперативной памяти, в которых развернута файловая система с линуксом — RamFS, из этих 32 метров доступно около 20, а код в PPC405 занимает раза в два больше места, чем на обычной x86).
У кого есть Стрим-ТВ, тот узнал конечно интерфейс.
Обратите внимание, что декодируется видео (конечно аппаратным декодером, но при этом задействован и центральный процессор (30-40 процентов)). Также обратите внимание на прозрачность, столбик с элементами имеет уменьшающуюся прозрачность, тоже большая нагрузка.
А использование Javascript и Web-технологий вообще в простой программе (да и программе вообще) — это не дурацкая идея — это новый уровень развития разработки ПО, и Qt делают ставку на это направление (WebKit, QML, Qscript). Смысл в том, что это позволяет отделить логику от отображения (это очень давно уже делают, как пример: MFC — одно из самых старых решений в этом плане), QML и Declarative Interface — это как раз эволюция в этом направлении.
В любом случае QT-программа потащит за собой в память либы, которые там будут висеть. Я не говорю, что QML и Declarative Interface — suxx, мне наоборот нравится подобный подход, однако у него (как и у любого другого) — свои плюсы и минусы.
P.S.: не кормите тролля, у егоринска — 190 кармы скоро будет.
P.S.: не кормите тролля, у егоринска — 190 кармы скоро будет.
*минус 190
ссылка на программу — как раз вариант, когда никто ничего больше не потащит, программа больше ничего не требует.
есть минусы и есть плюсы естественно и любой инструмент нужно применять с умом и к месту. Просто очень надоел стереотип, что если Qt, то
1. это только гуи
2. очень много будет занимать места
3. очень медленно будет работать и отжирать памяти
4. ряжело портировать под новую архитектуру, использовать можно только на уже портированых
первые три стереотипа я надеюсь опроверг в предыдущем комменте фактами
последний могу опровергнуть аргументом, что я портировал на 2 новые архитектуры (PPC405, SH4).
есть минусы и есть плюсы естественно и любой инструмент нужно применять с умом и к месту. Просто очень надоел стереотип, что если Qt, то
1. это только гуи
2. очень много будет занимать места
3. очень медленно будет работать и отжирать памяти
4. ряжело портировать под новую архитектуру, использовать можно только на уже портированых
первые три стереотипа я надеюсь опроверг в предыдущем комменте фактами
последний могу опровергнуть аргументом, что я портировал на 2 новые архитектуры (PPC405, SH4).
1. Ну насчет первого понятно, люди только гуй и видят.
2. В Виндовсе приходится с собой все либы Qt таскать, поэтому инсталяторы да, занимают чуть-чуть больше, хотя Qt оч хорошо архиваторами ужимается
3. Вот этого никогда не понимал, народ ведь часто даже и не догадывается, что Qt софт юзает, в том числе и потому, что работает он быстро.
4. Покажите мне тролля, который это сказал О.о, я таких в дикой природе не встречал. Qt даже под Haiku портировали
2. В Виндовсе приходится с собой все либы Qt таскать, поэтому инсталяторы да, занимают чуть-чуть больше, хотя Qt оч хорошо архиваторами ужимается
3. Вот этого никогда не понимал, народ ведь часто даже и не догадывается, что Qt софт юзает, в том числе и потому, что работает он быстро.
4. Покажите мне тролля, который это сказал О.о, я таких в дикой природе не встречал. Qt даже под Haiku портировали
я говорю, что это стереотипы, которые правдой не являются…
2. Не всегда нужно, например статическая линковка (LGPL не запрещает этого делать, я уже писал об этом. В самом трактате я не нашел строчки, запрещающей это делать).
3. Это стереотип разработчиков, как и все остальные. Пользователю вообще пофиг на чем это все пишется.
4. Троли не распространяют неверные слухи о своих продуктах, этот стереотип встретил при работе с партнерами.
2. Не всегда нужно, например статическая линковка (LGPL не запрещает этого делать, я уже писал об этом. В самом трактате я не нашел строчки, запрещающей это делать).
3. Это стереотип разработчиков, как и все остальные. Пользователю вообще пофиг на чем это все пишется.
4. Троли не распространяют неверные слухи о своих продуктах, этот стереотип встретил при работе с партнерами.
Ну потащит, и что? :). За последние 10 лет в техподдержку Radmin не обратился ни один (!!!) человек с вопросами об используемой памяти. Софт используется на миллионах end user компьютерах. По-моему память никого не волнует до тех пор, пока она не течет :(. А если она течет, то сколько программа ее занимала первоначально вообщем-то уже не важно.
Вы лукавите.
«2,5 метра» это пожатая UPXом, и это не то же самое, что 2.5 мб вышедших из-под компилятора :\ Не буду касаться темы плюсов и минусов упакованных ЕХЕшников, но в результате распаковки получаем 6 мб.
И судя по динамически-линкуемой версии (распакованный размер — 397кб) — бОльшая часть статического бинарника это таки Qt.
А зачем Вам UPX? ;) Обычно так поступают те, кто хочет придать своей программе мнимой компактности. Но вроде Вас не страшат оверхеды от Qt… Лучше бы Вы их сжимали LZMA-архиватором (7-zip или инсталлятор).
«2,5 метра» это пожатая UPXом, и это не то же самое, что 2.5 мб вышедших из-под компилятора :\ Не буду касаться темы плюсов и минусов упакованных ЕХЕшников, но в результате распаковки получаем 6 мб.
И судя по динамически-линкуемой версии (распакованный размер — 397кб) — бОльшая часть статического бинарника это таки Qt.
А зачем Вам UPX? ;) Обычно так поступают те, кто хочет придать своей программе мнимой компактности. Но вроде Вас не страшат оверхеды от Qt… Лучше бы Вы их сжимали LZMA-архиватором (7-zip или инсталлятор).
плюс за внимательность :-) Да действительно пожато UPX'ом.
UPX не придает мнимой компактности, он действительно программу делает компактной. И так как узкое место при запуске приложения — скорость чтения с диска, программа также стартует быстрее (скорость распаковки LZO алгоритмом быстрее чем скорость чтения с диска (даже с SSD) ). Тут явных целей не преследовалось, просто корпоративный стандарт такой. Конечно в случае с TXMuxer явной необходимости в этом не было, просто один из вариантов уменьшить трафик для скачивания.
6 метров — это выросла программка, первые варианты несжатые были по 3, видимо чего-то подцепили еще чего-то, что раньше не использовали из Qt и оно включилось в общий код.
UPX не придает мнимой компактности, он действительно программу делает компактной. И так как узкое место при запуске приложения — скорость чтения с диска, программа также стартует быстрее (скорость распаковки LZO алгоритмом быстрее чем скорость чтения с диска (даже с SSD) ). Тут явных целей не преследовалось, просто корпоративный стандарт такой. Конечно в случае с TXMuxer явной необходимости в этом не было, просто один из вариантов уменьшить трафик для скачивания.
6 метров — это выросла программка, первые варианты несжатые были по 3, видимо чего-то подцепили еще чего-то, что раньше не использовали из Qt и оно включилось в общий код.
Да, может упакованные данные быстрее читаются с диска, только вот несжатые страницы ОС может выбросить и подгрузить с ехе-шника, а распакованные только через своп.
Плюс к этому при запуске упакованной exe/dll она сперва полностью читается и распаковывается. Если же она неупакована, то страницы просто маппятся в адресное пространство, а физически подгружаются по мере надобности диспетчером кэша.
Компактность мнимая, т.к. в итоге получаем оверхед и её размер не становится меньше во время работы. А компактным становится файл программы.
Плюс к этому при запуске упакованной exe/dll она сперва полностью читается и распаковывается. Если же она неупакована, то страницы просто маппятся в адресное пространство, а физически подгружаются по мере надобности диспетчером кэша.
Компактность мнимая, т.к. в итоге получаем оверхед и её размер не становится меньше во время работы. А компактным становится файл программы.
Я бы сказал, юзайте файловые системы со сжатием, но к сожалению это не для Виндовса решение.
Зачем?
А затем, что быстрее будет информация с диска читаться, ибо в современных компьютерах самым узким местом является как раз жесткий диск, поэтому при хорошем сжатии файл в память будет быстрее считываться
А есть где-то сравнительные тесты этих файловых систем? (кстати, в виндовом NTFS тоже есть поддержка сжатия)
Что-то сомневаюсь, что они дают хорошее сжатие. С учетом того, что файлы могут читаться не последовательно. Соответственно нельзя сжать целиком, а только относительно небольшими кусками.
Вот и вопрос: стоят ли все эти телодвижения того?
Что-то сомневаюсь, что они дают хорошее сжатие. С учетом того, что файлы могут читаться не последовательно. Соответственно нельзя сжать целиком, а только относительно небольшими кусками.
Вот и вопрос: стоят ли все эти телодвижения того?
> А использование Javascript и Web-технологий вообще в простой программе (да и программе вообще) — это не дурацкая идея — это новый уровень развития разработки ПО
Ну что за бред, я не против самого синтаксиса Яваскрипта или CSS (кстати, как верстальщик, могу сказать, и на первом, и на втором много неудобств в синтаксисе, а уж банальное вертикальное выравнивание вообще без извратов не сделаешь, они все же для оформления научных текстов и документации придумывались, а не для рисования интерфейсов). Я против их ужасной неоптимизированности. Помножьте это на уровень среднестатистического разработчика (который о производительности не думает) — получите наше ужасное будущее.
Этот QML придуман, чтобы можно было привлечь в качестве разработчиков побольше индусов (проще же), а мне потом пользоваться может придется тем что они наваяют. Я раньше не очень хорошо относился к подвижкам по привлечению индусов со стороны МС в виде всяких Visual*, но до Qt им далекою надо признать.
Снижение уровня знаний разработчиков — вот что нас ждет. На HTML любой школьник писать умеет, вот они и будут теперь писать программы.
Ну что за бред, я не против самого синтаксиса Яваскрипта или CSS (кстати, как верстальщик, могу сказать, и на первом, и на втором много неудобств в синтаксисе, а уж банальное вертикальное выравнивание вообще без извратов не сделаешь, они все же для оформления научных текстов и документации придумывались, а не для рисования интерфейсов). Я против их ужасной неоптимизированности. Помножьте это на уровень среднестатистического разработчика (который о производительности не думает) — получите наше ужасное будущее.
Этот QML придуман, чтобы можно было привлечь в качестве разработчиков побольше индусов (проще же), а мне потом пользоваться может придется тем что они наваяют. Я раньше не очень хорошо относился к подвижкам по привлечению индусов со стороны МС в виде всяких Visual*, но до Qt им далекою надо признать.
Снижение уровня знаний разработчиков — вот что нас ждет. На HTML любой школьник писать умеет, вот они и будут теперь писать программы.
помоему, Вы описали преимущества нового подхода по разработке кода как недостаток.
Я считаю, что если нужно сделать приложения А и есть два подхода:
1. Высококвалифицированный специалист с вагоном знаний и время на разработку равное N-часов.
2. Посредственный кодер и время на разработку N/M (где M>1),
То я, как архитектор проекта, выберу подход 2. И мне все равно, если оно будет работать в 2 раза медленнее (в ряде задач это совсем не важно, а в некоторых случаях и незаметно). Я с намного меньшими трудо и время затратами решу задачу. Это главное. Естественно, если проект требует высококй производительности (встраиваемые и мобильные устройства например) — это совсем другой случай (из личного опыта — таких программ немного).
А Пользовательский интерфейс «среднестатистической» программы не требует высокой оптимизации и производительности. Именно это позволило Adobe Air существовать вообще. Именно это позволило создать WebOs и Google Chrome OS.
мыслите масштабней, по вашему получается, что разработчик на АСМе должен рассуждать так: «Наплодили тут языков программрования высокого уровня, и никто об оптимизации и производительности не заботится».
А вы вот заморачиваетесь на выборе компилятора, когда пишете на С или С++? А вот с вашим подходом — это должна быть задача номер 1. Код по размеру, оптимизации и производительности очень сильно отличается.
Я считаю, что если нужно сделать приложения А и есть два подхода:
1. Высококвалифицированный специалист с вагоном знаний и время на разработку равное N-часов.
2. Посредственный кодер и время на разработку N/M (где M>1),
То я, как архитектор проекта, выберу подход 2. И мне все равно, если оно будет работать в 2 раза медленнее (в ряде задач это совсем не важно, а в некоторых случаях и незаметно). Я с намного меньшими трудо и время затратами решу задачу. Это главное. Естественно, если проект требует высококй производительности (встраиваемые и мобильные устройства например) — это совсем другой случай (из личного опыта — таких программ немного).
А Пользовательский интерфейс «среднестатистической» программы не требует высокой оптимизации и производительности. Именно это позволило Adobe Air существовать вообще. Именно это позволило создать WebOs и Google Chrome OS.
мыслите масштабней, по вашему получается, что разработчик на АСМе должен рассуждать так: «Наплодили тут языков программрования высокого уровня, и никто об оптимизации и производительности не заботится».
А вы вот заморачиваетесь на выборе компилятора, когда пишете на С или С++? А вот с вашим подходом — это должна быть задача номер 1. Код по размеру, оптимизации и производительности очень сильно отличается.
Это понятно, но тут есть еще такая сторона, как разработчик технологии (того же Air или QML), от которого многое зависит, те же самые оптимизации, и например, выдача предупреждений при использовании неэффективных функций.
А вообще, да, все упирается в конечном итоге в деньги.
> А Пользовательский интерфейс «среднестатистической» программы не требует высокой оптимизации и производительности. Именно это позволило Adobe Air существовать вообще. Именно это позволило создать WebOs и Google Chrome OS.
Ага, и Убунту. Слава богу, пока таких программ немного и можно обходиться без них.
Тут кто-то на Хабре возмущался по поводу флеш-баннеров на сайтах, которые грузят процессор под 100%. Он огорчался, а я порадовался — чем больше будет таких сайтов, тем больше внимания будут уделять отзывчивости интерфейса, скорости запуска и работы программы, и борьбе с флешем.
А вообще, да, все упирается в конечном итоге в деньги.
> А Пользовательский интерфейс «среднестатистической» программы не требует высокой оптимизации и производительности. Именно это позволило Adobe Air существовать вообще. Именно это позволило создать WebOs и Google Chrome OS.
Ага, и Убунту. Слава богу, пока таких программ немного и можно обходиться без них.
Тут кто-то на Хабре возмущался по поводу флеш-баннеров на сайтах, которые грузят процессор под 100%. Он огорчался, а я порадовался — чем больше будет таких сайтов, тем больше внимания будут уделять отзывчивости интерфейса, скорости запуска и работы программы, и борьбе с флешем.
Чувак, да ты успокойся(с)
Никто не требует на qmlе организовывать обработку данных, хотя она теоретически возможна, у вас в руках вся мощь С++ и делайте что хотите, а для qml предоставляйте готовые модели. Яваскрипт там прежде всего используется для управления, а не обработки. А затраты на вызов функции, по сравнению со временем её исполнения ничтожны
Никто не требует на qmlе организовывать обработку данных, хотя она теоретически возможна, у вас в руках вся мощь С++ и делайте что хотите, а для qml предоставляйте готовые модели. Яваскрипт там прежде всего используется для управления, а не обработки. А затраты на вызов функции, по сравнению со временем её исполнения ничтожны
Зависит исключительно от того, что вы там запрограммируете, если не увлекаться, то всё будет работать быстро.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работаем с моделями в QML