в "обойме" 17-го есть ненавязчивый, но очень интересный однопанельный файловый менеджер, который чудненько смотрится в дополнение к излюбленному urxvt+vim+bash+mc :
всё классно, но прошло какое-то время, прежде чем стал пользоваться этим чудом на полную катушку. очень интересно организована ассоциация типов файлов и приложений, им соответствующих. как ни странно - всё в соответствии со стандартами, что просто удивительно. каждый файл "оценивается" по mime.types (определённому либо в /etc/mime.type либо в ~/.mime.types, но субъективно у /etc/mime.types есть некий приоритет в "весовой категории"):
а для непосредственной ассоциации одной или нескольких программ с определённым типом файла используется запись "MimeType=" в .desktop файле приложения. например:
$ cat ~/.local/share/applications/MPlayer.desktop
[Desktop Entry]
Hidden=false
Name[en_US]=MPlayer
NoDisplay=false
Icon[en_US]=/home/sda/.icons/MacOS-X/48x48/apps/mplayer.png
Exec=mplayer %f
Type=Application
Version=1.0
StartupNotify=false
StartupWMClass=MPlayer
GenericName=MPlayer
Name=MPlayer
Terminal=false
Icon=/home/sda/.icons/OSX/scalable/apps/purrr.png
GenericName[en_US]=MPlayer
MimeType=video/x-msvideo;video/x-ms-wmv;video/mpeg;
результат - прекрасный однопанельник без излишних "наворотов", чего собственно и хотелось.
на закуску - об очередной чумовой придумке. смысл: для того, чтобы что-то сделать (написать текст, нажать на кнопку и т.п.) нужно сперва "разбить стекло"! идея-то лежала на поверхности: разбейте стекло и воспользуйтесь огнетушителем, топором, молотком и т.п.. это стоит право увидеть самому (команда ewl_embed_test). итак... до:
"после":
внесённые изменения опять прячем под стекло:
4 комментария:
извиняюсь что тут пишу - просто несмог камент запостить там с opera и firefox - что делать? даж мыла нет, нада наверно по джабберу связаться...
ко мне это не относится - так как я юзаю gentoo, то собираю как хочу.
в данный момент устоялась следующая конфигурация:
[ebuild R ] x11-libs/evas-9999 USE="X cairo edb fbcon gif jpeg mmx nls opengl png sdl sse svg threads tiff xpm (-altivec) -directfb -doc" 0 kB
тоесть DirectFB отключен, а GL включен.
собственно для тестов уже есть софтина - expedite, и она говорит следующее:
vadim@vadim ~ $ expedite
ERROR: No GL Glew Engine built
ERROR: No Software DirectDraw Engine built
ERROR: No Direct3D Engine built
No engine selected.
Options:
-e ENGINE
Where ENGINE can be one of:
x11 xr gl-glew gl x11-16 ddraw direct3d sdl
ну и соответственно и её тестах, в среднем, xrender медленнее раза в 2 чем sofware-x11.
тут есть ещё одна непонятка - OpenGL это не xrender, и GL вообще нельзя поставить в Е как движок. А в entrance можно, зато он виснет наглухо через 5 минут...
...
вот что я натестировал:
vadim@vadim ~ $ expedite -e gl
324.19 , Image Blend Unscaled
vadim@vadim ~ $ expedite -e x11
135.79 , Image Blend Unscaled
vadim@vadim ~ $ expedite -e xr
68.05 , Image Blend Unscaled
при этом на Athlon64 X2 3800+(2ГГц) и ATI X1300
загрузка ядер процессора, сответсвенно:
45-50%/13-15%
99%/99%
99%/8-10%
а в холостую
2-4%/2-4%
тоесть получается что x11 и xr работают одинаково, но xr не использует второе ядро - поэтому пролетает... ну а GL всех сделал что и следовало ожидать. ну а sdl - делает 80 fps на обном ядре - тоже обходит xr...
>>извиняюсь что тут пишу
да полно вам, наоборот, с благодарностью читаю...
тут ещё поднял свои логи ирки - оказалось, что товарищ Растерман также уверен, что поддержка DirectFB не нужна, если она не критична естественно.
17-ый, если разобрать, можно представить как некое множество различных модулей, действующих в одном окружении. в своём скрипте форсировал OpenGL для evas, запретил DirectFB с линковкой на evas для ecore и остальные EFL унаследовали эту установку. например:
ewl 0.5.1.011
Engines:
Software X11...................: yes
Software 16 X11................: no
OpenGL X11.....................: yes
XRender X11....................: yes
Framebuffer....................: no
Buffer.........................: yes
Optional Components:
Emotion Support.................. yes
Epsilon Support.................. yes
насчёт поставить gl как движок - не очень хорошая идея, ибо (слава Богу) "Ешка" никогда не позиционировалась (и дай Бог, что не будет) в качестве 3D WM-а. опять же OpenGL - это (всего лишь) набор инструкций, поддержка которых - дело хорошее, но и отсутствие для 2D - не смертельно.
>>тут ещё поднял свои логи ирки -
>>оказалось, что товарищ Растерман также
>>уверен, что поддержка DirectFB не
>>нужна, если она не критична естественно.
мой английский до такого не дотягивет...
Ну DFB допустим на КПК заюзать можно, када дров небыло на X1300 - тож через него сидел.
а насчёт GL - причём тут 3D? отрисовка просто драматически быстрее... я вот когда с entrance баловался - он намного плавнее крутиться... правда недолго
>> а насчёт GL - причём тут 3D? отрисовка просто драматически быстрее...
мне кажется, что быстрее именно всвязи с работой OpenGL драйвера, загружающего видеокарту инструкциями, которые та в состоянии обработать (именно в этом контексте и использовался термин 3D, ибо imho кроме Matrox-ов с 2D так никто работать и не научился). в 17-ом основным (ключевым) игроком в отрисовке гуи является evas, с собственным API, зависящим лишь от freetype2 (и ждём-с с 2003-го вроде появления независимой шрифтовой библиотеки). все остальные компоненты (x11, xcb, directfb, opengl, sdl и т.п.) - опциональны. к сожалению работа с кодом opengl приостановлена довольно давно (чем и объясняется уход в ступор entrance и прочих). соответственно "чистый" OpenGL мы в 17-ом увидим не скоро... вспоминая историю с 16-ым - поддержка инструкций gl появилась гораздо позже начального релиза в 2000-ом году. другими словами - ждём-с релиза и доводки evas до ума...
Отправить комментарий