[аналитики] Нужно мнение о принципиально новом интерфейсе

Контекстно зависимый интерфейс: Раскин переворачивается в гробу.

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

Я задолбался слушать, лучше б ты текстом написал.

Хорошо, годно. Во всяком случае, мне пригодится. На чем реализована библиотека?

> Контекстно зависимый интерфейс: Раскин переворачивается в гробу.

А когда Enter по каталогу и Enter по текстовому файлу приводят к выполнению разных действий, Раскин в гробу не вертится? Не доводи до маразма идею-то.

Что за файловый менеджер у тебя?

Насколько я понял это больше для тайлщиков?

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

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

Оно умеет заменять костыли для глобального меню? В смысле быть глобальным меню для пользователей мелких экранов? Если да, то это будет чуть ли не единственным юзкейзом.

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

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

Я задолбался слушать, лучше б ты текстом написал.

Я как-то пробовал субтитры делать на трехминутное видео — убил час. Поэтому прошу прощения за путанные мысли, слова паразиты и непоследовательность изложения.

На чем реализована библиотека?

Угадай с одного раза :)

Что за файловый менеджер у тебя?

Не понял вопроса.

Попов, ты опять выходишь на связь?

> А когда Enter по каталогу и Enter по текстовому файлу приводят к выполнению разных действий

Каталоги и файлы не нужны. Спроси Раскина об этом.

Оно умеет заменять костыли для глобального меню?

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

пользователь может не заметить фичу

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

выглядит так, как будто хочет многочасовой настройки

но держать в голове тонну мусора не слишком удобно.

Тут каждый думает сам, сколько сочетаний клавиш помнить. Мне кажется, uxie решит главную проблему snaked — в нем вообще невозможно работать не выучив два десятка шоткатов.

> > На чем реализована библиотека?

Угадай с одного раза :)

Нет, только не он!

> Что за файловый менеджер у тебя?

Не понял вопроса.

Уточную: где лежит репозиторий этого твоего велосипеда?

Впрочем, всвязи с предыдущим, вопрос не актуален.

Каталоги и файлы не нужны.

Шоткаты тоже не нужны?

> Каталоги и файлы не нужны. Спроси Раскина об этом.

Ну как же, нужна большая объектная помойка с зум-навигацией. Закопать эту безумную идею вместе с Раскиным.

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

Если добавить инкрементальный поиск по меню, будет юзабельно.

> > Каталоги и файлы не нужны.

Шоткаты тоже не нужны?

Да компьютер вообще не нужен. Печатной машинки достаточно всем!

Отличная мысль, кстати.

Очередной велосипед.

Пиши пока в ящик, вернее на свой винт.
Как проведешь более глубокий анализ аналогов, тогда приходи.

Честно просмотред 50% скринкаста. Не вдохновило.

Если добавить инкрементальный поиск по меню, будет юзабельно.

Надо будет попробовать. Ничего сложного, вроде, нет.

Как проведешь более глубокий анализ аналогов, тогда приходи.

Каких аналогов? Таких не знаю. Встречал только одно убожество по части шоткатов.

Вот кстати.

Остро не хватает не привязанного к файловому менеджеру и среде протокола для ассоциирования действий с типами файлов. *.desktop-файлы и ассоциации mime-типов с ними — это не то; нужен универсальный подход, использующий идентификаторы действий, а не названия конкретных приложений.

Разработчики файловых менеджеров задолбали велосипедить свои костыли, вместо того, чтобы собраться где-нибудь и выработать общий протокол, который можно было бы потом смело добавлять в спецификации fd.o.

Как plumbing в plan9? Только fd.o-версия plumber'а должна работать через dbus

Остро не хватает не привязанного к файловому менеджеру и среде протокола для ассоциирования действий с типами файлов

Ну, вроде, есть xdg-open c xdg-mime.

а что, идея понравилась

Контекстноме меню файлов хотелось бы формировать полностью динамически.

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

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

> > *.desktop-файлы и ассоциации mime-типов с ними — это не то; нужен универсальный подход, использующий идентификаторы действий, а не названия конкретных приложений.

Ну, вроде, есть xdg-open c xdg-mime.

Я знаю, что я плохо умею объяснять. Но всё-таки.

-Здравствуйте, товарищи Лоровские аналитики!
-Здравствуй, Слоник!

Идея довольно интересная, до конца, честно говоря, недосмотрел, но про вставку - лучше писать, что в буфере есть файл, а то непонятно откуда в контексте paste берётся

Абсолютно негуманоидный подход.

Это я про выкладывание видео вместо нормального текста. И нет, «нормальный текст» не означает «субтитры к видео».

нормальный текст

Нормальный текст будет в документации, а это пока только более/менее рабочий пруф.

а то непонятно откуда в контексте paste берётся

Это уже свистелки, к делу не относятся. Не думаю, что вообще буду релизить fmd.

Суть ясна, но не видно киллер-фичи этих контекстов.

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

но не видно киллер-фичи этих контекстов.

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

На примере редактора: есть контекст поиска и контекст просмотра результатов тестирования. Как правило, для навигации по найденным совпадениям и провалившимся тестам используют разные сочетания клавиш. Но по смыслу действие то одно! Так вот, мои контексты помогут не плодить стопитсот разных шоткатов на одинаковые действия, у меня он будет один.

когда тебя начнут троллить по-взрослому.

Давай уже свои аналоги, не стесняйся.

Чувак, всё правильно делаешь, только не называй это, пожалуйста, «принципиально новым интерфейсом». Контексто-зависимые меню потому и назвали контестно-зависимыми, что они, типа, контекстно-зависимые. Правда, большую часть этой логики обычно хардкодят, а у тебя получился прикольный формализм для описания контекстов и действий. Я бы в своих кедах от такого не отказался, например. Давайте напишем во fd.o, пускай примут такой стандарт, а фигли.

Я был бы скорее за «открытые кишки»: приложение сообщает, какие действия оно умеет выполнять, предлагает им названия (возможно, локализованные), шорткаты и прочие хинты, а некий глобальный менеджер делает из этого меню, глобальное меню, dmenu, распределяет хоткеи с учётом пересечений, возможно даже назначает жесты и вообще делает что угодно и дёргает функции приложения через что-нибудь (да хотя бы dbus, но любители сетевой прозрачности будут против, а если показать им телепатию как сетевую прозрачность в dbus — закопают). Но это больше относится к главному меню, а не контекстному. С контекстным интереснее подход geekless'а с едиными командами для действий над объектами. Ну или сабж.

Заметтье вставки нет, появляется если скопировать в буфер обмена — киллер фича.

В упрощённом виде это уже реализовано в оболочках медиа-проигрывателей, вроде Dune. :)

это уже реализовано в оболочках медиа-проигрывателей

Там всегда один контекст, насколько понимаю. Поэтому у пользователя WTF не возникает.

Мне нравится. Хотелось бы ещё шоткаты с использованием кнопок мышки. Хотябы даблклик.

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

в чём новизна идеи, кроме того что шорткаты устанавливаются именно в меню

Как раз, это старо. Слизал у gtk.

Вроде в KDE и так можно задать любые комбинации для чего угодно.

Это каким образом?

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

Ну запоминать нужно всё равно пары сочетание-действие, разве нет?

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

Почему все строят интерфейсы по принципу «сначала найдём объект, потом решим, что с ним делать»? Это в принципе подходит для шатающихся по каталогам бездельников, ищущих как бы время потратить, чтобы глаза от экрана не отрывать, но мне всё же кажется более конструктивным думать сначала о том, что хочешь сделать, а уже потом искать объекты для операции. Соответственно, нужно вывернуть интерфейс наоборот: выбор операции -> выбор объектов. Это может быть менее эффективным, в случае если количество комманд(операций) сильно превышает количество объектов, ими обрабатываемых, но этого не почти никогда не бывает, IMHO.

А это даёт нам интерфейс в виде sh с умным автодополнением, т.ч. почти ничего не нужно изобретать.

Почему все строят интерфейсы по принципу «сначала найдём объект, потом решим, что с ним делать»?

Наоборот, этот принцип сходит на нет — хомячки не могут мыслить объектами, только действиями, что ведет к упрощению и одеревенению интерфейса.

А это даёт нам интерфейс в виде sh

На многих операциях этот интерфейс очень громко причмокивает. Массовое копирование файлов в разные директории, работа с содержимым архивов, история посещенных мест. Думаешь от хорошей жизни начал пилить fmd?

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

А слабо нажать кнопку «Menu» на клавиатуре?

Вывод: ненужный велосипед^2

Будущее за треугольными окнами, ящитаю.

А слабо нажать кнопку «Menu» на клавиатуре?

Смысл не в меню, а в шоткатах. Меню только как способ их настройки.

>На примере редактора: есть контекст поиска и контекст просмотра результатов тестирования. Как правило, для навигации по найденным совпадениям и провалившимся тестам используют разные сочетания клавиш. Но по смыслу действие то одно! Так вот, мои контексты помогут не плодить стопитсот разных шоткатов на одинаковые действия, у меня он будет один.

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

Запатентуй, продай некрософту и таким образом приблизь вендекапец.