Новый камень Торвальдса в огород Gnome

> Извиняюсь за офтоп, но нигде не нашел ответа на такой вопрос - каким образом сделать open/save диалог case insensitive т.е. чтобы директории на "а..." шли сразу за директориами на "А...."?

Наверно, в реестре :)

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

Приведите, пожалуйста, тот критерий, на основании которого Вы ругаете диалог гтк - разумеется, личные необоснованные "удобно"/"красиво"/"привык"/... - идут лесом сразу.

> А как выключить "пятницу" в списке файлов? "Сегодня" еще туда-сюда... но "пятница"...

Злодеи. Пятницу выключить хотят.

Робинзон

>> Даа, приняли серьезный патч...

>Если Вы на мгновение включите внимание, то обнаружите, что приняты все четыре патча к метасити. Всего было шесть патчей. Два других -- в gnome-control-center. Кончайте троллить уже.

Я всего лишь открыл вашу ссылку - "diff to previous" - а там такое :)

>AP ***** (*) (19.02.2007 17:36:03)

> Для _вас_ не принципиально насколько _качественно_ с точки зрения восприятия сделаны диалоги приложений.

С точки зрения чьего восприятия? :)))

Ну вообще-то по ссылке перечислены изменённые файлы и дано описание изменений :) Кстати, я ошибся. Патчей в метасити было пять :))

из tty1 они строку стырили: там нет кнопки "go" и отчистки поля ввода -> клаву нужно всегда держать под рукой

> Приведите, пожалуйста, тот критерий, на основании которого
> Вы ругаете диалог гтк - разумеется, личные необоснованные
> "удобно"/"красиво"/"привык"/... - идут лесом сразу.

Пожалуйста. Только "удобно"/"красиво"/"привык" не могут "идти лесом"
по простой причине - интерфейс для человека, а не машины. И человеку
_свойственно_ воспринимать свое окружение в терминах удобно, красиво и
привык. Другое дело насколько это соотностится с поднимаемой
проблемой.
Постараюсь быть конструктивным и обосновывать использование удобно,
красиво и привык.

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

2. Адрес (путь) отображается в трех (насколько я понял) местах и везде
по разному - излишество и дополнительная путанница для
неподготовленного пользователя.

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

4. Общий стиль не сохранен: кнопки добавить/удалить имеют текст, а
какая-то кнопка в верхнем левом углу нет и мне не понятно что она
должна делать. Учитывая, что ее внешний вид (граф. изображение) может
меняться в зависимости от установленной темы становится совсем
грустно.

5. В этом окне не понятно как сделать фильтрацию не только по типу а
вообще (имя файла, дата).

6. Подобное представление ФС (множественные директории) не всегда
удобны - нет возможности быстрого переключения в "классический" режим.

7. Есть кнопки добавить / удалить, но нет переименовать, скопировать и
т.д. - эти действия нельзя делать над документом? А если можно, то
почему идентичные действия нужно делать разным путем.

Ну и о свободном месте... Перечисленный отсутствующий функционал
запросто можно разместить в этих местах.

Также наличие пустот (то, что не входит в зеленые блоки) ни чем не
обосновано и не улучшает восприятие формы.

> Пользователь запросил возможность переименования/удаления файлов из диалога открытия/сохранения. Мейнтейнер попросил патч -- патч пришёл.

Что, неужели оно будет? Просто праздник.

>В нужный каталог я попадаю в Gtk+/Qt с одинаковой или несущественно различающейся скоростью.

Кстати, а как в gtk-шном диалоге перейти в указанный каталог, путь к которому я ввёл?

> Ну теперь-то уж точно всем будет ясно, что Gnome - отстой :)

теперь всем будет ясно, что Торвальдсу жена-каратистка точно мозги отшибла... :)

Нажать ввод? :)

нужно предложить KDE-шникам в качестве эксперимента портировать Konsole и Konqueror под GTK...
тогда посмотрим, на сколько сократиццо кол-во юзающих KDE... ;)

1. Последовательности в расположении нет. Есть некая внутренняя логика. Что важнее.

2. Путь отображается в двух местах (сорри, третьего не вижу). Одно из них - путь текущий, отображенный в списке файлов (кнопки на самом верху). Второе - путь желаемый, который пользователь еще только собирается отобразить (поле ввода, чуть пониже). В терминах MVC одно является V, другое C. Где третий?

3. Извините, но мне почему-то очевидно, что добавление относится к списку каталогов. Впрочем, я бы список "мест" сократил по высоте - чтобы суммарная высота списка вместе с кнопками была равна высоте списка файлов. Так было бы яснее ИМХО.

4. Вот это, пожалуй, да - иконочная кнопка среди текстовых действительно обескураживает.

5. Это уже advanced feature. Неочевидна необходимость.

6. Классический режим порой вызывает сложности у неподготовленных, вообще-то. Но если уж так хочется - в списке "мест" всегда есть корневой каталог. Или Вы о чем-то другом?

7. Кнопки "добавить" и "удалить" относятся к "местам", а не файлам. При чем тут перемещение и переименование?

Насчет свободного места - предложенный Вами mockup смотрится безумно из-за отсутствия свободного места между виджетами. Не то чтоб нельзя было сделать компактнее, чем оно есть - но предлагаемое просто безумный экстрим. Все-таки 6 пикселей между виджетами - это разумное требование HIG.

>Приведите, пожалуйста, тот критерий, на основании которого Вы ругаете диалог гтк

Пусть лучше приведут концепт-арт идеального с их точки зрения диалога. :)

а если ввод лежит где-то в двух метрах от руки или ноги ?

Что я, кдешных диалогов не видел?;)

А чем тогда свой путь набирать?.. ;)

Похоже, Вы пытаетесь выдумать юзкейс :)

У Вас адрес каким-то непостижимым образом набран, а клавиша ввода вдруг оказалась вне пределов досягяемости. Вы используете две клавиатуры, на одной из которых нет этой клавиши? :)))) Или Вы отвернулись, а в этот момент клавиатуру маленькие зелёные человечки похитили? :)))

есть такие волшебные вещи как копипаст их в гноме тоже вырезали ?

Как и везде -- обычный и мышиный. Вы тему исчезнувшей клавиши ввода-то раскрывать будете? :)

> Извиняюсь за офтоп, но нигде не нашел ответа на такой вопрос - каким образом сделать open/save диалог case insensitive т.е. чтобы директории на "а..." шли сразу за директориами на "А...."?

сменить LANG=C на LANG="en_US", напр.

>Вы тему исчезнувшей клавиши ввода-то раскрывать будете? :)

Указательный палец к мышке прирос, а мышкой по клавиатуре стучать неудобно.

2svu:
> 1. Последовательности в расположении нет. Есть некая внутренняя
> логика. Что важнее.
Не убедил. Пользователь видит внешнее и на основе этого выбирает модель
поведения. Про внутренную логику ему не вдомек ее он начинает
чуствовать интуитивно после _долгого_ пользования системой (или
прочтения HIG :)

> 2. Путь отображается в двух местах (сорри, третьего не вижу).
Будем опираться на действия пользователя: в горизонтальных блоках
выбирает путь до нужного файла. Каждая выбранная директория выделяется
и на основе этого выделения получается визуализация текущего пути.
Горизонтальная полоса прокрутки позволяет быстро перемещаться и
"охватывать" взором текущую позицию в ФС.
Это основные действия пользователя, ему просты и понятны. Путь в
верхней части он замечает _потом_ и эта информация является
второстепенной, излишней.
Аргумент, что из-за вертикального скроллинга одна из выбранных ветвей
может быть не видна возражу тем, что сам путь также может не вмещаться
в горизонтально пространство для верхней строчки.

> 3. Извините, но мне почему-то очевидно, что добавление относится к
> списку каталогов.
Чем очевидно? Я привел аргументацию почему это не очевидно. С вашей
стороны только личные эмоции.

> 5. Это уже advanced feature. Неочевидна необходимость.
На самом деле гораздо более важная чем ввод полново пути к файлу.
Лично мне вместо нее не хватает поисковой строки которая будет искать
файлы не только по имени, но и доп. (мета) информации. К тому-же такой
движок у GNOME есть и самое логичное для него место это в диалоговом
окне на открытие файла!

> 6. Классический режим порой вызывает сложности у неподготовленных
Я, несколько о другом. Это когда содержимое текущей директории
показыватеся в виде крупных пиктограмм и при этом показыватся preview
для мультимедиа и текстовых файлов.

> 7. Кнопки "добавить" и "удалить" относятся к "местам", а не файлам.
Упс. А что это за термин "места"?

> Насчет свободного места - предложенный Вами mockup смотрится безумно
> из-за отсутствия свободного места между виджетами.
Это уже придирки, да вы и сами это прекрасно понимаете. Или вы хотите,
что бы я за 5 мин. в примитивном граф. редакторе сделал из исходного
плоского рисунка идеал?

Какая нелепая, чудовишная смерть :)

1. Безусловно - ощущение внутренней логики приходит с опытом. Гном это не отрицает. Гном только старается, чтобы внутрення логика была непротиворечивой в рамках всего десктопа.

2. Предлагаемая Вами модель удобна, когда приходится работать с глубокими иерархиями. В случае, если иерархии ограничиваются 1-2-3 уровнями - она ИМХО является чрезмерным усложнением. Для того, чтоб пользователь не испытывал проблем со слишком глубокими структурами - придуманы "Места" (крайняя левая колонка).

И еще - сочетание сочетание выбора в "Местах" (левая колонка) и текущего каталога (средняя колонка) - может не давать точного представление о том, где реально находится пользователь. Так что на "третий способ представления" оно не тянет. Например, если текущий каталог будет ~avp/CVS/gnome-applets/po - в левой колонке будет выделен avp, в средней - содержимое каталога po - и средние элементы пути(CVS, gnome-applets, po) можно будет увидеть только сверху.

3. Это не эмоции, это ощущения. Да, разумеется, личные. Вообще, очевидность и не очевидность - вещь довольно субъективная. Почему очевидно? Потому что кнопки находятся ближе к списку "мест".

5. В гноме есть отдельный апплет для desktop search - там Вам и бигл и пр. удовольствия. Некоторые самые продвинутые даже заявляют, что при наличии оного диалог открытия файлов можно списать на свалку истории;) В принципе - да, хорошо б их сынтегрировать. Но такие вещи с кондочка не делаются - надо подумать, обсудить. Подождите пару релизов гнома;)

6. Вы не перепутали диалок открытия с файловым менеджером?

7. Упс. А вы обсуждаете диалог открытия файлов, даже не поняв, что такое "Места"? (см заголовок самого левого списка). Это фактически список filesystem bookmarks, которые могут содержать ссылки на любые каталоги файловой системы.

Безусловно, я придирался. Но я хотел подчеркнуть - нельзя бездумно гоняться за компактностью интерфейса. Сама по себе компактность обладает крайне низким, практически нулевым, приоритетом - если мы не говорим про всякие PDA/Internet Tablets/Smartphones/...

> Я, несколько о другом. Это когда содержимое текущей директории показыватеся в виде крупных пиктограмм и при этом показыватся preview для мультимедиа и текстовых файлов.

Эскизы -- разумный запрос. Есть одна тонкость. В гноме эскизы генерятся разными программами и вне гнома это может не работать.

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

> Сама по себе компактность обладает крайне низким, практически нулевым, приоритетом

Не совсем так. Поработай постоянно с GIMP на 1280х800 месяцок-другой -- и ты сразу захочешь уменьшить виджеты и диалоги :)

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

Есть ещё чисто эстетический момент: года полтора назад самолично запостил баг с просьбой убрать пять кнопок в ряд в диалоге параметров сохранения в PNG :) Это было ужасно, хотя работать не мешало :)

2svu:
1. За деревьями (внешним видом) не видно леса (внутренняя логика)

2. ... В случае, если иерархии ограничиваются 1-2-3 уровнями ...
У нас UNIX? И пользователь чаще всего работает со своими,
пользовательскими документами? Тогда уровень иерархии зашкаливает за 3:
/home/user/Public/.....
/home/user/Documents/.....
/home/user/Video/.....

И никто не заставляет делать представление от корня. От хомяка
достаточно в большинстве случаев. Если нужно выше, то ваши "места" с
этим отлично справятся.

> 3. Это не эмоции, это ощущения. ... Потому что кнопки находятся ближе
> к списку "мест".
Зы. провел местный опрос, на этом скрине, только зеленые квадраты 100%
плотности. И половина посчитала, кнопки по горизонтальной привязке.

> 5. В гноме есть отдельный апплет для desktop search - там Вам и бигл
> и пр. удовольствия.
Я работаю в _приложении_. Мне _нужен_ файл. Я вполне логично хочу
_открыть_ его. Для этого использую диалог по _открытию_ файлов.
И _не_могу_сделать_поиск_нужного_мне файла.
Оказывается для этого есть другая вещь, которая находится где-то вне
_нужного_в_данный_момент_ мне приложения.
Очень разумно сделанно...

> ... Подождите пару релизов гнома;)
Так и до куммунизма не далеко :)

> 6. Вы не перепутали диалок открытия с файловым менеджером?
Нет, совсем нет. Я просто оцениваю диалог на возможность выполнения
частых функций при работе с _приложением_, отличным от файлового
менеджера.


> Сама по себе компактность обладает крайне низким
Это все понятно. И я не гоняюсь за компактностью. Я просто повторяю,
что _пустые_ места должны быть оправданны. В данном диалоге - нет.

А ты думаешь зачем в Gtk нативные бэкенды пишутся для винды и макоси? :)

> Поработай постоянно с GIMP на 1280х800 месяцок-другой

"Доктор, мне больно, когда я так делаю. - А Вы так не делайте". Интересно, что будет, если запустить гимп на Nokia N800...;)

На самом деле - конечно, бывают специальные случаи. Но в общем случае, ясность и логичность интерфейса важнее его компактности, isn't it?

> Я работаю в _приложении_. Мне _нужен_ файл. Я вполне логично хочу _открыть_ его. Для этого использую диалог по _открытию_ файлов.

Дело в том , что есть proof-of-concept патч использования beagle внутри диалога открытия файлов :)

> Эскизы -- разумный запрос. Есть одна тонкость. В гноме эскизы
> генерятся разными программами и вне гнома это может не работать.

Тогда так: гномовские приложения могут запускаться вне гнома?
А их диалог не может - обломс. Мдямс.

Т.е. ограничение интерфейса в ущерб удобности на самом деле объясняется
не ненужностью, а сложностью корретно работать в гетерогенном
окружении. А мы то думали, что во всем HIG виноват :)

>"Доктор, мне больно, когда я так делаю. - А Вы так не делайте".
> Интересно, что будет, если запустить гимп на Nokia N800...;)

Вообще-то разрешение 1280х800 - очень хорошее, и далеко не у всех оно
доступно. Большинство на 1024 сидит.

По ходу опять оправдание не умения строить интерфейс за счет ненужности
пользователям. Мдямс... Грусно это... А мы-то думали во всем виноват
HIG :)

>Как пример: http://idisk.mac.com/alex.dederer/Public/002_dialog.gif

ага, взял и кнопки с каталогами выкинул - мне к примеру удобно или вы не в курсе, что там за кнопка с "avp" была и что они в основном всю строку занимают?

+ и - вообще песня :))) эти кнопки относятся к среднему окну - вы очевидно решили, что добавлять будут только путь? вы ошиблись! ;)

поздравляю! лужа газифицирована :)

> Извиняюсь за офтоп, но нигде не нашел ответа на такой вопрос - каким образом сделать open/save диалог case insensitive т.е. чтобы директории на "а..." шли сразу за директориами на "А...."?

LC_COLLATE ?

> Дело в том , что есть proof-of-concept патч использования beagle
> внутри диалога открытия файлов :)

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

А как оно будет работать в неродном окружении, да еще в другой среде
(Mac OS X, к примеру). Скорее всего просто оторвут.

2AcidumIrae - пишите, Шура, пишите.

> Интересно, что будет, если запустить гимп на Nokia N800...;)

Свен грозился сделать специальный порт :)

> На самом деле - конечно, бывают специальные случаи.

Именно. Слишком большой padding в ряде случаев не нужен. В программах типа GIMP, где плотность населения виджетов на квадратный метр как в Китае, как раз таки лучше нарушать правила.

А вот если мы говорим о программах типа баньши или ритмбокса -- для офисного, таскть, планктона, где бОльшую часть интерфейса составляют большие списки и тому прочее, тут хигнутые диалоги уже рулят :)

>Т.е. годика через два будет то, что пользователю реально будет удобно сейчас. Мдямс.

Не вам, Эра Георгиевна, говорить от лица народа.

>2AcidumIrae - пишите, Шура, пишите.

так бы и сказали, что нечего ответить ;)

только не надо рассказывать сказки про "эффективное использование_ пространства окна" :)))

> Не вам, Эра Георгиевна, говорить от лица народа.
Анонимусы подтянулись :)
Зы. Если не заметил, тебя не трогал, а написал в "пользователю" - в
одном лице, т.е. о себе.

Не читайте по утрам советских газет.

2. Я о том и говорю - если использовать "Места" (о ужас, надо переходить на английский) - кол-во уровней укладывается в 1-2, в основном - и тогда бессмысленно текущее представление вполне осмысленно ИМХО. Адрес (который действительно замечаешь сверху совсем не сразу) - практически не нужен.

3. Это "неправильная" половина ("... и они дают неправильный мед" %)

5. Вот это существенно. Вы работаете с приложением. А некоторые - с десктопом. Это принципиальное философское различие. Кстати, насчет "нужного Вам приложения". Нет никакого "нужного приложения", на самом деле. Есть нужная функциональность. А каким образом ее реализует сочетание софта и харда - вопрос вторичный. На всякий случай - это не оправдание отсутствию интеграции бигла в диалог открытия файлов, это объяснение, что решение, в котором приложение как таковое вообще не имеет такого диалога, а пользовательский интерфейс использует некий обобщенный компонент (апплет, демон, whatever) десктопа - вполне имеет право на существование.

6. И вот реализация этих функций сделает из диалога толстый файловый менеджер. Нафига? Я уже (в другом флейме) согласился - файловому диалогу просто не хватает кнопки "открыть окно наутилуса для этого каталога".

Насчет пустых мест - да, некоторые пустые места можно было бы ужать. Но предлагаемое Вами решение - увы, хуже оригинала. В нем отсутствует информация о текущем пути и совершенно убита юзабилити модификации списка "мест".

На самом деле, хорошо б в дискуссии использовать картинки стандартного диалога, без гимповых расширений (и, пожалуй, без локализации - как-то меня от "Мест" корежит..)

> так бы и сказали, что нечего ответить ;)
так бы и сказали, что читать не умеете :)


> только не надо рассказывать сказки про "эффективное использование_
> пространства окна" :)))

конечно! только после вас!

Нет торогал, как пользователя. Если тебе что-то не нравится, то это не значит, что это не нравится другим. Можешь доказывать всем как было бы хорошо, если бы... но не навязывай свое мнение. Если говоришь от себя, то пиши не пользователю, а мне.

> сложностью корретно работать в гетерогенном окружении

Что значит "сложностью"? Вы ж сами будете материться, если гномовское приложение будет инициализировать диалог открытия файлов полчаса (запуская компоненты для превьюшек)! И еще Вы посмОтрите на то, насколько "просела" система в смысле потребления памяти - и тоже не забудете пнуть. Извините, но пока нет компонентной модели, общей для всех десктопов - превьюшки в диалоге открытия файлов будут дорогим удовольствием.

ЗЫ Кстати, а как делаются превьюшки при открытии файлов в кде - что-то я не обращал внимания?

2svu:

> 2. Я о том и говорю - если использовать "Места" ...
С "местами" тоже не все так просто, при их использовании получается
сложней оценить текущее положение в файловой структуре (или я их не
умею готовить?)

> 5. Вот это существенно. Вы работаете с приложением. А некоторые - с
> десктопом...
Имхо передергивание. Поясню.
Предпосылка 1:
Нужный мне от компьютера функционал находится в приложениях.
Неважно в каких - консольных или графических. Только в случае консоли
shell выступает в роли десктопа.

Предпосылка 2:
десктоп предназначен (с точки зрения пользователя) для обеспечения
более эффективного выполнения задач которые нельзя (сложно) выполнить
с помощью одного приложения.
К примеру: требуется получить архив директории. Выполняем:
tar .... | gzip .... > some.tgz
В этом примере используем _два_ _приложения_ и возможность консоли:
pipes и перенаправление вывода в файл.

Вывод (упрощенный):
Какой функционал можно выполнить в окружении не прибегая к приложениям? Это я к тому, что "а некоторые - с десктопом" является передергиванием в данном контексте.

Кстати да, "места" очень удобны, большая часть действий всё-равно в двух-трёх папках.

some anonymous:
> [здесь идет не переводимый словесный поток]Если говоришь от себя, то
> пиши не пользователю, а мне.

Хм, а я что, не являюсь пользователем?