похоже такую штуку можно приделать к любой камере, главное софт такой сделать, чтоб это потом нормально развернул.
Жду китайские поделки для своего Canon D500 (паралельно ща полажу по вебу, мож уже сделали давно :-) )
Ну там и так полноценное Debian окружение, а портированые приложения немного изменяются лишь для того, чтоб удобно было пальцами на них тыкать (хилдонизация называется это :-) )
а еще под Mac/Linux/Windows/Linux Embedded и уже назревает проект lighthouse -http://qt.gitorious.org/+qt-developers/qt/lighthouse, который позволит использовать кути приолжения для веба (наподобие флеш плеера) и портироватся практически на любую платформу, включая Android(интузиасты уже начали этот проект)
Однозначно кодить выгоднее на Qt с точки зрения разработчика, один раз написали и захватил целый сегмент целевой.
2. ну придется их тоже в код включать :-), все от задачи зависит конечно :-)
2. ААААА, ну встречал, думаю тяжело будет найти. Но поверь, народ конфузится (обычно также конфузится словами Toolchain, rootstrap, bootstrap) :-)
помоему, Вы описали преимущества нового подхода по разработке кода как недостаток.
Я считаю, что если нужно сделать приложения А и есть два подхода:
1. Высококвалифицированный специалист с вагоном знаний и время на разработку равное N-часов.
2. Посредственный кодер и время на разработку N/M (где M>1),
То я, как архитектор проекта, выберу подход 2. И мне все равно, если оно будет работать в 2 раза медленнее (в ряде задач это совсем не важно, а в некоторых случаях и незаметно). Я с намного меньшими трудо и время затратами решу задачу. Это главное. Естественно, если проект требует высококй производительности (встраиваемые и мобильные устройства например) — это совсем другой случай (из личного опыта — таких программ немного).
А Пользовательский интерфейс «среднестатистической» программы не требует высокой оптимизации и производительности. Именно это позволило Adobe Air существовать вообще. Именно это позволило создать WebOs и Google Chrome OS.
мыслите масштабней, по вашему получается, что разработчик на АСМе должен рассуждать так: «Наплодили тут языков программрования высокого уровня, и никто об оптимизации и производительности не заботится».
А вы вот заморачиваетесь на выборе компилятора, когда пишете на С или С++? А вот с вашим подходом — это должна быть задача номер 1. Код по размеру, оптимизации и производительности очень сильно отличается.
плюс за внимательность :-) Да действительно пожато UPX'ом.
UPX не придает мнимой компактности, он действительно программу делает компактной. И так как узкое место при запуске приложения — скорость чтения с диска, программа также стартует быстрее (скорость распаковки LZO алгоритмом быстрее чем скорость чтения с диска (даже с SSD) ). Тут явных целей не преследовалось, просто корпоративный стандарт такой. Конечно в случае с TXMuxer явной необходимости в этом не было, просто один из вариантов уменьшить трафик для скачивания.
6 метров — это выросла программка, первые варианты несжатые были по 3, видимо чего-то подцепили еще чего-то, что раньше не использовали из Qt и оно включилось в общий код.
я говорю, что это стереотипы, которые правдой не являются…
2. Не всегда нужно, например статическая линковка (LGPL не запрещает этого делать, я уже писал об этом. В самом трактате я не нашел строчки, запрещающей это делать).
3. Это стереотип разработчиков, как и все остальные. Пользователю вообще пофиг на чем это все пишется.
4. Троли не распространяют неверные слухи о своих продуктах, этот стереотип встретил при работе с партнерами.
еде одно доказательство того, что Symbian никто хоронить не будет. Сделали бы централизованый магазин приложений для Symbian и возможность туда выкладывать приложения для разработчиков-индивидуалов и думаю бы рост популярности этой платформы бы ускорился.
чтоб небыло лишних вопросов — на Ovi-Store индивидуальные разработчики не могут ложить свой софт, только конторы.
ссылка на программу — как раз вариант, когда никто ничего больше не потащит, программа больше ничего не требует.
есть минусы и есть плюсы естественно и любой инструмент нужно применять с умом и к месту. Просто очень надоел стереотип, что если Qt, то
1. это только гуи
2. очень много будет занимать места
3. очень медленно будет работать и отжирать памяти
4. ряжело портировать под новую архитектуру, использовать можно только на уже портированых
первые три стереотипа я надеюсь опроверг в предыдущем комменте фактами
последний могу опровергнуть аргументом, что я портировал на 2 новые архитектуры (PPC405, SH4).
Жду китайские поделки для своего Canon D500 (паралельно ща полажу по вебу, мож уже сделали давно :-) )
Однозначно кодить выгоднее на Qt с точки зрения разработчика, один раз написали и захватил целый сегмент целевой.
2. ААААА, ну встречал, думаю тяжело будет найти. Но поверь, народ конфузится (обычно также конфузится словами Toolchain, rootstrap, bootstrap) :-)
Я считаю, что если нужно сделать приложения А и есть два подхода:
1. Высококвалифицированный специалист с вагоном знаний и время на разработку равное N-часов.
2. Посредственный кодер и время на разработку N/M (где M>1),
То я, как архитектор проекта, выберу подход 2. И мне все равно, если оно будет работать в 2 раза медленнее (в ряде задач это совсем не важно, а в некоторых случаях и незаметно). Я с намного меньшими трудо и время затратами решу задачу. Это главное. Естественно, если проект требует высококй производительности (встраиваемые и мобильные устройства например) — это совсем другой случай (из личного опыта — таких программ немного).
А Пользовательский интерфейс «среднестатистической» программы не требует высокой оптимизации и производительности. Именно это позволило Adobe Air существовать вообще. Именно это позволило создать WebOs и Google Chrome OS.
мыслите масштабней, по вашему получается, что разработчик на АСМе должен рассуждать так: «Наплодили тут языков программрования высокого уровня, и никто об оптимизации и производительности не заботится».
А вы вот заморачиваетесь на выборе компилятора, когда пишете на С или С++? А вот с вашим подходом — это должна быть задача номер 1. Код по размеру, оптимизации и производительности очень сильно отличается.
UPX не придает мнимой компактности, он действительно программу делает компактной. И так как узкое место при запуске приложения — скорость чтения с диска, программа также стартует быстрее (скорость распаковки LZO алгоритмом быстрее чем скорость чтения с диска (даже с SSD) ). Тут явных целей не преследовалось, просто корпоративный стандарт такой. Конечно в случае с TXMuxer явной необходимости в этом не было, просто один из вариантов уменьшить трафик для скачивания.
6 метров — это выросла программка, первые варианты несжатые были по 3, видимо чего-то подцепили еще чего-то, что раньше не использовали из Qt и оно включилось в общий код.
2. Не всегда нужно, например статическая линковка (LGPL не запрещает этого делать, я уже писал об этом. В самом трактате я не нашел строчки, запрещающей это делать).
3. Это стереотип разработчиков, как и все остальные. Пользователю вообще пофиг на чем это все пишется.
4. Троли не распространяют неверные слухи о своих продуктах, этот стереотип встретил при работе с партнерами.
чтоб небыло лишних вопросов — на Ovi-Store индивидуальные разработчики не могут ложить свой софт, только конторы.
есть минусы и есть плюсы естественно и любой инструмент нужно применять с умом и к месту. Просто очень надоел стереотип, что если Qt, то
1. это только гуи
2. очень много будет занимать места
3. очень медленно будет работать и отжирать памяти
4. ряжело портировать под новую архитектуру, использовать можно только на уже портированых
первые три стереотипа я надеюсь опроверг в предыдущем комменте фактами
последний могу опровергнуть аргументом, что я портировал на 2 новые архитектуры (PPC405, SH4).