23 ноября, 2006

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

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

Кстати, об идеале. Когда-то, не так давно, у меня возникло желание написать небольшую (а может даже и не небольшую) статью о том, что же такое в моём понимании "идеальное рабочее место" (разумеется, речь о 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-а) можно посмотреть в моей предыдущей заметке, где Вы также найдёте пару советов, которые могут оказаться крайне полезными, если Вы решите опробовать описанный мною подход на практике.

2 комментария:

portnov комментирует...

Респект. Весьма похоже на мои мысли, но изложено более связно ;)

Анонимный комментирует...

Мысли практически один-в-один повторяют вот это. Что тут скажешь? Екклезиаст да и только :-)