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 человек, с навыками программирования и желанием улучшить своё рабочее место. По отдельности мы — толпа анонимных аналитиков, вместе — команда разработчиков.

★★

> 1. Вкладки.
Спорно. У меня, например, вкладок в фоксе бывает по 30-40 открыто, но они вертикальные в боковой панели, ещё и сгруппированы, спасибо treestyletab, соответственно, ни в заголовке окна, ни в панели задач мне это богатство не надо, оно уже нормально организовано самим приложением. Кейс какой? Быстро переключиться из вкладки «голая девка.jpg» в браузере в файл «superlib.h» в IDE, а потом обратно в браузер на «следующая голая девка.jpg» силами панели задач? Имхо двухзвенка приложение - вкладка не намного медленнее, если не быстрее.

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

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

3. Действия.

Можно подробнее? Какие универсальные действия туда можно засунуть?

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

Информационные виджеты - детсад. Есть трей и его реально хватает. Все кейсы виджетов какие-то высосанные из пальца:
1) когда у меня есть время почитать фиды - я просто открываю читалку фидов, мне не нужен дайджест в маленьком окне;
2) о наличии новых емейлов мне сообщает значок в трее, плавающих окон а-ля the bat мне не надо;
3) погоду я узнаю просто посмотрев в окно :)

глобальное меню

На любителя.

В общем вау-эффекта нет. На новый уровень интеграции это всё не тянет. По крайней мере для меня.

Ну и X11 скоро отомрут, ибо пора ;)

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

Информационные виджеты - детсад

нюню

когда у меня есть время почитать фиды - я просто открываю читалку фидов, мне не нужен дайджест в маленьком окне

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

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

вот это реально детсад

виджет погоды нужен чтобы прикинуть в чём выходить на улицу

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

> 1. Вкладки.

Кейс какой?


Предлагаю проект: Semantic Window Management (комментарий)

3. Действия.

Можно подробнее? Какие универсальные действия туда можно засунуть?



Аналогично, примеры по ссылке выше.


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

Про интеграцию открытых документов в панель задач и подобных - аналогично п.1.



Сдвинь точку восприятия. Не «100500 кнопок на панели задач для открытых документов», а «Покажи мне, компьютер, какие документы типа pdf я открывал сегодня утром?» (Да, движок Zeitgeist уже изобрели. Но в данном случае у нас будет нечто более универсальное: механизм оповещения любых заинтересованных агентов об открытии/закрытии документов.)

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

>Да, движок Zeitgeist уже изобрели

Nepomuk, наверное, покруче будет

вообще, семантические хранилища данных - это здоровская идея, я на данном этапе вот от Непомука хочу только две вещи: интеграцию его в диалоги создания/сохранения файлов и синхронизацию с другими машинами через Сеть

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

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

> Nepomuk

У него есть тулкито-независимый интерфейс? Если нет, то в топку.

присобачить его к ... пакетному менеджеру

Это уже за гранью добра и зла.

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

>У него есть тулкито-независимый интерфейс?

нафига?

Это уже за гранью добра и зла

именно так, и это будет круто!!

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

> нафига?

Натуда. Тулкитов дохрена, и будет еще больше. Привязаные к тулкитам псевдоуниверсальные решения не нужны. Посмотри, например, сколько приложений умеет NETWM. Куча WM, куча панелей, поголовно все приложения. Это потому, что протокол не вводит дополнительных зависимостей и работает поверх голых иксов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Собственно, скрин лучше любых слов - детский сад, младшая группа. Отцентрированные в угоду «стилю» заголовки особенно улыбнули :)

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

У меня, видимо, стереотип работы сформировался или специфика задач сильно отличается, но всё равно как-то кейсы не цепляют.

Ну вот предоставляет приложение через некий интерфейс расширенную информацию о себе, типа «сейчас открыт файл для_васи.txt», есть некая «глобальная команда» в обличии кнопаря в заголовке окна «отправить по почте после завершения редактирования». Нажимаю я на этот кнопарь, система мне показывает диалог выбора нужного файла, или автоматом подцепляет единственный редактируемый файл и помещает в некую очередь заданий что-то на подобии «после завершения редактирования файла для_васи.txt открыть почтовик и прикрепить к новому письму этот файл». Соответственно, некий сервис или сам WM отслеживает состояние файла и после завершения редактирования выполняет действие из очереди. Правильно я идею уловил?

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

Ну можно использовать и так. Вообще моя цель на данном этапе — разработать универсальный механизм, а уж как им распорядится пользователь, то его личное дело. Другой вопрос: для чего я планирую использовать эти механизмы. Начнём, с того, что современный GUI — полный отстой. В консоли у нас есть модель «действие + объекты» (команды + файлы). В GUI у нас куча неструктурированных окошек и приложений с перекрывающейся функциональностью. Давайте посмотрим, как это можно улучшить, не изобретая велосипедов и очередных гномокед.

Посмотрим на эскиз типичного рабочего стола: http://s017.radikal.ru/i434/1111/8b/b1580652caca.png

Тут всё как обычно: панель задач, индикаторы, несколько окон приложений; в окне приложения полоса меню и рабочая область. Ключевые точки я обозначил цифрами:

(1) Окно приложения, фактически, предоставляет пользователю файл. Где-то на диске в каталоге лежит файл, который мы можем увидеть при помощи файлового менеджера, а в окне приложения мы видим содержимое файла. Рассуждая логически, «файл в приложении» — это подтип «файла в файловом менеджере». Файловый менеджер знает о файле только название, размер, дату модификации и т.п. Приложение знает о файле намного больше. Думаю, все знакомы с ООП и идею поняли. Проблема в следующем: понятия «файл в каталоге» и «файл, открытый в приложении» никак не связаны. Мы ожидаем, что приложение сохранит все возможности по взаимодействию с файлом, которые есть в ФМ, плюс добавит новые. Но оно их не сохраняет. У нас даже есть меню «Файл» в приложении, но оно обычно умеет только лишь открывать/сохранять файл + несколько возможностей, специфичных для приложения, типа экспорта в другой формат. И с точки зрения архитектуры приложения, это правильно, что оно не умеет делать ничего, кроме своих прямых обязанностей.

Итого, мы имеем противоречие: 1) приложение не должно уметь ничего лишнего, кроме своих прямых функций, чтобы не быть привязанным к DE и не дублировать функции других программ; 2) файл, открытый в приложении, должен быть интегрирован со средствами DE и другими приложениями. Решение состоит в разработке стандартного протокола для обмена информацией о файлах между приложением и DE.

(3) Информация о файле в окне приложения используется DE для формирования контекстного меню окна.

(2) Для приложения можно отображать меню «Недавние документы» для быстрого доступа к последним открытым в данной программе файлам. Приложению нет необходимости самостоятельно вести список недавних файлов, DE делает это автоматически.

(3) В меню окна DE отображает меню файла, аналогичное тому, что мы можем видеть в файловом менеджере.

(4) При помощи меню «Файл» пользователь может открыть этот документ в любой другой связанной с ним программе, не прибегая к вызову файлового менеджера или консоли.

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

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

(4) Если пользователь пишет скрипт, то через пункт «Свойства» он может назначить файл бит исполнения, а затем через это же меню запустить скрипт.

(4) Новые возможности доступны не только из GUI, но и средствами командной строки. При помощи этих утилит, программы xbindkeys и простейшего sh-скрипта, мы можем сделать такие интересные глобальные хоткеи как «открыть документ текущего окна в текстовом редакторе», «открыть каталог текущего документа в ФМ и поставить выделение на документ», «запустить скрипт, если текущий документ — это скрипт; выполнить make в каталоге документа, если документ — исходник; иначе открыть его в браузере».

(5) Для некоторых приложений будет иметь смысл изменять поведение пунктов меню DE. Например, для браузера команды копировать и отправить должны корректно сохранять содержимое текущей страницы на диск средствами браузера, а команда вырезать вообще не доступна. Приложение может переопределять часть команд. При этом, как и в случаях выше, приложение не зависит от DE и не тянет за собой кучу пакетов.

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 ★★
() автор топика
Ответ на: комментарий от geekless

Сдвинул точку восприятия:) Появились некоторые идеи кейсов. В принципе, используя рабочие пути открытых файлов, без дополнительного вмешательства в ПО можно организовать группировку текущих активных апликух по проектам. То есть изначально задаём привязки неких каталогов к проектам, ну а далее идёт проверка рабочих путей открываемых документов и присвоение меток проектов. Нечто подобное пилят в KDE, зовётся Activities, только на уровне приложений/виджетов, поэтому не особо юзабельно. В общем, концепция начинает нравиться ;)

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

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

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

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



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

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