CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
22.08.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Окружение :: Графические среды :: Менеджеры окон

Ion. Немного идеологии

Сегодня, друзья мои, мы сделаем очередной шаг на пути к идеалу.

Кстати, об идеале. Когда-то, не так давно, у меня возникло желание написать небольшую (а может даже и не небольшую) статью о том, что же такое в моём понимании "идеальное рабочее место" (разумеется, речь о desktop-окружении моего компьютера) и параллельно поведать о том, как его построить с использованием конкретного набора программных средств (взяв за основу некоторый менеджер окон). Помимо лени, о которой далее, меня долгое время останавливал один единственный, но архиважный факт - ни один из существующих WM не способен был в полной мере стать основой такого вот, если хотите, своеобразного исследования. В какой-то момент таковым чуть не стал PekWM, но не вдаваясь в излишние подробности просто скажу, что и он при ближайшем рассмотрении оказался далёк от искомого. И наконец, после кое-каких скитаний (очередных) я вернулся к любимому и ненаглядному Ion3, потратил некоторое время на доработку конфигов и, вуаля, - получил то, на основе чего уже можно говорить о прямой дороге к идеалу. Впрочем, оставалось ещё одно препятствие - обычная человеческая лень вкупе с тотальной нехваткой свободного времени. Субъективизм и объективность тут слились в какой-то прямо-таки идеальный союз. Но всё же что-то (надо на досуге поразмыслить - а что же именно?) сподвигло меня на попытку сдвинуть дело с мёртвой точки. Писать сразу, с ходу, полноценную статью пока, я думаю, не стоит. А потому, буду потихоньку, шаг за шагом, "раскрывать тему" в кратких заметках по отдельным аспектам (как "идеологическим", так и чисто техническим) на вышеобозначенную тему. Началом этого своеобразного цикла смело можно считать предыдущую заметку.

Итак, обозначим исходную. Я для себя (невольно, как-то само по себе так получилось) разделил используемые приложения на два "класса": те, сеанс работы с которыми (в т.ч. с несколькими из них параллельно) можно считать относительно длительным (например: IDE, графический редактор, браузер) и те, которые играют скорее "обслуживающую" роль и работу с которыми даже сеансом-то назвать трудно, например: словарь, калькулятор, jabber-клиент, музыкальный плеер. Все нюансы подобного деления мне даже сложно чётко сформулировать. Надеюсь, они постепенно проявятся в дальнейшем. А вот какие-никакие имена этим двум классам дать придётся. Первые обзовём бизнес-приложениями. А вторые, с моей лёгкой руки, scratch-applications. Вот только не могу придумать как это по-русски.

Мы обозначили абстрактным образом два класса приложений и теперь пришло время рассказать характер пользования ими с точки зрения управления их окнами.

Что касается бизнес-приложений, то на каждую группу таких приложений выделяется отдельный workspace (рабочее пространство). При таком подходе рабочих пространств у меня набралось 6 штук. При том, что пределом считаю число 10, если получается больше - надо с этим что-то делать. Примером такой группы может быть следующая связка: IDE + терминал для сборки + утилита тестирования + терминал с логами; а иногда группа определяется множеством окон всего одного приложения, например Gimp. В этом случае основным инструментом переключения между "задачами" является переключение между рабочими пространствами, число которых невелико, редко изменяемо, а оттого их нумерацию легко запомнить. При этом хотелось бы подчеркнуть, что переключение происходит не между конкретными приложениями, а между "задачами" или, можно сказать, "деятельностями". Нет смысла переключения на окно IDE, есть только смысл вернуться от написания текста документа к "процессу разработки", причём вернуться в то место (читай - на то окно), на котором процесс был прерван. Таким образом, переключение между рабочими пространствами, а не окнами - это даже не просто средство тупой группировки, в которой чуть проще разобраться, а полноценный инструмент рациональной организации рабочего места.

Теперь о scratch-applications. Суть использования такого рода приложений состоит в том, что пользователь в процессе выполнения основной своей деятельности на рабочем месте (например, программирования) отвлекается на сравнительно короткое время на использование такого приложения (самый яркий пример в данном случае - jabber-клиент). А быстренько "воспользовавшись" - возвращается к основной своей деятельности. Согласитесь, если принять к использованию вышеописанную "идеологию" использования рабочих пространств, то: выделять ещё одно рабочее пространство под ваш jabber-клиент (либо под все scratch-applications в целом) не логично, так как противоречит идее "деятельность рабочее пространство" даже если выделить таковое пространство, то сам факт переключения на него означает "уход" с того рабочего пространства, на котором в данный момент выполняется основная бизнес-деятельность, что также не выглядит логичным бизнес-приложения как правило используются таким образом, чтобы занимать максимальную область рабочего пространства (часто всю доступную область) и поэтому использование традиционных рабочих пространств Ion3 - WTiling - выглядит вполне логичным, в то время как scratch-applications часто не нуждаются в таких размерах окна (вспомните размеры своего словаря или калькулятора и вы со мной согласитесь).

Исходя из этих трёх утверждений получается, что необходимо некоторое специфическое средство управления окнами таких приложений. Но какое? К счастью, в Ion3 оно есть и называется scratchpad. С использованием дополнительного скрипта (toggle_named_scratchpad.lua) таких scratchpad-ов можно сделать произвольное количество и дав каждому соответствующее наименование. И используя наименования распределить по scratchpad-ам все свои scratch-applications. Есть некоторая свобода при распределении приложений по scratchpad-ам, в отличие от ситуации с распределением бизнес-приложений по рабочим пространствам. Связано это с тем, что для перехода к этого рода приложения мы будем использовать принципиально иной способ, о котором чуть позже. К примеру, у меня есть отдельный scratchpad для e-mail-клиента, но htop и conky прекрасно уживаются на одном и том же.

Так что же это за "принципиально иной" способ? Суть в том, что в данном случае целью является не некоторая абстрактная "задача", на которую мы переключаемся путём перехода на соответствующее рабочее пространство, а окно конкретного приложения, имеющее заранее известные характеристики (такие как class, instance и title). И необходимый нам механизм должен был бы искать открытое окно по соответствующим характеристикам и активировать его, а в случае его отсутствия - запускать соответствующее приложение. А раз уж есть возможность перехода к приложению для его кратковременного использования, необходима и функция "возврата к бизнес-деятельности", от которой пользователь только что отвлёкся. И такой механизм также имеется - скрипт app.lua (подробности использования этого скрипта Вы можете найти непосредственно в комментариях к нему), также доступный на сайте Ion3. А пример использования данного скрипта в соответствии с вышеизложенными идеями и подходами, а также простейший способ реализации функции "возврата" (путём закрытия активного scratchpad-а) можно посмотреть в моей предыдущей заметке, где Вы также найдёте пару советов, которые могут оказаться крайне полезными, если Вы решите опробовать описанный мною подход на практике.





Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds