N идей из Windows 98, о которых стоило бы знать разработчикам современных DE.

Среди пользователей линукс довольно распространена такая точка зрения, что вот в Windows всё плохо, а вот в графических средах для линукс всё хорошо. Между тем, всегда всё плохо быть не практически может, это надо сильно постараться, чтобы добиться такого результата. Поэтому в этой статье я постараюсь осветить те вещи, которые в Windows проработаны лучше, чем в мейнстримовых DE линукса. Возможно, кого-нибудь это вдохновит накодить что-то полезное.

Припомнив народную мудрость, что всё новое — это плотно забытое старое, в качестве жертвы вивисектора подопытной системы я установил Windows 98. Посмотрим, какие же идеи 14-ти летней давности актуальны для линукса и сейчас. Взяв быка за рога, переходим к первой и довольно неожиданной:

Тайлинг окон из контекстного меню панели задач.

Ух... да, вы всё прочитали правильно. В Windows 98 имеется поддержка тайлинга. Даже если вы об этом знали, то, готов спорить, уже наверняка забыли. Правда настоящим тайлингом это трудно назвать: панель задач умеет по команде из контекстного меню тайлить окна вертикально и горизонтально. Это всё.



Вы скажете: «Ну что за ерунда, тайлингом должен заниматься менеджер окон и делать это полноценно. WM в Windows этого не умеет.» Ну я на это скажу, что мой openbox тайлинга тоже не умеет, и в 99,9% процентах случаев мне этого и не нужно. Но если мне потребуется, раз в месяц, расположить несколько окон так, чтобы они не перекрывали друг друга, мне придётся сделать это вручную, а затем установить pytyle на случай, если это снова понадобится. Так что готовая команда, доступная в два клика, — это не лишне.

Кроме тайлинга таже доступно расположение окон каскадом, но я затрудняюсь придумать, для чего оно может быть полезно.

Что интересно, после выполнения действий Tile или Cascade, в меню появляется пункт для отмены этой операции, чтобы можно было «вернуть всё как было».



Однако сама по себе возможность затайлить все окна довольно бесполезна: обычно окон открыто много (особенно учитывая, что из коробки Windows не имеет поддержки переключения рабочих столов), и если ко всем применить тайлинг, на экране возникнет месиво из окон. И тут мы переходим к следующей особенности панели задач Windows:

Применение операций сразу к нескольким окнам панели задач.

Удерживая Ctrl, вы можете выделить несколько окон и затем из контекстного меню применить к ним действие:



Закрыть, свернуть, развернуть, затайлить, расположить каскадом — полный набор. Это достаточно очевидная и не трудная в реализации возможность, тем не менее, в распространёных панелях задач для линукса вы её вряд ли встретите. lxpanel так не умеет. xfce-panel так не умеет. gnome-panel из Gnome 2, скорее всего, тоже не умеет (сейчас мне не в чем проверить), т.к. работает на том же виджете, что и xfce-panel. Про всякие bmpanel и tint и вовсе говорить нечего.

В остальном панель задач Windows 98 банальна и никаких отровений не содержит. Однако стоит обратить внимание на такую возможность, не имеющую отношения к управлению окнами, как

toolbar-ы на панели задач.

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

Не поместившиеся на тулбар иконки отображаются в выпадающем меню, и с этим связана одна то ли багофича, то ли так-и-было-задумано фича: если иконка подкаталога поместилась на тулбар, то щелчок по ней приводит к запуску файлового менеджера; если же подкаталог попал в выпадающее меню, то он становится подменю с собственным содержимым (и так далее, рекурсивно по всем подкаталогам). Эта особенность позволяет, выставив размер тулбара на минимум, использовать его для быстрой навигации по файловой системе.

У панелей для линукса мне встречались реализации виджетов навигации по структуре каталогов. Например, lxpanel имеет такой виджет. А вот виджет, отображающий содержимое каталога непосредственно на панели, — сходу не припомню, есть ли такие и для каких панелей.

Также нельзя не отметить, что такой тулбар мало чем (кроме внешнего вида) отличается от основного поля файлового менеджера: аналогичнм образом работает перетаскивание, в контекстном меню иконок доступно точно такое же меню файлов, как и в Проводнике. И это следующая полезная идея:

Универсальное меню файлов.

Файл — это ключевая абстракция в современном компьютере. Всё, что делает пользователь, крутится вокруг файлов. В файлах лежат данные пользователя. В файлах лежат программы. Всё есть файл. В начале было Слово, и Слово это было ф... так, постойте, нет, это уже из другой истории.

Ну так вот. Взаимодействие с компьютером при помощи командной строки подразумевает модель «действие — объект». (Т.е. «команда — файлы».) Работа в графическом окружении, наоборот, подразумевает модель «объект — действие». Сначала пользователь выбирает при помощи графического интерфейса объекты, затем выбирает действия, производимые с ними. Действия выбираются из меню. А это значит, что везде, где доступны некоторые объекты, должны, из соображений регулярности и предсказуемости пользовательского интерфейса, быть доступны и действия над ними. Везде — значит везде.

На уже упомянутом тулбаре:



В меню Пуск:



В утилите поиска файлов:



В стандартном диалоге открытия/сохранения. (Скриншот забыл сделать, так что верим мне на слово. :} )

Эта особенность Windows является одной из флудоносных тем на форумах, посвященных линуксу. Ведь в линуксовых DE, как вы знаете, нет ни универсального файлового меню, ни даже попыток его создать. (Ну если не знаете, то вот теперь узнали.) Вне зависимости от того, сколько раз форумные бойцы повторят «не нужно», «нефиг тащить дурные привычки» и «проводник — говно», с точки зрения принципов проектирования пользовательского интерфейса это по-прежнему крутая и нужная фича, повышающая предсказуемость UI и снижающая число лишних переключений фокуса внимания во многих use cases.

Я даже наберусь наглости сказать, что данный подход к меню файлов по духу (но не по букве: реализация там говно) более юниксвеен, чем тот разброд, что по этому вопросу царит в графических средах для линукса.

Ну и раз уж мы открыли утилиту поиска, то рассмотрим и её. Есть тут какие-нибудь полезные идеи?

Утилита поиска?

Ну на первый взгляд ничего особенного:







Критериев поиска не много, но и не мало. С универсальным языком запросов у find (1) это не сравнится, но для большинства типичных случаев вполне пригодно.

Кстати, а какие графические средства поиска (не являющиеся фронтэндами к демонам-индексаторам) вообще есть для линукс? Сразу вспоминается утилита gnome-search-tool. В принципе, она умеет и все те же критерии поиска, что виндовая утилита, и даже намного больше. Также есть catfish, который убог. Есть утилита в составе проекта EDE (который де факто мертв, поэтому она не считается). Наверняка есть и в KDE, но мне лень устанавливать что-либо KDE-шное, чтобы проверить.

У Xfce и LXDE подобных утилит нет. Так что для этих проектов наличие утилиты поиска файлов само по себе может являться идеей-которую-стоит-взять-на-вооружение. В самом деле, что же это за окружение графическое рабочего стола, если в нём нет штатного средства, чтобы ответить на вопрос «какие *.html файлы в каталоге проекта изменял Вася Пупкин вчера и позавчера»?

Но настоящее сокровище откроется нашим взглядам, когда мы перестанем разглядывать виджеты критериев поиска и обратим взор внутрь меню Файл. Вот оно:

Сохранение условий и результатов поиска.

Итак, что делает действие Save Search. Оно сохраняет условия и результаты поиска (либо только условия, зависит от настроек программы) в файл на рабочем столе. Двойной щелчок по этому файлу откроет утилиту поиска точно в том виде, в каком она была в момент сохранения: с тем же текстом в полях ввода, с теми же строками в таблице результатов.

Выбора, куда сохранять, нет. Всегда сохраняет на рабочий стол. (В самом деле, вам вряд ли понадобится тусовать эти файлы-сейвы по каталогам.) Имя файла выбирается автоматически на основе условий поиска. (В самом деле, вы вряд ли захотите дать результатам иное имя, чем «Поиск по txt», если вы искали по *.txt.)

Я считаю это невероятно крутой вещью. Как по задумке (сама идея сохранять условия и результат), так и по реализации (два клика на сохранение, два клика на восстановление; ничего лишнего).

Следующая идея:

Справка на что угодно через контекстное меню.

Ну как бы всё очевидно — нажал правой кнопкой на практически любой элемент, получил краткую справку:





К сожалению, «что угодно» на самом деле совсем не что угодно. Во многих случаях контекстной справки нет, либо она довольно бестолкова. Тем не менее, на фоне тотального бардака в справочной системе наших DE, это просто сокровище. Ну я думаю, вы знаете: кто видел справку на приложения KDE, тот над шуткой «в Windows плохая справочная система» больше не смеётся. Фееричные руководства вида «А вот это меню Правка, а вот и список его пунктов» (скопипасченный прямо из исходников, вполне вероятно), которые писались не вполне трезвым Капитаном Очевидность. (Дабы поддержать баланс добра и зла, добавлю, что в Gnome ситуация со справочной системой принципиально не отличается.)


Ну а теперь вещь, ради проверки которой я и установилполез в Windows (еще до того, как мне пришла в голову идея этой статьи):

Непротиворечивое использовани мыши и клавиатуры в виджетах TreeView и ListView.

В приложениях, написанных на Gtk, с этими виджетами просто беда какая-то.

Вот возьмём типичное использование этих виджетов: отображение содержимого директорий. Тут имеют смысл два типа пометок обьектов: текущий и выделенный. Выделенные обьекты — это те, с которыми будут производиться любые операции. Текущий — это тот, который имеет пометку «вот тут находится клавиатурный курсор». В обычных условиях выделенный == текущий. Однако удерживая Ctrl или Shift, можно выделить произвольное число файлов (а курсор при этом может стоять на невыделенном файле).

Так вот. Если мы берём идею «операции производятся с выделенными объектами», то давайте следовать этой идее! В Gtk-шных же приложениях всё перепуталось. Если выделение находится одном файле, а курсор на другом, то Shift+F10 открывает меню для выделенного файла — верно. А вот enter выполняет действие над файлом под курсором, а не над выделенным — неверно! (Воспроизводится в: pcmanfm, thunar)

С мышью еще интереснее. Либо мы принимаем идею «левый клик выделяет, правый клик открывает меню для выделенных файлов» (так сделано, например, в PathFinder). Либо мы принимаем идею «выделять можно и левым, и правым кликом, но правый еще и открывает контекстное меню» (так сделано, например, в Проводнике). В pcmanfm решили сделать и не так, и не эдак. Левый клик выделяет объект. Если кликнуть по пустому пространству, выделение сбрасывается. Всё верно. Правый клик выделяет объект и открывает контекстное меню. Если сделать правый клик по пустому пространству, выделение не сбрасывается, и контекстное меню открывается не для вмещающего каталога, а для выделенных объектов. А вот это уже неверно!

В thunar, к слову, это работает правильно. В Проводнике — тоже:



Еще один вкусный баг: пункты боковой панели в файловых менеджерах. Этим пунктам приходится работать в трёх ипостасях: и как кнопка, по нажатию открывающая соответствующий каталог, и как объект, имеющий собственное меню и собственный набор действий, и как индикатор «сейчас открыт такой-то каталог». Всё бы ничего, но состояний у них всего два: выделен, либо не выделен. И поэтому фейлится либо роль обьекта с собственным меню (use case: щелкаем правой кнопкой, чтобы открыть меню; вместе с этим происходит активация кнопки, происходит переход в соответствующий каталог — fail). Либо роль индикатора (use case: щелкаем правой кнопкой, чтобы открыть меню; объект выделяется (это нужно, чтобы было видно, к какому обьекту открыто меню), но перехода в каталог не происходит — fail). Второй фейл, тем не менее, предпочтительнее первого, так что в thunar и pcmanfm реализован именно он.

Теперь, вместо отдельных пунктов, рассмотрим дерево каталогов в боковой панели. Суть та же, выделение означает 2 взаимоисключающие вещи: 1) этот каталог открыт; 2) к этому каталогу открыто контекстное меню. pcmanfm гордо не имеет поддержки контексного меню в дереве каталогов (то ли не планируется. то ли еще не реализовали), и этим решает проблему на корню. А вот thunar опять фейлится по тому же сценарию.

Но как же выйти из затруднения? Дерево каталогов Проводника подсказывает нам решение: следует использовать две разных метки. Конкретно в случае Проводника, метка изменением цвета фона означает «к этому каталогу открыто контекстное меню», а метка пунктирным контуром — «этот файл открыт на основной панели». Если контекстное меню не открыть, обе метки стоят на одном и том же каталоге. Если щелчком правой кнопкой мыши открывается меню для какого-либо узла, первая метка смещается на этот узел, а вторая остаётся на своём месте. После закрытия меню, первая метка возвращается к первой.



Вы можете подумать, что я зря потратил время, так подробно описывая эти небольшие (и не сказывающиеся на функциях программ) баги в интерфейсе. Однако пара этих багов — лишь частные случаи общей проблемы: графический интерфейс программ под линукс непредсказуем. Взаимодействовать с таким интерфейсом — всё равно что пользоваться отверткой с ручкой, которая впивается в руку, или носить неудобную обувь. Каждый раз, открывая даже стандартный с виду интерфейс, пользователь вынужден задать себе вопрос: что ожидать от него? Что делает левый клик, а что — правый? У каких объектов есть контекстное меню? Работает ли прокрутка как ожидается? Как программа реагирует на «стандартные» (даже в пределах тулкита) хоткеи? С какими вещами fd.o программа совместима? И так далее. Всё это делает работу с графическими приложениями в линукс несколько неприятной. GUI и так «не подарок», и для многих задач эффективнее использовать интерфейс командной оболочки. Однако есть задачи, которые всё же эффективно можно решить только в GUI. И вот тогда приходится сталкиваться со всеми этими проблемами.

Впрочем я уже далеко отклонился от изначальной темы статьи, и потому пора закругляться. Переходим к выводам:

Что делать?

Вы можете задаться вполне закономерным вопросом: ну написал автор всё это, и что дальше? Зачем он это писал? Кому это надо?

Лично я извлёк из экскурсии в прошлое «вражеской» системы несколько дельных идей.

Во-первых, панель задач. Возможность выделить несколько окон при помощи Ctrl+щелчок я занесу в TODO-список для LXPanelX. Команды для тайлинга также могут быть полезны. Поскольку возможность добавлять в меню окон «внешние» команды запланирована на один из будущих релизов, то тайлинг вполне может выполняться внешней утилитой, а в самой панели достаточно только добавить команды в меню. Так что непосредственно панель задач никаким тайлингом заниматься не будет, но возможность для пользователя сделать такую вещь — будет.

Во-вторых, тулбары из каталогов. Такой апплет также запланирован для LXPanelX. (Вероятно, можно доработать апплет dirmenu для этого.)

В-третьих, графический фронтэнд для различных поисковых утилит и движков. Да, мы работаем над этим. :-D Анонс проекта сделаю позже, когда код перейдёт из категории «не тянет даже на препреальфу» в категорию «более-менее работает». Кто из вас бывает на LOR-е, возможно уже видели в одном из моих тредов в ссылку на репозиторий проекта.

Что касается проблемы контекстного меню файлов, то эта задача слишком всеобъемлюща, чтобы быть под силу одному скромному блоггеру. Но мы думаем над этим, так же как и вы, дорогой читатель. И кто-нибудь из нас до чего-нибудь додумается и когда-нибудь напишет код.

На этом всё. Археологическую экспедицию можно считать оконченной.

P.S.
На прошлой неделе я обещал несколько статей о принципах устройства различных подсистем Linux. Я не забыл об этом, скоро первая будет опубликована.