Размещение плавающих окон в i3

Недавно сам пытался разобраться, у меня была обратная проблема: окно Dosbox забивалось в угол, а хотелось видеть его по центру экрана. После курения документации меня хватило только на то, чтобы повесить команду перемещения окна в центр на хоткей. Автоматически это делать никак не получалось.

Ппц. Что-то моя тяга к экспериментам слабеет по мере знакомства с i3...
А как вы окно двигали?

очевидно, тильда в тайлинг вм-ах — лишняя сущность и ненужна.

Итоговый вариант такой:

bindsym $mod+Shift+C move absolute position center

Пробовал так:

for_window [class="dosbox"] floating enable
for_window [class="dosbox"] move absolute position center

тильда в тайлинг вм-ах — лишняя сущность и ненужна.

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

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

man scratchpad
Впрочем, в i3 они не так удобны как в xmonad.

Ну и есть ещё такая шайтан хрень -> http://muhas.ru/?p=8. Работает даже в некоторых жёско контролирующих окна вм-ах.

man scratchpad
Впрочем, в i3 они не так удобны как в xmonad.

Можно поподробней?

Спасибо. Что-то я сам не догадался через точку с запятой две команды написать.

Можно поподробней?

Вот смотри: в i3 сначала окно нужно создать(допустим в автозапуске создаётся), потом положить в скретчпад(допустим ложится с помощью for_window), потом вызываешь его кнопкой.
А если убил это окно, специально или случайно? Всё его нету, сколько на кнопку не дави, не появится — нужно запускать программу заново, что неудобно(а ведь у тебя там ещё и коммандлайн параметры могут быть прописаны, для установки определённого там ксласса). Можно повесить на хоткей, но клава не резиновая. Я решал эту проблему специальным скриптом :).
В xmonad эту ситуацию можно автоматизировать. Что если жмёшь на хоткей, а он такого сретчпада с такой прогой не находит — то запускает.

а ну плюс ещё можно задать начальные размеры и позицию для каждого скретчпада.

В xmonad эту ситуацию можно автоматизировать. Что если жмёшь на хоткей, а он такого сретчпада с такой прогой не находит — то запускает.

Можешь показать, как это делается?

for_window [class=«Tilda»] floating enable; move absolute position 0px 0px

Спасибо, то, что надо! А можно ему ещё бордеры убрать? hide_edge_borders both не срабатывает.

Ещё вопрос: нельзя ли скрестить i3bar и строку заголовков? Чтобы под трей и рабочие толы целую лишнюю строку не отдавать.

Ну, к остальному конфигу добавляется:

-- импорт модуля именованных скретчпадов
import XMonad.Util.NamedScratchpad

-- список скретчей, например
scratchpads = [ 
                NS "ncmpcpp" "urxvtc -name audioplayer -e ncmpcpp" (resource =? "audioplayer" )
                (customFloating $ W.RationalRect (1/6) (1/6) (2/3) (2/3))
  
              , NS "mc" "urxvtc -name filemc -e mc" (resource =? "filemc")
                (customFloating $ W.RationalRect (1/6) (1/6) (2/3) (2/3))

              , NS "emacsclient" "urxvtc -name eeditor -e emacsclient -nw" (resource =? "eeditor")
                (customFloating $ W.RationalRect (1/6) (1/6) (2/3) (2/3))

              , NS "urxvts" "urxvtc -name scratchurxvt" (resource =? "scratchurxvt")
                (customFloating $ (W.RationalRect 0.25 0.375 0.5 0.35))
              ]

-- Ну и дальше где-то биндим на кнопки
myKeys = [
   ....
  , ("<XF86AudioMedia>", namedScratchpadAction scratchpads "ncmpcpp")
  , ("M-S-e", namedScratchpadAction scratchpads "emacsclient")
  , ("M-S-m", namedScratchpadAction scratchpads "mc")
  , ("M-`",  namedScratchpadAction scratchpads "urxvts")
   .... 

for_window [class="Tilda"] floating enable; border none; move absolute position 0px 0px

Именно в таком порядке.

А вот этого, к сожалению, не знаю. Но мне кажется нет.

Запуск, если уже не запущено, будет делаться автоматически?

Всё ясно, именно порядок и был неверный.

Ещё вопрос: нельзя ли скрестить i3bar и строку заголовков? Чтобы под трей и рабочие толы целую лишнюю строку не отдавать.

Лол, именно такое дефолтное поведение в awesome меня раздражает :3

ДА

Лол, именно такое дефолтное поведение в awesome меня раздражает :3

Почему? Чем хороша лишняя пустая строка?

Почему? Чем хороша лишняя пустая строка?

На ней размещается строка с системной информацией. Наверное, если монитор огромный, а окон немного, там поместится и то, и другое, но я не вижу в этом смысла — +/-1 строка никакой роли не играет.

На ней размещается строка с системной информацией.

У меня - нет.

+/-1 строка никакой роли не играет.

Особенно на 768 пикселах...

У меня - нет.

А у 99% пользователей тайловых вм — да (судя по скриншотам) :3

А у 99% пользователей тайловых вм — да (судя по скриншотам) :3

Очевидно, я не отношусь к 99% тайловы WM. :3 Строго говоря, я вообще к пользователям тайловых WM пока не отношусь, так, скучно стало, решил расширить кругозор.

Каким WM на данный момент пользуешься и почему? Что скажешь об awesome vs i3 vs xmonad (в алфавитном порядке :3)?

нельзя ли скрестить i3bar и строку заголовков?

Нет, но в протоколе общения с i3wm предусмотрено получение списка и позиции всех окон, так что можешь написать патч.

Каким WM на данный момент пользуешься и почему?

xmonad, потому что всё работает и устраивает.

awesome

говно

i3

хороший, с несколькими мелкими недочётами. Ну и всё таки конфиг, хоть и неплох, но не так гибок, как еслиб это был скрипт.

xmonad

всё что я от него хотел — всё есть. В ауре арчика есть пакет с патчем для нормальной работы явы :).

root@deadmines:~# aptitude install xmonad
The following NEW packages will be installed:
  cpp-4.5{a} g++-4.5{a} gcc-4.5{a} gcc-4.5-base{a} ghc{a} ghc-doc{a} 
  ghc-haddock{a} libbsd-dev{a} libelfg0{a} libexpat1-dev{a} libffi-dev{a} 
  libfontconfig1-dev{a} libfreetype6-dev{a} libghc-mtl-dev{a} 
  libghc-mtl-doc{a} libghc-random-dev{a} libghc-syb-dev{a} 
  libghc-transformers-dev{a} libghc-transformers-doc{a} 
  libghc-utf8-string-dev{a} libghc-x11-dev{a} libghc-x11-doc{a} 
  libghc-x11-xft-dev{a} libghc-x11-xft-doc{a} libghc-xmonad-contrib-dev{a} 
  libghc-xmonad-contrib-doc{a} libghc-xmonad-dev{a} libghc-xmonad-doc{a} 
  libgmp-dev{a} libgmpxx4ldbl{a} libstdc++6-4.5-dev{a} libxext-dev{a} 
  libxft-dev{a} libxinerama-dev{a} libxrender-dev{a} x11proto-render-dev{a} 
  x11proto-xext-dev{a} x11proto-xinerama-dev{a} xmonad zlib1g-dev{a} 
0 packages upgraded, 40 newly installed, 0 to remove and 0 not upgraded.
Need to get 92.9 MB of archives. After unpacking 448 MB will be used.
Do you want to continue? [Y/n/?]

OMG, оно еше кде не обогнало? :3

awesome

говно

Чем же он тебе так не угодил? :)

да, ghc жирен.

Чем же он тебе так не угодил? :)

конфиги какие-то невменяемые. А 'из коробки' тоже невменяемое всё.

а можно в i3 сделать, чтобы было по 9 экранов на каждом из мониторов, и замену хоткеям как в осм: перекинуть на следующий экран окно, и перевести фокус на следущий экран. Просто мне 9 столов на 2х экранах мало.

перевести фокус на следущий экран

focus output <<left|right|down|up>|output>

перекинуть на следующий экран окно

move container to output <<left|right|down|up>|<output>>

Т.е. именно следующий, как в awesome, нет.

9 экранов на каждом из мониторов

Как я понимаю надо будет назначить для каждого монитора свои workspace (что не очень удобно):

workspace "www" output VGA1
workspace "mail" output LVDS1

move workspace to output <<left|right|down|up>|<output>>

workspace next_on_output|prev_on_output

Т.е. i3 не следит на каком экране фокус, только на каком воркспэйсе и окне. И воркспэйсов с одинаковыми названиями быть не может. Поэтому в awesome, на мой взгляд, это сделано удобнее.

И да, я i3 использую не долго и могу ошибаться, так что если что-то напутал, то поправьте меня кто-нибудь.

Спасибо. Буду пробовать. Может в wmii это легче делается?