Как стать автором
Обновить

Комментарии 35

1. Топик про язык описания пользовательского интерфейса для Qt.
2. В профиле автора значится «разработчик qutIM».
3. Скриншоты очень напоминают контакт-лист мессенджера.

Так это что, концепты нового интерфейса для qutIM? :)
Ну пока да, экспериментирую с внешним видом.
Отличный пост.
Сравнивая с XAML увидел в Qt лаконичность и красоту форматирования.
А с XUL сравнивать доводилося?
Читается легко, конечный результат великолепен. Спасибо!
Ну, во-первых, спасибо. Очень интересно, хотя многое непонятно (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-программа потащит за собой в память либы, которые там будут висеть. Я не говорю, что QML и Declarative Interface — suxx, мне наоборот нравится подобный подход, однако у него (как и у любого другого) — свои плюсы и минусы.

P.S.: не кормите тролля, у егоринска — 190 кармы скоро будет.
*минус 190
ссылка на программу — как раз вариант, когда никто ничего больше не потащит, программа больше ничего не требует.

есть минусы и есть плюсы естественно и любой инструмент нужно применять с умом и к месту. Просто очень надоел стереотип, что если Qt, то
1. это только гуи
2. очень много будет занимать места
3. очень медленно будет работать и отжирать памяти
4. ряжело портировать под новую архитектуру, использовать можно только на уже портированых

первые три стереотипа я надеюсь опроверг в предыдущем комменте фактами
последний могу опровергнуть аргументом, что я портировал на 2 новые архитектуры (PPC405, SH4).

1. Ну насчет первого понятно, люди только гуй и видят.
2. В Виндовсе приходится с собой все либы Qt таскать, поэтому инсталяторы да, занимают чуть-чуть больше, хотя Qt оч хорошо архиваторами ужимается
3. Вот этого никогда не понимал, народ ведь часто даже и не догадывается, что Qt софт юзает, в том числе и потому, что работает он быстро.
4. Покажите мне тролля, который это сказал О.о, я таких в дикой природе не встречал. Qt даже под Haiku портировали
я говорю, что это стереотипы, которые правдой не являются…

2. Не всегда нужно, например статическая линковка (LGPL не запрещает этого делать, я уже писал об этом. В самом трактате я не нашел строчки, запрещающей это делать).
3. Это стереотип разработчиков, как и все остальные. Пользователю вообще пофиг на чем это все пишется.
4. Троли не распространяют неверные слухи о своих продуктах, этот стереотип встретил при работе с партнерами.
2. Только с ней все плагины отвалятся.
4. Я про форумных троллей))))
2. ну придется их тоже в код включать :-), все от задачи зависит конечно :-)
2. ААААА, ну встречал, думаю тяжело будет найти. Но поверь, народ конфузится (обычно также конфузится словами Toolchain, rootstrap, bootstrap) :-)
Ну потащит, и что? :). За последние 10 лет в техподдержку Radmin не обратился ни один (!!!) человек с вопросами об используемой памяти. Софт используется на миллионах end user компьютерах. По-моему память никого не волнует до тех пор, пока она не течет :(. А если она течет, то сколько программа ее занимала первоначально вообщем-то уже не важно.
Не забывайте про embedded устройства. Там памяти очень мало, а Qt и qml там работают. Поэтому минимизировать потребление памяти смысл есть.
Вы лукавите.
«2,5 метра» это пожатая UPXом, и это не то же самое, что 2.5 мб вышедших из-под компилятора :\ Не буду касаться темы плюсов и минусов упакованных ЕХЕшников, но в результате распаковки получаем 6 мб.
И судя по динамически-линкуемой версии (распакованный размер — 397кб) — бОльшая часть статического бинарника это таки Qt.

А зачем Вам UPX? ;) Обычно так поступают те, кто хочет придать своей программе мнимой компактности. Но вроде Вас не страшат оверхеды от Qt… Лучше бы Вы их сжимали LZMA-архиватором (7-zip или инсталлятор).
плюс за внимательность :-) Да действительно пожато UPX'ом.

UPX не придает мнимой компактности, он действительно программу делает компактной. И так как узкое место при запуске приложения — скорость чтения с диска, программа также стартует быстрее (скорость распаковки LZO алгоритмом быстрее чем скорость чтения с диска (даже с SSD) ). Тут явных целей не преследовалось, просто корпоративный стандарт такой. Конечно в случае с TXMuxer явной необходимости в этом не было, просто один из вариантов уменьшить трафик для скачивания.

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

Плюс к этому при запуске упакованной exe/dll она сперва полностью читается и распаковывается. Если же она неупакована, то страницы просто маппятся в адресное пространство, а физически подгружаются по мере надобности диспетчером кэша.

Компактность мнимая, т.к. в итоге получаем оверхед и её размер не становится меньше во время работы. А компактным становится файл программы.
Я бы сказал, юзайте файловые системы со сжатием, но к сожалению это не для Виндовса решение.
Зачем?
А затем, что быстрее будет информация с диска читаться, ибо в современных компьютерах самым узким местом является как раз жесткий диск, поэтому при хорошем сжатии файл в память будет быстрее считываться
А есть где-то сравнительные тесты этих файловых систем? (кстати, в виндовом NTFS тоже есть поддержка сжатия)
Что-то сомневаюсь, что они дают хорошее сжатие. С учетом того, что файлы могут читаться не последовательно. Соответственно нельзя сжать целиком, а только относительно небольшими кусками.
Вот и вопрос: стоят ли все эти телодвижения того?
> А использование Javascript и Web-технологий вообще в простой программе (да и программе вообще) — это не дурацкая идея — это новый уровень развития разработки ПО

Ну что за бред, я не против самого синтаксиса Яваскрипта или CSS (кстати, как верстальщик, могу сказать, и на первом, и на втором много неудобств в синтаксисе, а уж банальное вертикальное выравнивание вообще без извратов не сделаешь, они все же для оформления научных текстов и документации придумывались, а не для рисования интерфейсов). Я против их ужасной неоптимизированности. Помножьте это на уровень среднестатистического разработчика (который о производительности не думает) — получите наше ужасное будущее.

Этот QML придуман, чтобы можно было привлечь в качестве разработчиков побольше индусов (проще же), а мне потом пользоваться может придется тем что они наваяют. Я раньше не очень хорошо относился к подвижкам по привлечению индусов со стороны МС в виде всяких Visual*, но до Qt им далекою надо признать.

Снижение уровня знаний разработчиков — вот что нас ждет. На HTML любой школьник писать умеет, вот они и будут теперь писать программы.
помоему, Вы описали преимущества нового подхода по разработке кода как недостаток.
Я считаю, что если нужно сделать приложения А и есть два подхода:
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%. Он огорчался, а я порадовался — чем больше будет таких сайтов, тем больше внимания будут уделять отзывчивости интерфейса, скорости запуска и работы программы, и борьбе с флешем.
Чувак, да ты успокойся(с)
Никто не требует на qmlе организовывать обработку данных, хотя она теоретически возможна, у вас в руках вся мощь С++ и делайте что хотите, а для qml предоставляйте готовые модели. Яваскрипт там прежде всего используется для управления, а не обработки. А затраты на вызов функции, по сравнению со временем её исполнения ничтожны
Зависит исключительно от того, что вы там запрограммируете, если не увлекаться, то всё будет работать быстро.
Я против такого подхода, писать десктопные программы на неоптимизированном (оптимизированный = компилируемый и без hash table lookups для каждой переменной) яваскрипте — верх лентяйства.
А мне неинтересно мнение безмозглых троллей
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории