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

Собсна пункт 3 как и действия уже запилили, просто пока нету нормальной спеки уровня freedesktop. А насчет зависимости от иксов, то чем плох dbus для этих целей? Он не зависит от гуя и более кроссплатформенный. По сети его тоже можно научить гоняться, если припрёт.

Gorthauer ★★★★★ ()

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

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

всё решается ещё проще - внутренние вкладки приложения не нужны, это же решает проблему иконок и названий.

А объединение в группы должно настраиваться в оконного менеджера

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

см пункт первый, но спеки хорошо бы расширить (чтобы не нужно было парсить заголовки вручную)

в остальном - неплохие идейки, но нужно обдумать

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

> Собсна пункт 3 как и действия уже запилили, просто пока нету нормальной спеки уровня freedesktop.

Вот это: https://wiki.ubuntu.com/Unity/LauncherAPI#Dynamic_Quicklist_entries ?

Нет, спасибо. Это порождение быдлокодеров не нужно. В основе должна лежать формальная спецификация протокола, а не мутная реализация из недоDE. Кроме того, протокол должен быть достаточно прост, чтобы несколькострочным bash-скриптом можно было бы добавить окну действие «My Super Action», запускающее команду /usr/bin/mysupercommand ${WINDOWID}.

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

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

Зависимость от иксов — это не проблема. У на ВСЁ в gui зависит от иксов. Это всё-равно, что переживать из-за зависимости от libc.

Вопрос не в том, чем плох dbus, а в том, чем он хорош. Окна — абстракиця в иксах. Посылка сообщений — абстракция в иксах. Свойства окон — абстракция в иксах. Dbus тут лишняя сущность.

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

>Dbus тут лишняя сущность.

зато оно есть и работает

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

> всё решается ещё проще - внутренние вкладки приложения не нужны, это же решает проблему иконок и названий.

А объединение в группы должно настраиваться в оконного менеджера

У нас УЖЕ есть 100500 приложений, имеющих вкладочный интерфейс. И лучший, насколько я вижу, способ малой кровью превратить эти вкладки в нечто полезное — предложенный мной вариант.

Т.е. надо копать с противовположной стороны: чтобы идея «объединение в группы должно настраиваться у оконного менеджера» дошла до широких масс разработчиков, надо сделать её наглядной на примере существующего софта с вкладками.

см пункт первый, но спеки хорошо бы расширить (чтобы не нужно было парсить заголовки вручную)

Смотри, допустим, у нас нет вкладочного интерфейса. Т.е. пусть он вообще не обрел популярность, или мы им просто не пользуемся. Тогда у нас каждое окно — это либо служебное окно приложения (панель, настроечный диалог и т.п.), либо окно ОДНОГО документа. И тогда нам тем более важно об этом документе дать как можно больше информации для стороннего софта. Чем больше информации, тем умнее можно настроить поведение WM, панели задач и т.п. по отношению к таким окнам. Ибо зачем парсить вручную, если приложение может и само предоставить о себе конкретную информацию.

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

>У нас УЖЕ есть 100500 приложений, имеющих вкладочный интерфейс.

и это ужасно

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

возможно ты и прав, собственно, я уже использую подобный костыль для буферов емакса :)

lazyklimm ★★★★★ ()

по п1. Строго говоря, организация MDI собственными средствами приложения - ЗЛО. Один документ = одно окно. А как размещать это окно, во вкладке ли, в тайлах/фрйемах/отдельном мониторе и прочая - должен решать и делать WM.

по п2. не задача DE/WM и в рамках X-протокола без привлечения LDAP и а-ля ActiveDirectory нереализуемо. Окна могут быть от разных машин с разных логинов, то есть как минимум с разными ФС и правами.

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

Определять URL — не задача данного протокола. Задача протокола — давать механизмы для его передачи между клиентами.

Что касается самого URL, то в рамках одной машины всё будет прекрасно работать. А в случае нескольких машин... зачем тут вообще LDAP, для какой цели? Достаточно по необходимости банально передать в приложение параметры через переменные окружения. Нам же требуется всего лишь удобство для сортировки/группировки окон, а не, например, гарантия того, что URL документа не фейковый.

geekless ★★ ()

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

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

Достаточно по необходимости банально передать в приложение параметры через переменные окружения

через какие параметры и какого окружения ??

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

Что значит «какого окружения»? Словосочетание «переменные окружения» имеет только одно значение, без какой-либо двусмысленности.

какие параметры

А ты называй конкретные use cases, на которых идея «URL для окна» фейлится, мы и определимся, какие параметры нужны. Пока единственный случай, который я вижу — локальные URL на разных машинах. Т.е. клиенты, запущенные на разных машинах, должны знать, что они запущены на разных. Вообще-то у нас уже есть свойство WM_CLIENT_MACHINE. Но если его недостаточно (в каких случаях?), можно в явном виде устанавливать переменную окружения SWM_CLIENT_MACHINE, по которой клиентом будет выставляться соответствующее свойство окна.

geekless ★★ ()

По п.1 :

На кой черт сдались куча вкладок приложений на панели задач DE? Хоть какой-нибудь распространённый кейс, где это нужно? То же самое по пунктам 3 и 4 (кейсы).

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

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

единственный случай, который я вижу — локальные URL на разных машинах

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

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

> На кой черт сдались куча вкладок приложений на панели задач DE? Хоть какой-нибудь распространённый кейс, где это нужно? То же самое по пунктам 3 и 4 (кейсы).

1. Ты пользуешься такой фичей, как переход в нужное окно вводом части его названия? Вот если тебе надо опасть на третью вкладку какого-либо окна, а у тебя в нём активна первая, такой поиск по названию нужного тебе окна не найдёт. Если же компонент, отвечающий за поиск, будет знать названия вкладок и знать, как активировать не только окно, но и нужную вкладку, то всё сработает как ожидается.

3. Самое очевидное: в меню окна или панели задач отображать список недавних документов для данного приложения. При чем, не обязательно, чтобы само приложение умело это делать. Этим может заниматься и внешнаяя утилита, специально для этого предназначенная.

Далее, допустим, есть некая полезная утилита для управления окнами, функционал которой отсутствует в WM. Тогда я смогу прикрутить команды для управления этой утилитой к WM. Например, в контекстное меню окна. Или в виде дополнительных кнопок.

Также некоторые тут жалуются, что в шindoшs есть средства для размещения туллбара программы в заголовке окна, а в иксах — нет. Я не знаю, зачем это надо (говорят, для экономии места по вертикали), но пусть будет.

4. Универсализация интерфейса для виджетов. Протокол для трея — один. И везде работает. (Не считая своего велосипеда в Unity, но это отдельная песня). А вот интерфейсов для виджетов, «индикаторов», «плазмойдов», «аддонов» и т.п. миллион, хотя все они делают одно и то же — встраивают небольшое окно приложения на некоторую панель, настраиваемую пользователем. Так давайте сведем весь этот зоопарк к общему знаменателю.

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

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

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

Во-вторых, оно и так их может получать из заголовка тунара.

В-третьих, запускать ЛЮБЫЕ приложения имеет смысл только на заведомо доверенном дисплейном сервере, потому что любой клиент может послать тебе любые события. Например rm -rf /* в окно терминала.

Так что еще раз: чем именно прорблема?

geekless ★★ ()

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

Ты не понял зачем нужны стандарты: их пишут, в первую очередь, чтобы оговорить совместимость чего-то с чем-то, все остальное - домыслы гуманитариев. Когда совмещать нечего, стандарт __нинужен__ - это твой случай.

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

>Что за костыль ?

единое переключение (через Dmenu/Wmctrl) рабочих столов, окон и буферов емакса

вот

lazyklimm ★★★★★ ()

Два предложения:

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

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

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

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

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

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

Отдельным, да. Собственно, прогрессбар — это самое простое из предложенного.

А какую роль выполняет в юнити число на иконке?

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

> а где тут semantic?

Ну в пункте 2, например. :) Есть лучшие идеи для названия?

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

geekless

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

Они вроде бы собирались новый пилить, потому что старый уже старый)

А какую роль выполняет в юнити число на иконке?

Число непрочитанных в пигине/rss клиенте/скачанных в лисе/whatever. Это больше зависит от фантазии разрабов ведь.

CrossFire ★★★★★ ()

> 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 ★★ ()

В линуксомирке придумали 1/100 WPF. Круто, прогресс, че.

Кстати, GUI через сокеты нахер никому вменяемому не сдался.

anonymous ()

Почти всё уже есть.

>1. Вкладки.

Использовать tabbed и чмырить программиздов, чьи поделия не имеют опции детача вкладок приложения в отдельные окна.

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

Заводить по окну на каждый документ. Различать окна с документами от остальных окон приложения по x-ролям.

3. Действия.

Это как систем-меню в виндавс, которое можно привязать к каждому окну? Профит сомнительный, но в принципе не помешает.

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

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

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

Если ты не пользуешься сетевой прозрачностью, это ещё не значит, что ею никто не пользуется.

yoghurt ★★★★★ ()
Ответ на: Почти всё уже есть. от yoghurt

>Использовать tabbed и чмырить программиздов, чьи поделия не имеют опции детача вкладок приложения в отдельные окна.

вкладки на уровне приложений надо запретить вообще

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

Объясни это счастливым пользователям всяких говнонедоwm :)

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

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

ollowtf ★★★ ()

Хорошие идеи, я бы с удовольствием присоединился, но, к сожалению, мало опыта, знаний и времени :(

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

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

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

ollowtf ★★★ ()
Ответ на: Почти всё уже есть. от yoghurt

> Использовать tabbed и чмырить программиздов, чьи поделия не имеют опции детача вкладок приложения в отдельные окна.

Меня неизменно удивляют люди, которые предлагают «чмырить», «не пущать», «принуждать». Волоком за ноги в светлое будущее. Так дела не делаются.

Заводить по окну на каждый документ. Различать окна с документами от остальных окон приложения по x-ролям.

Такое впечатление, что ты по диагонали читал.

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

Мешает отсутствие договоренностей. Я удивлён, как этого можно не понимать.

geekless ★★ ()
Ответ на: комментарий от 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 ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.