Здравствуйте!
Задача: разработать панель оператора 320х240.
За основу выбрана отладочная плата Cirrus Logic EDB9315A.
Основная сложность в том, что программировать GUI будут программеры заказчика. Надо создать для них примеры и т.д.
Начал я с QT, но поговорив с Trolltech'ом, узнал, что лицензирование дорого (от Э7500 со средами разработки) и запутанно (пока на разобрался до конца).
Linux использовать придеться (и хочется!), иначе потянутся другие сложности.
Вопрос: что посоветуете для графики?
P.S. Если есть проблемы с заливкой платы, см. сюда arm.cirrus.com/docs/2.6/x160.html
Полная версия этой страницы: Графика для Linux.
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Linux
Цитата(Logout @ May 24 2008, 13:06) 
Здравствуйте!
Задача: разработать панель оператора 320х240.
За основу выбрана отладочная плата Cirrus Logic EDB9315A.
Основная сложность в том, что программировать GUI будут программеры заказчика. Надо создать для них примеры и т.д.
Начал я с QT, но поговорив с Trolltech'ом, узнал, что лицензирование дорого (от Э7500 со средами разработки) и запутанно (пока на разобрался до конца).
Linux использовать придеться (и хочется!), иначе потянутся другие сложности.
Вопрос: что посоветуете для графики?
P.S. Если есть проблемы с заливкой платы, см. сюда arm.cirrus.com/docs/2.6/x160.html
Задача: разработать панель оператора 320х240.
За основу выбрана отладочная плата Cirrus Logic EDB9315A.
Основная сложность в том, что программировать GUI будут программеры заказчика. Надо создать для них примеры и т.д.
Начал я с QT, но поговорив с Trolltech'ом, узнал, что лицензирование дорого (от Э7500 со средами разработки) и запутанно (пока на разобрался до конца).
Linux использовать придеться (и хочется!), иначе потянутся другие сложности.
Вопрос: что посоветуете для графики?
P.S. Если есть проблемы с заливкой платы, см. сюда arm.cirrus.com/docs/2.6/x160.html
У Trolltech есть старые версии open-source qtopia (например, qtopia-free-2.1.0), которые идут не по dual-license, а по обычной GNU GPL лицензии. Поэтому, если заказчик программирует для себя, или открытие исходников не является для него проблемой, то можете смело ставить эту версию QTopia и использовать ее для коммерческого проекта.
Если открытие исходников не входит в планы, то похоже из бесплатного кроме как FLTK особых вариантов нет.
qt не рекомендую, лучшее(из бесплатного) чем я пользуюсь и мне нравится это wxWidgets к тому же к нему есть опен сорс редактор форм, вобщем вот ссылки:
http://wxwidgets.org
http://wxformbuilder.org/
вот скрины готовых интерфейсов: http://www.wxwidgets.org/about/screensh.htm
http://wxwidgets.org
http://wxformbuilder.org/
вот скрины готовых интерфейсов: http://www.wxwidgets.org/about/screensh.htm
Цитата(Nitrotoluol @ May 24 2008, 15:31)
qt не рекомендую, лучшее(из бесплатного) чем я пользуюсь и мне нравится это wxWidgets к тому же к нему есть опен сорс редактор форм, вобщем вот ссылки:
http://wxwidgets.org
http://wxformbuilder.org/
вот скрины готовых интерфейсов: http://www.wxwidgets.org/about/screensh.htm
http://wxwidgets.org
http://wxformbuilder.org/
вот скрины готовых интерфейсов: http://www.wxwidgets.org/about/screensh.htm
А можно узнать причины неприязни к QT?
Или это из серии - "я знаю только Delphi, поэтому Delphi круче"?
wxWidgets вообще-то не есть GUI.
Это некий довольно убогий фреймворк с кучей далеко не embedded функций тесно привязанный к PC платформе.
Смотрите сами: http://docs.wxwidgets.org/stable/wx_functions.html#functions
Шансы поставить его на голую платформу близки к нулю.
Qt - тот же гемор. Это тоже фреймворк, с кучей не относящихся к GUI функций.
Плюс дополнительный гемор - не прямая компиляция. Если Wiki не врет , то там нужно предварительно пропускать исходники через Meta Object Compiler.
В переводе это типичный obfuscator. Т.е. портирование затруднено до предела.
Из опыта работы с Qt на отладочной борде с i.MX27 его так называемая embedded версия требует не менее 30 Мег RAM-а
Это некий довольно убогий фреймворк с кучей далеко не embedded функций тесно привязанный к PC платформе.
Смотрите сами: http://docs.wxwidgets.org/stable/wx_functions.html#functions
Шансы поставить его на голую платформу близки к нулю.
Qt - тот же гемор. Это тоже фреймворк, с кучей не относящихся к GUI функций.
Плюс дополнительный гемор - не прямая компиляция. Если Wiki не врет , то там нужно предварительно пропускать исходники через Meta Object Compiler.
В переводе это типичный obfuscator. Т.е. портирование затруднено до предела.
Из опыта работы с Qt на отладочной борде с i.MX27 его так называемая embedded версия требует не менее 30 Мег RAM-а
Цитата(acex2 @ May 24 2008, 18:47)
А можно узнать причины неприязни к QT?
Или это из серии - "я знаю только Delphi, поэтому Delphi круче"?
Или это из серии - "я знаю только Delphi, поэтому Delphi круче"?
Цитата(acex2 @ May 24 2008, 18:17)
А можно узнать причины неприязни к QT?
Или это из серии - "я знаю только Delphi, поэтому Delphi круче"?
Или это из серии - "я знаю только Delphi, поэтому Delphi круче"?
да потому что он меня ничем не ограничивает, захочу продам, захочу выложу опенсорс, и ни в том ни в другом случае не выложу ни цента. я не теряю много времени на разработку интерфейса, а времена делфи для меня давно прошли, еще что неменее важно это удобство пользования.
Цитата(AlexandrY @ May 24 2008, 20:04)
wxWidgets вообще-то не есть GUI.
Это некий довольно убогий фреймворк с кучей далеко не embedded функций тесно привязанный к PC платформе.
Смотрите сами: http://docs.wxwidgets.org/stable/wx_functions.html#functions
Шансы поставить его на голую платформу близки к нулю.
Qt - тот же гемор. Это тоже фреймворк, с кучей не относящихся к GUI функций.
Плюс дополнительный гемор - не прямая компиляция. Если Wiki не врет , то там нужно предварительно пропускать исходники через Meta Object Compiler.
В переводе это типичный obfuscator. Т.е. портирование затруднено до предела.
Из опыта работы с Qt на отладочной борде с i.MX27 его так называемая embedded версия требует не менее 30 Мег RAM-а
Это некий довольно убогий фреймворк с кучей далеко не embedded функций тесно привязанный к PC платформе.
Смотрите сами: http://docs.wxwidgets.org/stable/wx_functions.html#functions
Шансы поставить его на голую платформу близки к нулю.
Qt - тот же гемор. Это тоже фреймворк, с кучей не относящихся к GUI функций.
Плюс дополнительный гемор - не прямая компиляция. Если Wiki не врет , то там нужно предварительно пропускать исходники через Meta Object Compiler.
В переводе это типичный obfuscator. Т.е. портирование затруднено до предела.
Из опыта работы с Qt на отладочной борде с i.MX27 его так называемая embedded версия требует не менее 30 Мег RAM-а
мда... довольно веселый ответ особенно еси учесть что(надеюсь вы понимаете английский):
"wxWidgets lets developers create applications for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more using one codebase. It can be used from languages such as C++, Python, Perl, and C#/.NET. Unlike other cross-platform toolkits, wxWidgets applications look and feel native. This is because wxWidgets uses the platform's own native controls rather than emulating them. It's also extensive, free, open-source, and mature."
далее идете и читаете вот это http://www.wxwidgets.org/about/datasheets/...etsEmbedded.pdf
и это http://www.wxwidgets.org/docs/embedded.htm
если это называется "тесно привязанный к PC" и "вообще-то не есть GUI" значит я испанский летчик... а насчет убогости... вы просто видать не писали интерфейсов на чистом ассемблере....
а вообще нужно сказать что на вкус и цвет фломастеры разные...
Цитата(Logout @ May 24 2008, 12:06)
Здравствуйте!
Задача: разработать панель оператора 320х240.
За основу выбрана отладочная плата Cirrus Logic EDB9315A.
Основная сложность в том, что программировать GUI будут программеры заказчика. Надо создать для них примеры и т.д.
Начал я с QT, но поговорив с Trolltech'ом, узнал, что лицензирование дорого (от Э7500 со средами разработки) и запутанно (пока на разобрался до конца).
Linux использовать придеться (и хочется!), иначе потянутся другие сложности.
Вопрос: что посоветуете для графики?
P.S. Если есть проблемы с заливкой платы, см. сюда arm.cirrus.com/docs/2.6/x160.html
Задача: разработать панель оператора 320х240.
За основу выбрана отладочная плата Cirrus Logic EDB9315A.
Основная сложность в том, что программировать GUI будут программеры заказчика. Надо создать для них примеры и т.д.
Начал я с QT, но поговорив с Trolltech'ом, узнал, что лицензирование дорого (от Э7500 со средами разработки) и запутанно (пока на разобрался до конца).
Linux использовать придеться (и хочется!), иначе потянутся другие сложности.
Вопрос: что посоветуете для графики?
P.S. Если есть проблемы с заливкой платы, см. сюда arm.cirrus.com/docs/2.6/x160.html
Вы можете выложить свой исходный код и Trolltech не попросит у Вас ни цента. Вряд ли кому-то будет особый зыск с GUI Вашего проекта... мало того, можете еще накатать пару статей в журналы, мол "программирование Qt под встроенные системы" с ссылками на свой проект. Ведь лицензия Qt обязывет раскрыть только код для...
www.fltk.org
Рекламой нам мозги кормить не надо, тем более такой не убедительной.
Можете показать что сами сделаи на wxwidgets?
И каким образом они к вам попали, в смысле получили вы их готовыми на чужом KIT-е или портировали сами.
Можете показать что сами сделаи на wxwidgets?
И каким образом они к вам попали, в смысле получили вы их готовыми на чужом KIT-е или портировали сами.
Цитата(Nitrotoluol @ May 24 2008, 23:27)
да потому что он меня ничем не ограничивает, захочу продам, захочу выложу опенсорс, и ни в том ни в другом случае не выложу ни цента. я не теряю много времени на разработку интерфейса, а времена делфи для меня давно прошли, еще что неменее важно это удобство пользования.
мда... довольно веселый ответ особенно еси учесть что(надеюсь вы понимаете английский):
"wxWidgets lets developers create applications for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more using one codebase. It can be used from languages such as C++, Python, Perl, and C#/.NET. Unlike other cross-platform toolkits, wxWidgets applications look and feel native. This is because wxWidgets uses the platform's own native controls rather than emulating them. It's also extensive, free, open-source, and mature."
далее идете и читаете вот это http://www.wxwidgets.org/about/datasheets/...etsEmbedded.pdf
и это http://www.wxwidgets.org/docs/embedded.htm
если это называется "тесно привязанный к PC" и "вообще-то не есть GUI" значит я испанский летчик... а насчет убогости... вы просто видать не писали интерфейсов на чистом ассемблере....
а вообще нужно сказать что на вкус и цвет фломастеры разные...
мда... довольно веселый ответ особенно еси учесть что(надеюсь вы понимаете английский):
"wxWidgets lets developers create applications for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more using one codebase. It can be used from languages such as C++, Python, Perl, and C#/.NET. Unlike other cross-platform toolkits, wxWidgets applications look and feel native. This is because wxWidgets uses the platform's own native controls rather than emulating them. It's also extensive, free, open-source, and mature."
далее идете и читаете вот это http://www.wxwidgets.org/about/datasheets/...etsEmbedded.pdf
и это http://www.wxwidgets.org/docs/embedded.htm
если это называется "тесно привязанный к PC" и "вообще-то не есть GUI" значит я испанский летчик... а насчет убогости... вы просто видать не писали интерфейсов на чистом ассемблере....
а вообще нужно сказать что на вкус и цвет фломастеры разные...
Замечательная дискуссия получается!
Настоящий индеец должен всё попробовать (не в смысле шмали, конечно), но не сразу.
По поводу wxwidgets...
У меня целевая система 64 MB RAM, 16 MB flash. Увеличитвать память затратно. Можно поставить диск на компакт-флэши, но крайне не желательно из-за суровых условий применения (нефтепромысел).
В связи с этим вопросы:
1. если применять wxwidgets, то какой порт - wxX11 или wxGTK?
2. будет ли X11 нормально работать на такой машине? Если ли порт X11 для EDB9315 или рецепт как его изготовить? Надо будет спросить на форуме Cirrus'a.
Настоящий индеец должен всё попробовать (не в смысле шмали, конечно), но не сразу.
По поводу wxwidgets...
У меня целевая система 64 MB RAM, 16 MB flash. Увеличитвать память затратно. Можно поставить диск на компакт-флэши, но крайне не желательно из-за суровых условий применения (нефтепромысел).
В связи с этим вопросы:
1. если применять wxwidgets, то какой порт - wxX11 или wxGTK?
2. будет ли X11 нормально работать на такой машине? Если ли порт X11 для EDB9315 или рецепт как его изготовить? Надо будет спросить на форуме Cirrus'a.
Цитата(AlexandrY @ May 24 2008, 21:04)
wxWidgets вообще-то не есть GUI.
Это некий довольно убогий фреймворк с кучей далеко не embedded функций тесно привязанный к PC платформе.
Смотрите сами: http://docs.wxwidgets.org/stable/wx_functions.html#functions
Шансы поставить его на голую платформу близки к нулю.
Qt - тот же гемор. Это тоже фреймворк, с кучей не относящихся к GUI функций.
Плюс дополнительный гемор - не прямая компиляция. Если Wiki не врет , то там нужно предварительно пропускать исходники через Meta Object Compiler.
В переводе это типичный obfuscator. Т.е. портирование затруднено до предела.
Из опыта работы с Qt на отладочной борде с i.MX27 его так называемая embedded версия требует не менее 30 Мег RAM-а
Это некий довольно убогий фреймворк с кучей далеко не embedded функций тесно привязанный к PC платформе.
Смотрите сами: http://docs.wxwidgets.org/stable/wx_functions.html#functions
Шансы поставить его на голую платформу близки к нулю.
Qt - тот же гемор. Это тоже фреймворк, с кучей не относящихся к GUI функций.
Плюс дополнительный гемор - не прямая компиляция. Если Wiki не врет , то там нужно предварительно пропускать исходники через Meta Object Compiler.
В переводе это типичный obfuscator. Т.е. портирование затруднено до предела.
Из опыта работы с Qt на отладочной борде с i.MX27 его так называемая embedded версия требует не менее 30 Мег RAM-а
wx даавно смотрел - не понравилось
поэтому не скажу хорош он или плоха про Qt - в данном случае "нефиг на зеркало пенять" - при минимальном знании английского (для прочтения доки) он настраиваеться так-как нужно автору ....MOC зоветься автоматом - и нужен для работы связки signal-slot - и это более правильно чем Борландовское творение (VCL - Delphi & Builder с добавлением несуразностей в язык).Qt в данном случае совершенно прозрачен и собираеться пачкой компиляторов без лишних(ну еслим честно они бывают) телодвижений.
про память .... я в свое время ради прикола - прочитавши qtopia на ngw100(ngw100 это эвалюшен для avr32 ap7000) запихал на него нечто для красивого отбражения состояния железки - загрузку проца,памяти ,сколько пролетело через езернеты и по цепрчкам iptables ну и остальной фигни какую смог придумать - на плате 32 метра оперативки и оставалась примерно 4M ....
Цена да - кусаеться в свое время покупали за 2500*2 (две платформы) но это было 4 года назад (еще 3 версия)...Щаз незнаю - 4 покупали без моего участия ....
Цитата(AlexandrY @ May 24 2008, 21:04)
Qt - тот же гемор. Это тоже фреймворк, с кучей не относящихся к GUI функций.
Плюс дополнительный гемор - не прямая компиляция. Если Wiki не врет , то там нужно предварительно пропускать исходники через Meta Object Compiler.
В переводе это типичный obfuscator. Т.е. портирование затруднено до предела.
Из опыта работы с Qt на отладочной борде с i.MX27 его так называемая embedded версия требует не менее 30 Мег RAM-а
Плюс дополнительный гемор - не прямая компиляция. Если Wiki не врет , то там нужно предварительно пропускать исходники через Meta Object Compiler.
В переводе это типичный obfuscator. Т.е. портирование затруднено до предела.
Из опыта работы с Qt на отладочной борде с i.MX27 его так называемая embedded версия требует не менее 30 Мег RAM-а
Не стоит быть таким категоричным в вещах, в которых не разбираетесь.
QTopia отлично портируется на embedded Linux, так как работает напрямую через framebuffer.
Кроме того, перед компиляцией библиотеки пользователь может сам выбрать при помощи QConfig какая функциональность ему нужна - соответственно можно уменьшить размер, выбрав только нужные фичи. Лет 6-7 назад, когда память была дорогая, у меня довольно сложное приложение на QT отлично крутилось на SA1110 c 16 Мб RAM.
Здравствуйте!
Решил пока остановиться на QT. Всё таки Cirrus кое как это поддерживает. Для EDB9315 есть тулчейн, который автоматически лепит бибилотеки QT и окружение рабочего стола OPIE. Так же есть инструмент, который эмулирует фреймбуфер для Х11. То есть можно запускать приложение на ПК, и оно, вроде как, должно выглядеть как на контроллере.
Пока сумел запустить Hello world! из примеров на плате и на ПК. Это получилось не сразу.
Чтобы установить QT/X11 делай раз:
#do-all
#Создать директрию "qtx11" там же, где находится linux-crater_1-0-3/
#копировать и запустить скрипт:
#sourse do-all
wget http://vanille.de/tools/uic-qt2
chmod u+rx uic-qt2
wget http://vanille.de/tools/qvfb-qt2
chmod u+rx qvfb-qt2
wget ftp://ftp.trolltech.com/pub/qt/source/qt-....10-free.tar.gz
tar zxvf qt-embedded-2.3.10-free.tar.gz 1>/dev/null
cd qt-2.3.10
export QTDIR="$(pwd)"
mkdir bin
ln -s $QTDIR/../uic-qt2 bin/uic
ln -s $QTDIR/../qvfb-qt2 bin/qvfb
chmod 666 src/kernel/qpixmapcache.cpp src/kernel/qwindowsystem_qws.h src/tools/qvaluestack.h
patch -p1 < ../../linux-crater_1-0-3/packages/qt/qt-2.3.10-gcc4.1.1-fix.patch
yes yes |./configure -qconfig "" -depths 4,16,24,32 -system-jpeg -system-libpng -system-zlib -no-xft -qvfb
make
export PATH=$QTDIR/bin:$PATH
Чтобы запустить фреймбуфер делай два:
#runfb
#запускает фреймбуффер
#source runfb
export QTDIR=$PWD/qt-2.3.10
export PATH=$QTDIR/bin:$PATH
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
qvfb -width 320 -height 240 &
sleep 5
Чтобы поздороваться с миром делай три:
#run-t1
#завускает Hello world! из примера
#source run-t1
source runfb
$QTDIR/tutorial/t1/t1 -qws &
Как скомпилирвать этот же пример для EDB9315A в linux-crater напишу попозже, если кому то интересно...
Там я много ковырялся, и не только с QT. В общем, работать можно.
Решил пока остановиться на QT. Всё таки Cirrus кое как это поддерживает. Для EDB9315 есть тулчейн, который автоматически лепит бибилотеки QT и окружение рабочего стола OPIE. Так же есть инструмент, который эмулирует фреймбуфер для Х11. То есть можно запускать приложение на ПК, и оно, вроде как, должно выглядеть как на контроллере.
Пока сумел запустить Hello world! из примеров на плате и на ПК. Это получилось не сразу.
Чтобы установить QT/X11 делай раз:
#do-all
#Создать директрию "qtx11" там же, где находится linux-crater_1-0-3/
#копировать и запустить скрипт:
#sourse do-all
wget http://vanille.de/tools/uic-qt2
chmod u+rx uic-qt2
wget http://vanille.de/tools/qvfb-qt2
chmod u+rx qvfb-qt2
wget ftp://ftp.trolltech.com/pub/qt/source/qt-....10-free.tar.gz
tar zxvf qt-embedded-2.3.10-free.tar.gz 1>/dev/null
cd qt-2.3.10
export QTDIR="$(pwd)"
mkdir bin
ln -s $QTDIR/../uic-qt2 bin/uic
ln -s $QTDIR/../qvfb-qt2 bin/qvfb
chmod 666 src/kernel/qpixmapcache.cpp src/kernel/qwindowsystem_qws.h src/tools/qvaluestack.h
patch -p1 < ../../linux-crater_1-0-3/packages/qt/qt-2.3.10-gcc4.1.1-fix.patch
yes yes |./configure -qconfig "" -depths 4,16,24,32 -system-jpeg -system-libpng -system-zlib -no-xft -qvfb
make
export PATH=$QTDIR/bin:$PATH
Чтобы запустить фреймбуфер делай два:
#runfb
#запускает фреймбуффер
#source runfb
export QTDIR=$PWD/qt-2.3.10
export PATH=$QTDIR/bin:$PATH
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
qvfb -width 320 -height 240 &
sleep 5
Чтобы поздороваться с миром делай три:
#run-t1
#завускает Hello world! из примера
#source run-t1
source runfb
$QTDIR/tutorial/t1/t1 -qws &
Как скомпилирвать этот же пример для EDB9315A в linux-crater напишу попозже, если кому то интересно...
Там я много ковырялся, и не только с QT. В общем, работать можно.
Цитата
cd qt-2.3.10
это реально 2 ветка ? брось каку - возьми 3 хотя-б , лучше 4 но тут смотреть надо что лучше к задече подходит .... она приятнее(4) но и более массивная ....
по qt тут можно поспрошать
Пришлось однажды использовать Nano-X. В качестве элементарного GUI сойдет (кнопки, простейшие окошки). Размер 100кб, правда проект уже довольно давно не развивается. Включен в дистрибутив uClinux.
Почему никто не предложил использовать библиотеку GTK? По-моему неплохая альтернатива QT
Почему никто не предложил использовать библиотеку GTK? По-моему неплохая альтернатива QT
Цитата(Maddy @ May 29 2008, 23:24)
это реально 2 ветка ? брось каку - возьми 3 хотя-б , лучше 4 но тут смотреть надо что лучше к задече подходит .... она приятнее(4) но и более массивная ....
по qt тут можно поспрошать
по qt тут можно поспрошать
С qt2 вроде всё получается и смотрится неплохо. Народ, конечно, в быту привык к лучшему (телефоны, комьютеры), но для производства годится. Не делвть же ещё им сменные обои! Однако 3 версию попробую прикрутить. На х11 я примерчик сделал, и qmake мне больше нравится, чем руками маке лабать. Хотя может у qt2 своя утилита есть аналогичная?
Цитата(Cont @ May 29 2008, 23:29)
Пришлось однажды использовать Nano-X. В качестве элементарного GUI сойдет (кнопки, простейшие окошки). Размер 100кб, правда проект уже довольно давно не развивается. Включен в дистрибутив uClinux.
Почему никто не предложил использовать библиотеку GTK? По-моему неплохая альтернатива QT
Почему никто не предложил использовать библиотеку GTK? По-моему неплохая альтернатива QT
А GTK под фрейм-буфер можно конфигурировать? Если да, то где можно посмотреть рецепты?
То что GTK можно сконфигурировать под фреймбуфер - это точно, к сожалению работал с GTK давно, и уже не помню где брал доку на эту тему. Посмотрите на оф. сайте.
Может быть DirectFB (GTK+DirectFB)?
directfb.org
directfb.org
Цитата(Harbour @ May 25 2008, 13:55)
www.fltk.org
а под ucLinux-ом эта штука работает?
А то я подумываю с PXA на blackfin проект перевести и с microwindows на fltk.
Microwindows (он же nano-X) умер не успев родиться, там даже truetype шрифты не работают.
дык а чего бы ему не работать ? есть интересный порт на DirectFB Никиты Егорова, см. :
http://www.mail-archive.com/fltk-dev@easys...m/msg00762.html
http://www.mail-archive.com/fltk-dev@easys...m/msg00762.html
Цитата(Logout @ Jun 2 2008, 01:32)
На х11 я примерчик сделал, и qmake мне больше нравится, чем руками маке лабать. Хотя может у qt2 своя утилита есть аналогичная?
На 2-ой QT-е есть tmake. Я с его помощью два скрипта написал - чтобы собирать проект под нужную платформу (x86 или ARM).
Цитата(Harbour @ Jul 6 2008, 09:37)
дык а чего бы ему не работать ? есть интересный порт на DirectFB Никиты Егорова, см. :
http://www.mail-archive.com/fltk-dev@easys...m/msg00762.html
http://www.mail-archive.com/fltk-dev@easys...m/msg00762.html
Пока не понял, как мне этот directFb хотя бы к PXA-255 прикрутить.
Насколька понял, чтоб fltk заработал, нужен directfb. Какие-то драйвера в нем вроде бы есть, но как это все использовать с конкретным PXA-шным fb (хотя бы где в конфигурации настроить разрешение 640х480 и глубину цвета 16bpp) я не понял. FLTK при компиляции выдает
=== making fluid ===
Linking fluid-shared...
../src/libfltk.so: undefined reference to `dfb_color_to_pixel'
collect2: ld returned 1 exit status
make[1]: *** [fluid-shared] Ошибка 1
судя по всему directfb неудачно собралась?
нашел багу в fltk в файле _draw.cxx
там объявлена внешняя функция dfb_color_to_pixel, которая в directfb является инлайновой, да еще static.
вставил в _draw.cxx:
extern "C" unsigned long dfb_pixel_from_color( DFBSurfacePixelFormat format,
const DFBColor *color );
static inline u32
dfb_color_to_pixel( DFBSurfacePixelFormat format,
u8 r, u8 g, u8 b )
{
const DFBColor color = { 0, r, g, b };
return dfb_pixel_from_color( format, &color );
}
вроде скомпилилось/слинковалось
теперь он мне зачем-то хочет запускать arm-овый бинарник fluid на х86 машине
и shared-library почему-то не сделал, хотя config-у ключик --enable-shared я указал
на первый взгляд microwindows полегче будет - здесь одна libfltk.a мегабайт весит, не считая directfb и прочего
там объявлена внешняя функция dfb_color_to_pixel, которая в directfb является инлайновой, да еще static.
вставил в _draw.cxx:
extern "C" unsigned long dfb_pixel_from_color( DFBSurfacePixelFormat format,
const DFBColor *color );
static inline u32
dfb_color_to_pixel( DFBSurfacePixelFormat format,
u8 r, u8 g, u8 b )
{
const DFBColor color = { 0, r, g, b };
return dfb_pixel_from_color( format, &color );
}
вроде скомпилилось/слинковалось
теперь он мне зачем-то хочет запускать arm-овый бинарник fluid на х86 машине
и shared-library почему-то не сделал, хотя config-у ключик --enable-shared я указал
на первый взгляд microwindows полегче будет - здесь одна libfltk.a мегабайт весит, не считая directfb и прочего
Цитата(Harbour @ May 25 2008, 13:55)
www.fltk.org
Познакомившись поближе с FLTK я не понял юмора:
Оно же работает ТОЛЬКО ПОВЕРХ Х! То есть для embedded системы нужна связка например FLTK + все тот же nano-X !!!?
Если я не прав, поправьте пожалуйста.
Может ли FLTK работать напрямую поверх fb и как его заставить?
Нашел вот сравнение Microwindows, FLTK (FLNX) и QT. Старенькая статейка, правда:
Кстати, а про SDL http://www.libsdl.org/ кто-нибудь может что-то хорошее сказать?
А есть еще китайский miniGUI http://www.minigui.org/ - кто нибудь юзал?
Цитата
Microwindows
Microwindows is an open source project from Century Software that is designed for tiny devices with small display units. It has a lot of features aimed at the modern graphical windowing environment. Like X, Microwindows is supported on variety of platforms.
Microwindows architecture is client/server based and has a layered design. At the lowest level are the screen and input device drivers (as for the keyboard or mouse) to interact with the actual hardware. At the middle level, a portable graphics engine provides support for line draws, area fills, polygons, clipping, and color models.
At the uppermost level, Microwindows supports two APIs: the Win32/WinCE API implementation also known as Microwindows, and the other API mostly resembles that of GDK and is known as Nano-X. Nano-X is used on Linux. It is an X-like API intended for low-footprint applications.
Microwindows has support for 1, 2, 4, and 8 bpp (bits per pixel) palletized displays, as well as 8, 15, 24, and 32 bpp trucolor displays. Microwindows also supports framebuffer, which makes it pretty fast. The footprint of the Nano-X server is somewhere around 100 to 150 kilobytes.
The average raw Nano-X app is in 30 to 60 K in size. Since Nano-X is designed for low-end devices with memory constraints, it does not have support for a large number of functions as X has, and so it can't really serve as a replacement for Tiny X (Xfree86 4.1).
You can run FLNX, a version of the FLTK (Fast Light Toolkit) application development environment modified to target Nano-X rather than X, on top of Microwindows. FLTK is described in this article.
Nano-X's advantages include:
• Unlike the Xlib implementation, Nano-X still runs synchronously per client, meaning that once a client request packet is sent, the server waits until the whole packet has arrived before servicing another client. This keeps the server code immensely simple, while still running very quickly.
• Small footprint
Nano-Xs' disadvantages include:
• Networking features are not properly tuned as yet (especially network transparency).
• Not many ready-to-use applications are available.
• Compared to X, Nano-X has not as much documentation and not as well supported -- although development is going on at lightening speed lately, so this may change.
FLTK API on Microwindows
FLTK is a simple but flexible GUI toolkit that is gaining increasing attention in the Linux world, especially for low-footprint environments. It provides most of the widgets you would expect from a GUI toolkit like buttons, dialog boxes, text boxes, and a nice selection of "valuators" (widgets used for the input of numeric values). These include sliders, scroll bars, dials, and a few others.
The Linux version of FLTK targeted for the Microwindows GUI engine is known as FLNX. FLNX is made up of two components: Fl_Widget and FLUID. Fl_Widget consists of all of the basic widget APIs. FLUID (Fast Light User Interface Designer) is a graphical editor used to produce FLTK source code. In all, FLNX is an excellent UI builder that can be used to create applications for embedded environments.
The footprint of Fl_Widget is about 40 to 48 K and FLUID (which includes every widget) weighs in at around 380 K. These very small footprints are making Fl_Widget and FLUID very popular in the world of embedded development.
Advantages include:
• Anyone accustomed to developing GUI-based applications under more established environments like Windows will adjust to the FLTK environment quite easily.
• Its documentation includes a very complete and well-written manual.
• It is distributed under the LGPL, so developers have flexibility in how they license their applications.
• FLTK is a C++ library (Perl and Python bindings are also available). The choice of an object-oriented model is a good one, as most modern GUI environments are object-oriented; this should also facilitate the porting of applications written to similar APIs.
• Century's environment provides several useful facilities, such as ScreenTop and the ViewML browser.
Its disadvantage is:
• While vanilla FLTK works with both X and Windows APIs, FLNX does not. Its incompatibility with X hinders its adoption in many projects.
Qt/Embedded
Qt/Embedded is Trolltech's new graphical user interface system for embedded Linux. Trolltech initially created Qt for the Linux desktop as a cross-platform development tool. It supports a variety of UNIX flavors, as well as Microsoft Windows. KDE, one of the most popular Linux desktop environments, is written with Qt.
Qt/Embedded is based on the original Qt, with a lot of fine tuning for the embedded environment. Qt Embedded directly interacts with the Linux I/O facilities via the Qt API. Those who are conversant and comfortable with object-oriented programming will find it an ideal environment. Also the object-oriented architecture makes the code structured, reusable, and fast. The Qt GUI is pretty fast compared to other GUIs, and its lack of layering makes Qt/Embedded the most compact environment for running Qt-based programs.
Trolltech has also come up with a Qt Palmtop Environment, popularly known as Qpe. Qpe provides a basic desktop window, and the environment provides an easy-to-use interface for development. Qpe includes a full set of Personal Information Management (PIM) applications, Internet clients, utilities, and more. However, you need to obtain a commercial license from Trolltech in order to integrate Qt/Embedded or Qpe into a product. (The original Qt has been available under the GPL since version 2.2.)
Its advantages include:
• Object-oriented architecture, which makes for faster execution
• Small footprint, about 800 K
• Anti-aliased text and alpha blended pixmaps
Its disadvantage is:
• Qt/Embedded and Qpe are available under commercial licenses only.
Microwindows is an open source project from Century Software that is designed for tiny devices with small display units. It has a lot of features aimed at the modern graphical windowing environment. Like X, Microwindows is supported on variety of platforms.
Microwindows architecture is client/server based and has a layered design. At the lowest level are the screen and input device drivers (as for the keyboard or mouse) to interact with the actual hardware. At the middle level, a portable graphics engine provides support for line draws, area fills, polygons, clipping, and color models.
At the uppermost level, Microwindows supports two APIs: the Win32/WinCE API implementation also known as Microwindows, and the other API mostly resembles that of GDK and is known as Nano-X. Nano-X is used on Linux. It is an X-like API intended for low-footprint applications.
Microwindows has support for 1, 2, 4, and 8 bpp (bits per pixel) palletized displays, as well as 8, 15, 24, and 32 bpp trucolor displays. Microwindows also supports framebuffer, which makes it pretty fast. The footprint of the Nano-X server is somewhere around 100 to 150 kilobytes.
The average raw Nano-X app is in 30 to 60 K in size. Since Nano-X is designed for low-end devices with memory constraints, it does not have support for a large number of functions as X has, and so it can't really serve as a replacement for Tiny X (Xfree86 4.1).
You can run FLNX, a version of the FLTK (Fast Light Toolkit) application development environment modified to target Nano-X rather than X, on top of Microwindows. FLTK is described in this article.
Nano-X's advantages include:
• Unlike the Xlib implementation, Nano-X still runs synchronously per client, meaning that once a client request packet is sent, the server waits until the whole packet has arrived before servicing another client. This keeps the server code immensely simple, while still running very quickly.
• Small footprint
Nano-Xs' disadvantages include:
• Networking features are not properly tuned as yet (especially network transparency).
• Not many ready-to-use applications are available.
• Compared to X, Nano-X has not as much documentation and not as well supported -- although development is going on at lightening speed lately, so this may change.
FLTK API on Microwindows
FLTK is a simple but flexible GUI toolkit that is gaining increasing attention in the Linux world, especially for low-footprint environments. It provides most of the widgets you would expect from a GUI toolkit like buttons, dialog boxes, text boxes, and a nice selection of "valuators" (widgets used for the input of numeric values). These include sliders, scroll bars, dials, and a few others.
The Linux version of FLTK targeted for the Microwindows GUI engine is known as FLNX. FLNX is made up of two components: Fl_Widget and FLUID. Fl_Widget consists of all of the basic widget APIs. FLUID (Fast Light User Interface Designer) is a graphical editor used to produce FLTK source code. In all, FLNX is an excellent UI builder that can be used to create applications for embedded environments.
The footprint of Fl_Widget is about 40 to 48 K and FLUID (which includes every widget) weighs in at around 380 K. These very small footprints are making Fl_Widget and FLUID very popular in the world of embedded development.
Advantages include:
• Anyone accustomed to developing GUI-based applications under more established environments like Windows will adjust to the FLTK environment quite easily.
• Its documentation includes a very complete and well-written manual.
• It is distributed under the LGPL, so developers have flexibility in how they license their applications.
• FLTK is a C++ library (Perl and Python bindings are also available). The choice of an object-oriented model is a good one, as most modern GUI environments are object-oriented; this should also facilitate the porting of applications written to similar APIs.
• Century's environment provides several useful facilities, such as ScreenTop and the ViewML browser.
Its disadvantage is:
• While vanilla FLTK works with both X and Windows APIs, FLNX does not. Its incompatibility with X hinders its adoption in many projects.
Qt/Embedded
Qt/Embedded is Trolltech's new graphical user interface system for embedded Linux. Trolltech initially created Qt for the Linux desktop as a cross-platform development tool. It supports a variety of UNIX flavors, as well as Microsoft Windows. KDE, one of the most popular Linux desktop environments, is written with Qt.
Qt/Embedded is based on the original Qt, with a lot of fine tuning for the embedded environment. Qt Embedded directly interacts with the Linux I/O facilities via the Qt API. Those who are conversant and comfortable with object-oriented programming will find it an ideal environment. Also the object-oriented architecture makes the code structured, reusable, and fast. The Qt GUI is pretty fast compared to other GUIs, and its lack of layering makes Qt/Embedded the most compact environment for running Qt-based programs.
Trolltech has also come up with a Qt Palmtop Environment, popularly known as Qpe. Qpe provides a basic desktop window, and the environment provides an easy-to-use interface for development. Qpe includes a full set of Personal Information Management (PIM) applications, Internet clients, utilities, and more. However, you need to obtain a commercial license from Trolltech in order to integrate Qt/Embedded or Qpe into a product. (The original Qt has been available under the GPL since version 2.2.)
Its advantages include:
• Object-oriented architecture, which makes for faster execution
• Small footprint, about 800 K
• Anti-aliased text and alpha blended pixmaps
Its disadvantage is:
• Qt/Embedded and Qpe are available under commercial licenses only.
Кстати, а про SDL http://www.libsdl.org/ кто-нибудь может что-то хорошее сказать?
А есть еще китайский miniGUI http://www.minigui.org/ - кто нибудь юзал?
Прочитал, что FLTK можно скомпилить поверх NXLIB - надстройка над nano-X. Скомпилил nxlib-0.45, получил libX11.so. А FLTK требует еще libXext. Ее откуда брать? Кто работал, как вообще этот FLTK запустить на ARM?
Цитата(Johny @ Aug 8 2008, 20:32)
Прочитал, что FLTK можно скомпилить поверх NXLIB - надстройка над nano-X. Скомпилил nxlib-0.45, получил libX11.so. А FLTK требует еще libXext. Ее откуда брать? Кто работал, как вообще этот FLTK запустить на ARM?
Вобщем
Первым делом выкинул из FLTK-шного configure.in упоминание о -lXext
После этого при линковке появилось сообщение о ненайденных функциях XSetSelectionOwner и еще какой-то
Функции оказались в файле Selection.c библиотеки nxlib-0.45, но почему-то в Makefile этого объектника не оказалось - пришлось добавить. Заодно подправил warning - в структуре sstruct в одном месте была лишняя s: ssstruct. Один warning правда остался - implifict declaration of function time(). Что они имели в виду, когда писали time(0), я не понял, потом разберемся.
До кучи выкачал снапшот nano-X от 04.08.08 - оказывается проект еще не совсем умер, вот их mailing list
По ходу дела обнаружился flnx-1.1.8 - порт fltk на nano-X
А после всего этого, я посмотрел на fltk и подумал:
А зачем оно мне надо? Ведь это по сути набор виджетов, который я буду использовать процентов на 10, потому как оно все написано для большой машины. На эмбежженом девайсе с экраном 3,5' и десятью кнопками, одна из которых - питание, все это не надо.
Тот интерфейс, который для него разработан, прост и удобен, но большей части его компонентов нет ни в одной самой навороченной библиотеки виджетов. Не уверен, есть ли в этих библиотеках и функции рисования графиков - скорее всего, подходящих - нет.
В общем microwindows - рулез, возможно directFB и китайский mini-GUI. Остальное - излишества
О ужас! В библиотеке FLTK, в файле FL_x.cxx строка 582 я встретил оператор goto
А вообще у меня похоже в FLTK не идет ввод с клавиатуры в нужное окно.
А вообще у меня похоже в FLTK не идет ввод с клавиатуры в нужное окно.
Цитата(Johny @ Aug 11 2008, 20:07)
О ужас! В библиотеке FLTK, в файле FL_x.cxx строка 582 я встретил оператор goto
Так без goto жизни нет вообще
Особенно в kernel'е.Сам сейчас занят аналогичной проблемой - созданием GUI. После долгих размышлений пришел к выводу, что нужно писать все самому.
Цитата(aaarrr @ Aug 11 2008, 20:33)
Так без goto жизни нет вообще Особенно в kernel'е.
Сам сейчас занят аналогичной проблемой - созданием GUI. После долгих размышлений пришел к выводу, что нужно писать все самому.
Особенно в kernel'е.Сам сейчас занят аналогичной проблемой - созданием GUI. После долгих размышлений пришел к выводу, что нужно писать все самому.
Я бы не был настолько категоричен. Все-таки рисование графических примитивов и работу с рисунками (хотя бы .bmp) работу со шрифтами (желательно UTF-8 .ttf) проще использовать готовые. Так же как и каркас обработчика событий.
Работа с .bmp пишется и отлаживается за день. Использование .ttf во встраиваемых приложениях представляется сомнительным - растровые шрифты получаются компактнее и быстрее.
А всякие хитрые виджеты все равно приходится делать свои.
А всякие хитрые виджеты все равно приходится делать свои.
Долго мучался со вводом с клавиатуры, а все оказалось очень просто:
Для FLTK нужны скан-коды, а у меня nano-X был скомпилен с драйвером tty, который всегда возвращает из функции TTY_Read() *scancode = 0. Пересобрал nano-X с драйвером tty-scan, и ввод заработал!
К сожелению драйвер pipe (kbd_pipe.c), который я использую на девайсе тоже не возвращает скан-код, надо будет что-то с ним делать.
Для FLTK нужны скан-коды, а у меня nano-X был скомпилен с драйвером tty, который всегда возвращает из функции TTY_Read() *scancode = 0. Пересобрал nano-X с драйвером tty-scan, и ввод заработал!
К сожелению драйвер pipe (kbd_pipe.c), который я использую на девайсе тоже не возвращает скан-код, надо будет что-то с ним делать.
Решил посмотреть, как в FLTK 1.1.x поддержка многопоточности сделана так же, как в microwindows - никак. Только в 2.0 появилась. Предлагается синхронизировать через за файл - пайп или сокет.
2.0 на DirectFB не портирован, а под nano-X подозреваю, тормозить будет сильно.
Кто-нибудь сравнивал, насколько FLTK на nano-X тормознее microwindows приложения?
2.0 на DirectFB не портирован, а под nano-X подозреваю, тормозить будет сильно.
Кто-нибудь сравнивал, насколько FLTK на nano-X тормознее microwindows приложения?
Избавился от бордюра окна в FLTK+nano-X!
Запускал:
nano-X& nanowm& myApp
Оказывается, надо запускать без nanowm:
nano-X& myApp
Откуда FLTK берет шрифты? Как установить кодировку lable-ов?
Запускал:
nano-X& nanowm& myApp
Оказывается, надо запускать без nanowm:
nano-X& myApp
Откуда FLTK берет шрифты? Как установить кодировку lable-ов?
Цитата(Johny @ Aug 21 2008, 19:36)
Откуда FLTK берет шрифты?
/etc/fonts/fonts.conf
Цитата(al333 @ Aug 22 2008, 11:14)
/etc/fonts/fonts.conf
Это на стандартной Х11, наверное. На нано-Х этим занимается нано-Х. У нее там в исходниках прописана пара директориев. Важно, чтобы файл с описанием шрифтов там был. Приду на работу, гляну что и куда я там ставил.
Вопрос знатокам.
Посмотрел wxFormBuilder и сижу в недоумении.
Почему-то не работает размещение контролов по x,y (pos X,Y).
Это так задумано или только у меня не работает?
Если так и задумано, как это можно исправить до вменяемого человеческого варианта (типа VS), существует ли патч?
Потому, как сделать более менее сложный интерфейс не получается.
-
Посмотрел wxFormBuilder и сижу в недоумении.
Почему-то не работает размещение контролов по x,y (pos X,Y).
Это так задумано или только у меня не работает?
Если так и задумано, как это можно исправить до вменяемого человеческого варианта (типа VS), существует ли патч?
Потому, как сделать более менее сложный интерфейс не получается.
-
Встроил в x86 с 24 Мб памяти и 300 МГц Qt Embedded 4.4.2. Все работает нормально. Только возникла проблема уменьшения времени запуска. Основной вес в статически слинкованном Qt приложении( 8 М ). Есть хороший паковщик исп. файлов UPX, только что-то для моего многопоточного прил. не подходит - при запуске сегментация и т.д. Хотел уменьшить за счет отключения фич в библиотеке с пом. qconfig, так она не компилится, говорит, что чего-то там не найдено. Пришлось отключать ненужное с пом. configure((
Как уменьшить еще размер Qt приложения?
Как уменьшить еще размер Qt приложения?
Цитата(Alexander2000 @ May 25 2009, 09:38)
Основной вес в статически слинкованном Qt приложении( 8 М ). Есть хороший паковщик исп. файлов UPX, только что-то для моего многопоточного прил. не подходит - при запуске сегментация и т.д. Хотел уменьшить за счет отключения фич в библиотеке с пом. qconfig, так она не компилится, говорит, что чего-то там не найдено. Пришлось отключать ненужное с пом. configure((
Как уменьшить еще размер Qt приложения?
Как уменьшить еще размер Qt приложения?
Восемь мегабайт - это целый монстр. Паковать ничего не нужно. В принципе, в инете есть достаточно рабочих рецептов, например здесь http://www.prog.org.ru/index.php?topic=3974.msg17516 Единственная проблема, с которой сталкивался - это время потраченное на эксперименты. Троллтехи готовых рецептов не дают, даже по подписке т.к. обычно с выхоодм новой версии заново приходится экспериментировать.
При попытке портировать проект с использованием microwindows WIN32 API с arm-linux на blackfin-uClinux первое разочарование: На uClinux framebuffer, похоже, одновременно может работать только одно microwindows WIN32 API приложение - второе не может открыть framebuffer. Это связано с ограничением uClinux - не поддерживается вызов mmap(MAP_SHARED, PROT_WRITE, file). Вместо него используется mmap(MAP_PRIVATE, PROT_WRITE, file) для отображения framebuffer в память.
Наверное, переписывание под FLTK/nano-X решит проблему - там вроде все приложения используют один nano-X сервер, а значит и framebuffer открывается только один раз.
Наверное, переписывание под FLTK/nano-X решит проблему - там вроде все приложения используют один nano-X сервер, а значит и framebuffer открывается только один раз.
Давно уже не секрет что Qt почти год назад вышел под хорошей для всех лицензией - под LGPL. Никому ничего платить давно уже не надо. Интересует то, как этот факт повлиял на выбор средства реализации GUI автора темы и не только
http://www.antigrain.com/
есть виджеты (кнопки, метки и т.д). Работает на фрейм-буфер. Не помню,как обстоят дела с directfb но видимо никак
Я проводил сравнительные тесты cairo и agg при портировании Flash-плеера на SH4 (STi710x). По моим наблюдениям, cairo сильно проигрывает в скорости отрисовки. Так-же размер у AGG существенно меньше. По функционалу конечно не Qt, но для встраиваемых систем - самое то что нужно. Присутствует в репозитариях дебиана и убунту
есть виджеты (кнопки, метки и т.д). Работает на фрейм-буфер. Не помню,как обстоят дела с directfb но видимо никак
Я проводил сравнительные тесты cairo и agg при портировании Flash-плеера на SH4 (STi710x). По моим наблюдениям, cairo сильно проигрывает в скорости отрисовки. Так-же размер у AGG существенно меньше. По функционалу конечно не Qt, но для встраиваемых систем - самое то что нужно. Присутствует в репозитариях дебиана и убунту
У меня вопросик, близкий по теме поэтому отдельную заводить не стал.
Надо на встроенной десктопной Убунте выводить на весь экран ту или иную картинку, формат картинки не принципиален (jpeg, bmp...) Скорость вывода картинки на экран не критична.
Ради такой фигни тащить на борду какой-нибудь GTK наверное нет смысла. Как это можно сделать попроще, желательно без задействования всяких сторонних пакетов, которые надо будет потом еще и кросскомпилировать (нативной компиляцией не пользуюсь) ?
Спасибо.
Надо на встроенной десктопной Убунте выводить на весь экран ту или иную картинку, формат картинки не принципиален (jpeg, bmp...) Скорость вывода картинки на экран не критична.
Ради такой фигни тащить на борду какой-нибудь GTK наверное нет смысла. Как это можно сделать попроще, желательно без задействования всяких сторонних пакетов, которые надо будет потом еще и кросскомпилировать (нативной компиляцией не пользуюсь) ?
Спасибо.
Цитата(berkl @ Jan 6 2014, 15:22)
Надо на встроенной десктопной Убунте выводить на весь экран ту или иную картинку, формат картинки не принципиален (jpeg, bmp...) Скорость вывода картинки на экран не критична.
Ради такой фигни тащить на борду какой-нибудь GTK наверное нет смысла.
Ради такой фигни тащить на борду какой-нибудь GTK наверное нет смысла.
Какая именно у вас разновидность убунты? Потому что в той же десктопной Lubuntu, что предлагают на dl.cubieboard.org, «какой-нибудь GTK» уже есть:
Код
➜ usr find ./ -name 'libgtk*' -type f
./lib/arm-linux-gnueabihf/libgtk-3.so.0.600.0
./lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0.2400.13
./lib/arm-linux-gnueabihf/libgtk-3.so.0.600.0
./lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0.2400.13
Цитата(Canis Dirus @ Jan 7 2014, 15:14)
Какая именно у вас разновидность убунты? Потому что в той же десктопной Lubuntu, что предлагают на dl.cubieboard.org, «какой-нибудь GTK» уже есть:
Код
➜ usr find ./ -name 'libgtk*' -type f
./lib/arm-linux-gnueabihf/libgtk-3.so.0.600.0
./lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0.2400.13
./lib/arm-linux-gnueabihf/libgtk-3.so.0.600.0
./lib/arm-linux-gnueabihf/libgtk-x11-2.0.so.0.2400.13
В Lubuntu есть, да. Но сборка GTK под arm должна быть и на большом Брате, а она состоит из большой связки других библиотек (glib, atk, cairo, cairo-object, gdk-pixbuf...)
Цитата(berkl @ Jan 7 2014, 20:25)
В Lubuntu есть, да. Но сборка GTK под arm должна быть и на большом Брате, а она состоит из большой связки других библиотек (glib, atk, cairo, cairo-object, gdk-pixbuf...)
И что? С нынешними размерами дисков выделить пяток гигабайт на "armhf chroot" не проблема.
P.S. В принципе, если вам так не хочется ставить gtk, то можете попробовать воспользоваться SDL или даже xlib (лежит в пакете libx11-dev).
Цитата(berkl @ Jan 6 2014, 13:22)
Надо на встроенной десктопной Убунте выводить на весь экран ту или иную картинку, формат картинки не принципиален (jpeg, bmp...) Скорость вывода картинки на экран не критична.
а девайс /dev/fb0 (/dev/fbX) есть? А то прямо туда можно выводить, будет вывод непосредственно в видеопамять.
Если хотите, у меня есть "png2fb", которая png-картинку в фреймбуфер выдает, выложу сюда сырец
Цитата(Canis Dirus @ Jan 10 2014, 18:23)
И что? С нынешними размерами дисков выделить пяток гигабайт на "armhf chroot" не проблема.
P.S. В принципе, если вам так не хочется ставить gtk, то можете попробовать воспользоваться SDL или даже xlib (лежит в пакете libx11-dev).
P.S. В принципе, если вам так не хочется ставить gtk, то можете попробовать воспользоваться SDL или даже xlib (лежит в пакете libx11-dev).
Я старый баре-металлист и всякие штуки, вроде qemu вызывают у меня панический страх и недоверие
. Хотя очевидно, что будущее кросскомпиляции за виртуалками. Пока решил попробовать использовать GTK и диначиескую загрузку библиотек GTK, с помощью функции dlopen(....) , тем самым избавив себя от удовольствия постройки/настройки кроссокружения. Цитата(SM @ Jan 10 2014, 18:28)
а девайс /dev/fb0 (/dev/fbX) есть? А то прямо туда можно выводить, будет вывод непосредственно в видеопамять.
Если хотите, у меня есть "png2fb", которая png-картинку в фреймбуфер выдает, выложу сюда сырец
Если хотите, у меня есть "png2fb", которая png-картинку в фреймбуфер выдает, выложу сюда сырец
Буду пробовать c GTK, спасибо
Непонятно, почему такое частное, поверхностное и бестолковое обсуждение, да ещё 3-х летней давности - держать таким важным и прикреплённым вверху форума.
Чтобы позориться? Чтоб тот, кто случайно заглянет - изумился и удивился
Но если кого ещё раз заинтересует состояние дел с графикой в Linux с точки зрения написания программного кода, то можете скачать Разработка программных проектов в Linux
Там, среди обзора прочего инструментария, есть отдельная глава "Создание графических приложений", рассматривается 5 различных инструментариев написания GUI под Linux. С примитивными (но работающими) примерами кодов в архиве, которые можно брать в качестве начальной отправной точки.
P.S. В принципе, тот же, практически, материал, когда-то подготовленный на заказ IBM DeveloperWork: Инструменты ОС Linux для разработчиков приложений для ОС Windows. Часть 8. Разработка GUI приложений.
А ещё отличная альтернатива - Python - графика: быстрая отработка графики малыми трудозатратами (+ Тонкости использования языка Python: Часть 9. Разработка GUI-приложений, Тонкости использования языка Python: Часть 10. 2D Графика и GUI-сценарии )
А ещё в части графики посоветую обратить внимание на библиотеки OpenCV, компьютерного зрения, получившие огромную динамику в развитии в последние пару лет.
Это не их специфика - отображение графики, но, попутно со своим основным назначением, этот инструмент позволяет минимальными затратами отрисовывать графику из кода.
Материалов по OpenCV - море. Некоторые детали, с URL источников информации, см. здесь: OpenCV и компьютерное зрение
Чтобы позориться? Чтоб тот, кто случайно заглянет - изумился и удивился
Но если кого ещё раз заинтересует состояние дел с графикой в Linux с точки зрения написания программного кода, то можете скачать Разработка программных проектов в Linux
Цитата
Объём (страниц): 307
Размер файла текста: 2493316
Размер архива кодов: 2623890
Размер файла текста: 2493316
Размер архива кодов: 2623890
Там, среди обзора прочего инструментария, есть отдельная глава "Создание графических приложений", рассматривается 5 различных инструментариев написания GUI под Linux. С примитивными (но работающими) примерами кодов в архиве, которые можно брать в качестве начальной отправной точки.
P.S. В принципе, тот же, практически, материал, когда-то подготовленный на заказ IBM DeveloperWork: Инструменты ОС Linux для разработчиков приложений для ОС Windows. Часть 8. Разработка GUI приложений.
А ещё отличная альтернатива - Python - графика: быстрая отработка графики малыми трудозатратами (+ Тонкости использования языка Python: Часть 9. Разработка GUI-приложений, Тонкости использования языка Python: Часть 10. 2D Графика и GUI-сценарии )
А ещё в части графики посоветую обратить внимание на библиотеки OpenCV, компьютерного зрения, получившие огромную динамику в развитии в последние пару лет.
Это не их специфика - отображение графики, но, попутно со своим основным назначением, этот инструмент позволяет минимальными затратами отрисовывать графику из кода.
Материалов по OpenCV - море. Некоторые детали, с URL источников информации, см. здесь: OpenCV и компьютерное зрение
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.