LINUX.ORG.RU

Предлагаю проект: Semantic Window Management


0

3

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

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

Итак, необходимы механизмы взаимодействия приложений и компонентов DE, которые выведут GUI в юниксе на новый уровень интеграции. Предполагается, что протокол будет реализован поверх протокола Иксов, аналогично NETWM. Впрочем, я готов выслушать вменяемую аргументацию за реализацию средствами dbus. (Аргумент «Скоро иксы умрут из-за вейланда» адекватным не является.)

Назовём это всё Semantic Window Management, ну просто потому что надо хоть как-то это назвать. :)

Ключевые фичи, как я их вижу:

1. Вкладки.

Суть: Если окно приложения использует интерфейс на основе вкладок, от окна можно получить список вкладок, включая название, иконку и флаг, указывающий может ли вкладка быть закрыта. Окну можно посылать команды переключения и закрытия вкладок, а также отображать/скрывать встроенный в окно таббар.

Для чего: возможность интеграции вкладок в заголовок окна в WM и/или в панель задач.

2. Документы.

Суть: Если окно приложения используется для открытия одного или нескольких документов, от окна можно получить список документов, включая такую информацию, как URL документа, тип MIME, название и признак «документ изменен». Окну можно посылать команды переключения и закрытия документов, а также открытия новых документов.

Для чего: Интеграция списка документов в механизмы переключения окон. Создание документо-ориентированного интерфейса. Автогруппировка или сортировка окон, отображающих один документ (например, html-страница в редакторе и она же в браузере) или отображающих документы из одного каталога. Автоназначение окон для работы с файлами разных проектов на разные рабочие столы. Интеграция открытых каталогов в ФМ и диалоговых окон открытия/сохранения файлов. (Допустим, открыт каталог ~/somedir/ в thunar-е, и в это время в medit я выбираю «Сохранить как»; в диалоге сохранения на левой панели я увижу ссылку на этот каталог. Или же можно прямо через меню: Файл -> Сохранить в -> меню с выбором каталогов) Интеграция окон файловых менеджеров между собой. Ведение учёта недавно открытых / часто используемых файлов. Возможность скриптовой связки двух окон между собой по типу «файл, открытый в редакторе, автоматически показывать в браузере», «для файла, открытого в редакторе, автоматически отображать ФМ с соответствующим каталогом».

3. Действия.

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

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

4. Окна состояния.

Суть: Приложение может создавать дополнительные окна для отображения своего состояния, которые будут встраиваться в DE аналогично трею. Отличие от трея тут не столько техническое, сколько логическое: окно в трее — это маленькая иконка, которая обычно всегда видна, если виден сам трей. Окно состояния — это окно произвольного размера, которое видно только тогда, когда пользователь его самостоятельно добавил на панель, на рабочий стол и т.п.

Для чего: Приложение может использовать специальное окно для отображения своего состояния. Например: RSS-клиент — заголовки самых свежих элементов фидов, email-клиент — количество непрочитанных сообщений. Приложение может использовать любое число таких окон с разными именами, если это имеет для приложения смысл. По сути, это способ показа виджетов. DE может давать пользователю возможность размещать такие окна на рабочем столе, в панели, во всплывающих контейнерах и т.п. Выглядеть это может как боковая панель, как Плазма или же как плитка Metro в Windows 8 — зависит от DE.

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

Что требуется реализовать для достижения светлого будущего:

  • протокол Semantic Window Management.
  • библиотеки, инкапсулирующие работу с протоколом.
  • поддержку этих возможностей в некотором количестве распространённых приложений, достаточном для того, чтобы этим уже заинтересовались сторонние разработчики.

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

Итак, вопрос стоит следующим образом: найдётся ли среди посетителей ЛОРа, не довольных текущим положением вещей в десктопном линуксе, 5 человек, умеющих не только болтать, но и работать? Всего 5 человек, с навыками программирования и желанием улучшить своё рабочее место. По отдельности мы — толпа анонимных аналитиков, вместе — команда разработчиков.

Ответ на: комментарий от geekless

>Тулкитов дохрена, и будет еще больше

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

Ситуация «API для крутой фичи такой-то есть только в нашем тулките» — не нормальная

кто мешает сделать аналогичный api в других тулкитах?

в кедах вот есть интересные решения, которые при грамотном применении могут кардинально изменить принципы работы с системой и данными, например, kio или тот же nepomuk

кто мешает сделать более низкий аналог nepomuk? да сами пользователи, которые пользуются красноглазыми WM; им же find с locate хватает, зачем им эти «свистоперделки», вот и зачем было авторам nepomuk/strigi пыжиться для влюблённых в консоль и традиции? так что оставь идею великой унификации, вряд ли твои усилия оценят, если кто-то захочет пользоваться nepomuk, он на кеды пересядет, благо они лепятся пластично под свои запросы

anonymous
()
Ответ на: комментарий от anonymous

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

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

кто мешает сделать аналогичный api в других тулкитах?

Ничего не мешает, если есть интерфейс, не привязанный к тулкиту. А он таки есть или нет? Я зашел на сайт непомука, потыкал по ссылкам, ничего внятного не нашел, закрыл.

так что оставь идею великой унификации, вряд ли твои усилия оценят

Мне похрен на оценку моих усилий. Десктопный софт я делаю для себя, для своего удобства. Просто есть задачи, которые в одиночку не решить, надо несколько человек единомышленников. Кстати, надо скастовать в тред baverman-а, может у него есть соображения по теме.

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

geekless ★★
() автор топика
Ответ на: комментарий от geekless

Желание привнести хоть толику интеграции в современный иксовый десктоп вполне понятно и похвально. Но меня смущают несколько вещей.

* Проработанность, детализация, объем «стандарта». То есть, чем больше фич он будет описывать, тем сложнее будет API и тем больше кода будет на стороне приложения. Мне кажется очень легко пересечь черту, когда свой велосипед пишется проще/быстрее, вместо использования сторонней убербиблиотеки.

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

* Получается очень тонкая грань, требующая опыта общения со всевозможными неудобными приложениями/wm. Лично я вообще не представляю как можно формализовать подобную задачу.

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

Убербиблиотеки не предполагается. Заметь, что все части сами по себе независимы и самодостаточны.

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

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

Поясни, что ты имеешь ввиду. Как можно на уровне ОДНОГО приложения сделать средства взаимодейстия РАЗНЫХ приложений, не имея общего базиса?

geekless ★★
() автор топика
Ответ на: комментарий от geekless

Как можно на уровне ОДНОГО приложения сделать средства взаимодейстия РАЗНЫХ приложений, не имея общего базиса?

Приложение просто должно выставлять наружу средства для автоматизации. *Не важно как*. Через скрипты, через dbus, через управляющий сокет или через cli, вообще без разницы. У каждого приложения может быть любой механизм, главное, чтоб он просто был. Собственно, сейчас примерно так дела и обстоят. Этот зоопарк есть и будет, так как изначально средства разработки пресильно разношерстные. С этим надо смириться и принять как данность. Так как интеграция все-со-всеми не нужна, а только с ограниченным перечнем, то поддержка сторонних приложений сводиться к конечному количеству кода для их управления и не сильно сложна.

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

baverman ★★★
()
Ответ на: комментарий от baverman

А ты представь, что нет и не было единого стандарта на имена окон, их иконки, хинты и на команды управления оконным менеджером. ;) Ведь так как на конкретном компьютере стоит ограниченный набор ПО и «интеграция все-со-всеми не нужна, а только с ограниченным перечнем, то поддержка сторонних приложений сводиться к конечному количеству кода для их управления и не сильно сложна». В плане высокуровневой работы с документами ситуация сейчас такая же, как была бы с окнами в отсутствие ICCCM. И это совсем не такая вешь, которую невозможно улучшить в силу объективных причин.

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

Ну смотри. Мне ничего не мешает сейчас запилить в свою панель задач слепенный из говна и палок код для расширения меню кустомными пунктами. А потом запилить в 5 самых используемых мной приложений поддержку анонсирования в свойствах окон открытых в них документов. Пусть, это займёт неделю кодинга по вечерам. Еще дня три прибавим на то, чтобы на руби быстро слабать демон для ведения списка недавних документов и составления файлового меню, как я вот тут описывал: Предлагаю проект: Semantic Window Management (комментарий)

И для этого не нужны никакие стандарты, и результат я получу «прямо сейчас» (10 дней не срок, ага). И возникает вопрос. А что дальше? Весь остальной-то мир не подозревает о моих наколеночных поделиях.

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

geekless ★★
() автор топика
Ответ на: комментарий от geekless

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

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

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

geekless ★★
() автор топика
Ответ на: комментарий от geekless

а вот в винде можно экономить место по вертикали, размещая тулбар в заголовке окна

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

Ну это просто пример был, я тоже не думаю, что это сильно востребовано. Но вот из того же треда примеры. Обсуждаем проблему нерабочести глобальных хоткеев, когда открыто меню. Реплика в стиле «вот в винде же это работает так-то и так-то, неужели так же нельзя». Я говорю, да без проблем, пиши спецификацию, как между собой должны договариваться агенты о хоткеях и как они будут друг с другом взаимодействовать, если один из них захватил клавиатуру, и все не нужные себе нажатия отсылает остальным; если будет документ, я даже готов пропатчить gtk и парочку приложений для работы с хоткеями. Нет, сразу чуваку это стало «не нужно». Другой чувак хочет, чтобы DE ему показывало в диалоговом окне выхлоп stderr, если приложение, запущенное средствами DE, закрылось с ненулевым кодом ошибки. При чем чувак не просто хочет типа «окошко с ошибкой как в винде», а даже имеет представление, что конкретно должно быть. Я ради эксеримента, написал за 20 минут обертку для запуска приложений, говорю, вот тебе прототип твоей идеи на Руби, и делай с ним, что хочешь. Тоже чувак сразу затих. Люди, натурально, страдают хернёй. Скоро чтобы дома гвоздь забить, будут приглашать специально обученного специалиста, лишь бы самому не пытаться думать о том, с какой стороны надо держать молоток.

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

Это верно, самое главное достоинство опенсорсного юникса — охрененная гибкость — является одновременно и самым главным его недостатком.

geekless ★★
() автор топика
Ответ на: комментарий от anonymous

> да к чёрту этот чёртов зоопарк, надо взять что-то

одно и пилить-пилить-пилить до отменного состояния,

а за всеми зайцами сразу гнаться - фиг с места сдвинешься



Вот так и размножаются стандарты ....
http://xkcd.com/927/

kernel ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.