Comments 31
Лично мне очень не хватало подобного функционала ещё в KDE 3. Решил проблему кардинально — перешёл на WMII…
Почему на скриншотах многие видят ШГ, хотя у меня всё в порядке?
У всех разные мониторы. Я вон не только ШГ вижу, но и опечатку в настройках компиза.
А чем такой подход лучше, чем рабочие столы?
рабочие столы то же самое при условии что у вас приложения развернуты на весь экран.
На больших мониторах удобно иметь множество мелких окон, скажем, с открытыми ssh сессиями к разным серверам, в которых бегут логи.
Что б не хватать каждый раз мышку способ может быть полезен
На больших мониторах удобно иметь множество мелких окон, скажем, с открытыми ssh сессиями к разным серверам, в которых бегут логи.
Что б не хватать каждый раз мышку способ может быть полезен
У меня стандартные 24 дюйма — всегда все на весь экран развернуто. Может просто не сталкивался с необходимостью кучи мелких окон.
Тут дело не столько в дюймах сколько в разрешении.
мне, например, очень удобно иметь рядом два окна: ИДЕ (так что б код на экране был) и браузер в 1024х768, так что б видеть сразу результат. Иногда рядом же вешаю маленькое окно с консолью, что б что-то быстрое проверить: запрос, права файла и т.п.
Это ОЧЕНЬ (правда очень) ускоряет работу: когда не надо альттабом искать окно, все перед глазами.
Даже ставил программу xrefresh, она обнавляла браузер при сохранении файла в ИДЕ. Концентрируешься на задаче, пишешь — видишь результат в процессе!
мне, например, очень удобно иметь рядом два окна: ИДЕ (так что б код на экране был) и браузер в 1024х768, так что б видеть сразу результат. Иногда рядом же вешаю маленькое окно с консолью, что б что-то быстрое проверить: запрос, права файла и т.п.
Это ОЧЕНЬ (правда очень) ускоряет работу: когда не надо альттабом искать окно, все перед глазами.
Даже ставил программу xrefresh, она обнавляла браузер при сохранении файла в ИДЕ. Концентрируешься на задаче, пишешь — видишь результат в процессе!
Слабо себе представляю, как 2 окна IDE впринципе могут нормально влезть на один экран. А если еще и браузер и консоль… Можете скриншот примерно показать?
Лично у меня IDE на 2м рабочем столе, браузер на 3м, консоль на F12. С ситуацией, когда надо что-то править так, что бы сразу видеть изменения в браузере ни разу не сталкивался (верстка может быть?).
Лично у меня IDE на 2м рабочем столе, браузер на 3м, консоль на F12. С ситуацией, когда надо что-то править так, что бы сразу видеть изменения в браузере ни разу не сталкивался (верстка может быть?).
Особо остро начинаешь ощущать чем этот подход лучше при использовании >1 монитора.
Ну в том же awessome можно разные «столы» иметь на разных мониторах и по разному их переключать.
В гном-шелле у меня к разным воркспэйсам «приклеены» переменные окружения, что когда я запускаю емакс, потом терминал в одном воркспэйсе и из терминала пытаюсь что-то отредактировать, то емаксклиент коннектится к правильному емакс приложению. Так же и хоткеи для переключения на нужное приложение работают только внутри одного воркспэйса, а не пытаются прыгнуть на какое-то окно из другого воркспэйса.
Всё тоже самое скорее всего можно и в awesome сделать, но и в гном-шелле так же всё это делается без особых проблем.
Всё тоже самое скорее всего можно и в awesome сделать, но и в гном-шелле так же всё это делается без особых проблем.
Всё гораздо проще:
Что касается активации следующего окна при повторном запуске с теми же аргументами, не могу представить, зачем это может быть нужно.
wmctrl -a firefox
Что касается активации следующего окна при повторном запуске с теми же аргументами, не могу представить, зачем это может быть нужно.
разницу можно увидеть, когда открыто несколько окон firefox. wmctrl -a firefox кидает в первое попавшееся окно, а look-at firefox, должен циклить между ними, давая шанс добраться до нужного. по идее. :)
Как насчет активации окна приложения, свернутого в трей? Например, pidgin. Который, между прочим, на свое имя не отзовется, а только на «Buddy List».
Ответ интересует, потому как еще с месяц назад захотел себе накалякать на коленке аналогичный скрипт на bash, но стало лень разбираться с такими подробностями.
Ответ интересует, потому как еще с месяц назад захотел себе накалякать на коленке аналогичный скрипт на bash, но стало лень разбираться с такими подробностями.
Если вам нужно назначить на это действие хоткей, вам должен помочь плагин pidgin-hotkeys. Если вам надо именно в скрипте это сделать, то я вижу только один способ — написать свой плагин.
Кстати, как можно избежать того, что некоторые программы в Ubuntu (Unity+Compiz) перехватывают фокус (окно логина Skype, менеджер обновлений)? Я хочу продолжать работать в том окне где я работаю, а не сворачивать вышеуказанные программы.
В Unity такое работает из коробки, как раз по Super+1..9
именно так. :)
вообще, скрипт появился тогда, когда этой фичи в юнити ещё не было, а у меня уже был gnome2. т.е. давно. и по правде говоря, от перехода на 12.04 и юнити, я ждал именного этого самого коробочного счастья. буквально — до прошлой недели когда обновил убунту.
на практике (п)оказалось, что именно этот переключательный механизм в юнити всё ещё не доделан: переключает с заметным лагом, и вместо нужно окна, я часто попадаю в лаунчер (или как эта штука называется, по типу меню «пуск»). в результате, сложилось ощущение, что скрипт всё ещё может кому-то полезным.
вообще, скрипт появился тогда, когда этой фичи в юнити ещё не было, а у меня уже был gnome2. т.е. давно. и по правде говоря, от перехода на 12.04 и юнити, я ждал именного этого самого коробочного счастья. буквально — до прошлой недели когда обновил убунту.
на практике (п)оказалось, что именно этот переключательный механизм в юнити всё ещё не доделан: переключает с заметным лагом, и вместо нужно окна, я часто попадаю в лаунчер (или как эта штука называется, по типу меню «пуск»). в результате, сложилось ощущение, что скрипт всё ещё может кому-то полезным.
xatk — динамические хоткей для переключения между окнами
Очень удачная в нем заложена концепция хоткеев…
Очень удачная в нем заложена концепция хоткеев…
А еще есть программа xdotool
www.semicomplete.com/projects/xdotool/ — тут и описание и примеры. На мой вкус, сильно мощнее.
А вот тут пример www.semicomplete.com/projects/xdotool/#id270183, тоже с firefox.
www.semicomplete.com/projects/xdotool/ — тут и описание и примеры. На мой вкус, сильно мощнее.
А вот тут пример www.semicomplete.com/projects/xdotool/#id270183, тоже с firefox.
Подскажите название вашей темы оформления.
тема Zukitwo-Dark
<sarcasm>Чего только не придумают люди, лишь бы не пользоваться тайловыми оконными менеджерами.</sarcasm>
До перехода на awesome тоже для этих целей пользовался wmctrl и xdotool.
До перехода на awesome тоже для этих целей пользовался wmctrl и xdotool.
Уже лет пять как я использую продвинутый вариант такой программки — в виде bash скрипта на пять строк. А продвинутый, потому что скрипт умеет принимать класс окна в которое надо переключиться (для случаев программ с разными окнами — pidgin, gimp). Но мне никогда не приходило в голову ни выложить такой элементарный скрипт на github, ни переписать на python — то есть притащить ещё кучу зависимостей.
Вот видимо чего мне не хватает для написания своих опенсорсных проектов: святой уверенности что то что ты написал не может быть решено другим пользователем за 5 минут.
Удивительно… Автору плюс в карму за смелость. Наверное такие программки в репозиториях нужны.
Вот видимо чего мне не хватает для написания своих опенсорсных проектов: святой уверенности что то что ты написал не может быть решено другим пользователем за 5 минут.
Удивительно… Автору плюс в карму за смелость. Наверное такие программки в репозиториях нужны.
умение программировать тем и замечательно, что дает возможность написать что угодно на чём угодно. я зарабатываю разработкой на python, поэтому такая зависимость совсем не мешает. вполне себе язык, ни чем не хуже bash. =)
плюсик в карму, за скромность и минимализм )
плюсик в карму, за скромность и минимализм )
А не могли бы вы поделиться данным скриптом?
Спасибо. Еще бы тайлинг к этой штуке… Не планируете?
Sign up to leave a comment.
look-at — менеджер фокуса