Чтобы иметь окно не появляются в списке задач, необходимо установить skip_taskbar
кому: true
для клиента. Поскольку Вы хотите сделать это для определенных приложений, вероятно, лучший способ состоит в том, чтобы добавить клиентское правило к Вашему rc.lua
:
awful.rules.rules = {
{ rule = { class = {"Gajim","Skype"} },
properties = { skip_taskbar = true }
},
-- other rules ...
}
Вам, вероятно, придется изменить значения для class
. Для получения класса окна X программ звонить xprop WM_CLASS
от терминала затем нажмите на окно, которому Вы хотите соответствовать. Это должно произвести 2 значения (например. WM_CLASS(STRING) = "Zsh", "URxvt"
). Второй является тем для class
. Первый может соответствовать instance
и может использоваться для дифференциации между окнами от той же программы.
См. также Потрясающую Wiki для больше на правилах и Потрясающих документах API для списка свойств, которые можно установить с правилами.
О чем свидетельствует любезность (-)?
Заметьте, что они также имеют PRI балл -100; это указывает на то, что процесс запланирован как процесс в реальном времени . Процессы в реальном времени не используют хорошие оценки и всегда имеют более высокий приоритет, чем обычные, но все же отличаются друг от друга.
Вы можете просмотреть детали каждого процесса с помощью команды chrt
(например, chrt -p 3
). Один из ваших -100, скорее всего, сообщит "текущий приоритет планирования" 99 -- в отличие от nice
, здесь высокие значения имеют более высокий приоритет, откуда, вероятно, сверху было создано число -100
. Процессы, не относящиеся к реальному времени, всегда будут иметь "текущий приоритет планирования" 0 в chrt
независимо от хорошего значения, а под linux "текущая политика планирования" из
SCHED_OTHER
.
Только машины Ubuntu и CentOs имеют нецифровые значения точности.
Некоторые версии top
, похоже, сообщают о процессах в реальном времени с rt
под PRI, а затем 0
под NI.
@ Ответ Голдилока направил меня на то, чтобы провести исследование в правильном направлении. Вот подробности моего исследования.
Алгоритмы планирования, доступные для процессов
Linux поддерживает 3 политики планирования. SCHED_FIFO
, SCHED_RR
и SCHED_OTHER
. SCHED_OTHER
является универсальной политикой планировщика распределения времени по умолчанию, используемой большинством процессов; SCHED_FIFO
и SCHED_RR
предназначены для специальных приложений, критичных по времени, которые нуждаются в точном контроле над тем, как выполняемые процессы выбираются для выполнения.
Приоритеты доступны
Для выбора выполняемого процесса планировщик Linux должен учитывать приоритет каждого процесса. На самом деле, существует два типа приоритетов.
A статический приоритет присваивается каждому процессу, и от этого статического приоритета зависит планирование. Процессы, запланированные со значением SCHED_OTHER
, имеют статический приоритет 0; процессы, запланированные со значением SCHED_FIFO
или SCHED_RR
, могут иметь статический приоритет в диапазоне от 1
до 99
(99 - самый высокий).
Рутина sys_sched_get_priority_max( )
возвращает статический приоритет процесса,
возвращает 0
для процессов, работающих в режиме нерегулярного времени.
Динамический приоритет используется для приложений, работающих в режиме нерегулярного времени.
Все процессы, работающие в режиме реального времени, имеют более высокий приоритет, чем обычные процессы. В Linux реализованы приоритеты реального времени в соответствии с POSIX. Приведенный ниже график может дать представление о том, как процессы планируют свою работу с их приоритетами.
HIGH PRIORITY – - – - – > – - – - – > – - – - – > – - – - – > – - – – LEAST PRIORITY
……..real time priority (static priority)…….| …. nice value (dynamic priority) …..
99 ……………………….. 50 ……………………… 1 | -20 …….. -10 …….. 0 …….. 10 ……. 19
Теперь мы можем выдать приведенную ниже команду для проверки приоритета процесса в реальном времени. Здесь я использую сторожевую собаку, так как она имеет приятное значение, перечисленное как -.
ps -e -o class,rtprio,pri,nice,cmd | grep watchdog
Это вывод вышеприведенной команды. Как мы видим, приоритет реального времени - 99, что является наивысшим возможным приоритетом.
FF 99 139 - [watchdog/0]
FF 99 139 - [watchdog/1]
TS - 21 0 grep watchdog
Так что, насколько я понимаю, приоритет реального времени может иметь максимальное значение 99, и поэтому не может быть никакого хорошего значения над ним. По этой причине мы получаем хороший результат как - для сторожевого пса и других системных процессов.
Ссылки
http://oreilly.com/catalog/linuxkernel/chapter/ch10.html http://atipaday.wordpress.com/2008/08/19/atad-21-linux-process-priority-range/