LINUX.ORG.RU
Форум — Desktop  

Делаю в FVWM аналог комнат KDE

 , ,


2

1

Прочитал про комнаты KDE, фича однозначно полезная, более того, если вы сами можете управлять, какие окна будут заморожены, а какие нет.
Например, у вас ноутбук работает от батареи, в одной комнате играет плеер и запущен браузер, вы переключаетесь на другую комнату, чтобы писать код - браузер замораживается, чтобы не тратить процессорное время, плеер продолжает играть, а текстовый редактор размораживается. Годнота да и только.

Пока только прототип, и работает так, что, когда вы переключаетесь на другое окно (пока что окно, потом будет «другой стол/страница»), и если в данный момент текущее окно содержит название «Firefox», то вызывается функция FuncFvwmProc firefox, которая устанавливает переменную окну (по которой проверяется состояние, заморожено оно или нет), и замораживает/размораживает первым параметром указанный процесс, и только затем уже переключает окно. 

DestroyFunc FuncFvwmNextWindow
AddToFunc FuncFvwmNextWindow
+ I Current (Firefox) FuncFvwmProc firefox
+ I Current (Leafpad) FuncFvwmProc leafpad
+ I Next (CurrentPage, !Iconic, CirculateHit, AcceptsFocus) FlipFocus NoWarp
+ I Current Raise

DestroyFunc FuncFvwmPrevWindow
AddToFunc FuncFvwmPrevWindow
+ I Current (Firefox) FuncFvwmProc firefox
+ I Current (Leafpad) FuncFvwmProc leafpad
+ I Prev (CurrentPage, !Iconic, CirculateHit, AcceptsFocus) Focus NoWarp
+ I Current Raise

DestroyFunc FuncFvwmProc
AddToFunc FuncFvwmProc
+ I ThisWindow (State 10) Exec kill -CONT $(pgrep $0)
+ I TestRc (False) Exec kill -STOP $(pgrep $0)
+ I State 10

но, может быть запущено много одинаковых процессов с одинаковым названием окна (как например текстовый редактор Leafpad), и нужно точно определять ID процесса по окну. скорей всего придется воспользоваться какой-нибудь сторонней утилитой, - подскажите, такая существует в природе? :)

и да, вопрос по юзабилити, - как бы вы сделали лучше управление процессами, в какой момент их замораживать/размораживать? желательно конечно делать это автоматически, но можно и просто, в заголовок окна повешать еще одну кнопочку, и на нее жмякаешь - процесс данного окна замораживается/размораживается. :)

★★★★★
← Hibernate в Linux Mint 14 MATE
звонки и смс через комп →

в одной комнате играет плеер и запущен браузер, вы переключаетесь на другую комнату, чтобы писать код - браузер замораживается, чтобы не тратить процессорное время, плеер продолжает играть

как он продолжает играть, если он в замороженной комнате?

anonymous
()
Ответ на: комментарий от Spoofing

твой проект ещё тоько на уровне концепта, а уже через жопу

лучше вообще ничего не пиши, пока не научишься строить нормальные продуманные системы

anonymous
()
Ответ на: комментарий от Spoofing

для начала - проштудируй учебник по логике

anonymous
()
Ответ на: комментарий от Spoofing

это в кедах так. а я описал ситуацию, как будет сделано в fvwm.

В кедах у окна есть галочка «во всех комнатах», не оно?

vyazovoi ★★★
()

Столкнулся с похожей проблемой, с определением ID окна.

На тот момент, у меня была своя концепция реализации «объектов» в shell'e. Связал fvwm + объекты, получилось довольно стройно.

К примеру, такая вот видео стена написана на 40-60 минут http://www.youtube.com/watch?v=Wis_VLLIBVI

anonymous
()
Ответ на: комментарий от anonymous

О ФИ ГЕТЬ! :D

Так глянешь, сколько всяких штук можно сделать клевых, и что FVWM дает для этого полную свободу действий... прям ух, завораживает.

Вы это просто так для примера показывали, или у вас возникла какая-то задача, просматривать много mplayer'ов одновременно? Может, систему охраны делали? :)

Сам представляю, что таким образом можно устроить превью фильмов, т.е. открывать из директории много mplayer'ов с фильмами, где они с рандомной позиции будут просматриваться и тайлиться на экране, и сделать бинд, чтоб при клике на видео закрывались все mpalyer'ы, а открывался данный фильм. Ых.. блин, ну круто, захотелось прям тоже что-нибудь сварганить эдакое. :)

А пока надо решить главный вопрос с определнием ID окна, в FVWM есть переменная $[w.id] которая в контексте окна хранит его ID, и вот по этому ID теперь остается узнать какому процессу это окно принадлежит)..

Spoofing ★★★★★
() автор топика

Не взлетит, you're doing it wrong. Нужно полноценное управление сеансами с поддержкой в приложениях, а не костыли.

geekless ★★
()
Ответ на: комментарий от Spoofing

Вы это просто так для примера показывали, или у вас возникла какая-то задача, просматривать много mplayer'ов одновременно? Может, систему охраны делали? :)

Делал для себя, дома на кухне крутится видеостена, 5x5, в ней показываются только что залившиеся ролики на ютюб (идет постоянный процесс обновления новых роликов, и удаления старых).

А пока надо решить главный вопрос с определнием ID окна, в FVWM есть переменная $[w.id] которая в контексте окна хранит его ID, и вот по этому ID теперь остается узнать какому процессу это окно принадлежит)..

Моя реализация такова:

Запускается FvwmEvent модуль, для того чтобы создавать абстракцию объект xwindow. Связывает id окна с понятием объект

*FvwmObjectEvent: add_window FvwmObjectEventAddWindow

...
AddToFunc FvwmObjectEventAddWindow
+ I exec $[HOME]/.obj/obj new xwindow $[OBJECTS_DIR]/windows/$0

При создании объекта, у него (объекта) вызывается конструктор, который создает связь вида xwindow_id <-> объект.

У объекта есть свойства: window_id, pid, символическая ссылка на /proc/pid, путь до fifo управления mplayer'a.

Например в конструкторе код выполняющий связь с /proc выглядит следующим образом: 

id_regex=`obj_prop_get id_regex`

obj_prop_set pid `wmctrl -pl | grep -E "$id_regex" | awk -F" " '{print $3}'`
obj_link_set /proc/`obj_prop_get pid` proc

Сам объект создается в директории 

~/.obj/$hash

где $hash - это hash от абсолютного пути к объекту (на древовидную структуру файловой системы довольно хорошо кладутся понятия namespace из объектных языков программирования).

В случае объекта xwindow hash рассчитывается от абсолютного пути ~/objects/windows/window_id

После создания объекта к нему делается символическая ссылка, для удобства пользователя. Выходит примерно так:

~/objects/windows/0x1c00022 -> ~/.obj/125ef1a9d5769b7c3d14b25c148b93c0

Так же у объекта есть метода Enter и Leave, они вызываются с помощью того же FvwmEvent

*FvwmObjectEvent: enter_window FvwmObjectEventEnterWindow
*FvwmObjectEvent: leave_window FvwmObjectEventLeaveWindow

...
AddToFunc FvwmObjectEventLeaveWindow
+ I ThisWindow (VideoStage*) exec $[HOME]/.obj/obj func $[OBJECTS_DIR]/windows/$0 Enter

...
AddToFunc FvwmObjectEventLeaveWindow
+ I ThisWindow (VideoStage*) exec $[HOME]/.obj/obj func $[OBJECTS_DIR]/windows/$0 Leave

При закрытие окна срабатывает деструктор объекта, через тот же FvwmEvent. Он в свою очередь подчищает созданные объектов проекции на файловую систему. 

...
AddToFunc FvwmObjectEventDestroyWindow
+ I exec $[HOME]/.obj/obj destroy $[OBJECTS_DIR]/windows/$0

Смею предположить, что может сложиться ощущение нагромождения лишних сущностей и громоздкости системы в целом. Из моего скромного опыта общения с Fvwm, и знакомства с миром unix-way в целом, я пришел к такой концепции объектов в файловой системе, что-бы более менее, стандартизировать и инкапсулировать «костыли», которые так или иначе появляются у fvwm пользователей и в целом последователей unix-way.

Выходит опрятно и складно. Единственное, небольшой порог вхождения, есть отголоски plan9.

anonymous
() 

┌[lord] [home-hell-machine]:~ 
└>xprop 

_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
_NET_WM_DESKTOP(CARDINAL) = 2
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_PID(CARDINAL) = 29834
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLASS(STRING) = "rxvt-unicode", "URxvt"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x1000015
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 11 by 32
		program specified resize increment: 7 by 14
		program specified base size: 4 by 18
		window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "home-hell-machine"
WM_COMMAND(STRING) = { "urxvt", "-embed", "16777225" }
_NET_WM_ICON_NAME(UTF8_STRING) = "rxvt-unicode"
WM_ICON_NAME(STRING) = "rxvt-unicode"
_NET_WM_NAME(UTF8_STRING) = "rxvt-unicode"
WM_NAME(STRING) = "rxvt-unicode"

# смотрим на "_NET_WM_PID(CARDINAL) = 29834"

┌[lord] [home-hell-machine]:~ 
└>ps ax | grep -v grep | grep 29834
29834 ?        Ss     0:00 rxvt-unicode
Spirit_of_Stallman ★★★
()

зачем пилисть свой de когда есть готовые линуксоводы клиенты людей в белых халатах

anonymous
()

в твоей концепции так же есть один неверный постулат. Хотя он и оговорен не явно.

Окно != Процесс.

Простейший пример Браузер chrome/chromium, либо FvwmTabs

anonymous
()
Ответ на: комментарий от anonymous

зачем пилисть свой de когда есть готовые

потому что они едят по целых 500 метров памяти, неЪ и всё такое же прочее прыщичковое ололо

но ТС тут ещё, можно сказать, демонстрирует весьма лёгкую степень ФГМ

самый смешной поциент в этом плане - geekless, который пилит себе из кусочков суперпуперудобное окружение чтобы повысить КПД своей работы пиления суперпуперудобного окружения

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Hibernate в Linux Mint 14 MATE
Desktop
звонки и смс через комп →