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

Предлагаю еще индикатор прогресса как на панели задач в оффтоп7. А существующие глобальные меню вроде сделаны костыльно.

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

Хотя в юнити этот индикатор уже есть

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

Недавно ковырял mongodb и очень понравилась идея gridfs. Это я к чему: документоориентированные DB можно использовать как абстракцию над файловой системой (ведь юзер работает не с файлами, а с изображениями, документами, аудиозаписями и т.д.).

В контексте топика такую БД можно использовать как persistence-layer для хранения метаданных: относящихся к отдельному приложению, относящихся к отдельному окну, относящихся к коллекциям окон и приложений и так далее. На основе метаданных можно изменять представление сущностей, генерировать layoutы рабочего стола, по-умному фильтровать окна, динамически создавать выделенные рабочие столы «под задачу» с помощью правил подобно тому, как фильтруются письма в почтовых клиентах.

ИМХО, в качестве основы будет удобно использовать xmonad, интегрированный в гном. Можно прикрутить свистелки-перделки компиза.

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

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

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

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

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

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

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

geekless ★★
() автор топика

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

прозреваю перепил тулкитов - я такое уже предлагал

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

mongodb

gridfs

БД как persistence-layer для хранения метаданных

xmonad, интегрированный в гном

прикрутить свистелки-перделки компиза

Даааа. Это будет посильнее «Фауста» пострашнее Gnome Shell.

geekless ★★
() автор топика

Не знаю зачем я пишу сюда, лор давно протух, но...

Вкладки.

Не нужны. Вообще, в принципе. Если быть точным, то сущность «вкладка» не нужна, равно как и разные сплит-вью и им подобные. А вот отрисовка «вкладочек» - нужна, так как пользователи привыкли к этому элементу интерфейса и он им хорошо знаком, но реализовать ее можно в виде простого скина. Скина к чему? Сделайте СПИСКИ view-объектов. Грубо говоря, пусть listview, внутри которого будут сами view, скажем в виде картинок (не обязательно, пока лучше считать, что каждый вью - просто картинка). И вот тут как раз будет большая радость в виде списков. Рендеринг в виде списка кнопок с окошком, внутри которого «картинка». На кнопках скин табов.

включая название, иконку

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

и флаг, указывающий может ли вкладка быть закрыта

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

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

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

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

включая такую информацию, как URL документа, тип MIME> или отображающих документы из одного каталога

Не нужно. У меня десятки окон, у которых в принципе нет ничего похожего на URL - как ими рулить будешь? Зато каждому окну можно повесить свой набор тегов, который генерить в том числе на основе URL.

Интеграция окон файловых менеджеров между собой

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

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

ну так сделай тулбар, который можно отделять от основного окна, в гноме уже 100 лет такое есть.

Например: RSS-клиент — заголовки самых свежих элементов фидов, email-клиент — количество непрочитанных сообщений

А если я хочу список емейлов и количество RSS-уведомлений? Решение простое - пусть не само приложение создает эти уведомления, а WM копирует те виджеты, которые желает мониторить пользователь. Сделать набор пресетов, дабы новичкам не надо было лазить в настройки. Опять же, сам же пользователь определяет, куда отображать все это - на десктоп, в заголовок окна, на таскбар или в систрей.

По отдельности мы — толпа анонимных аналитиков, вместе — команда разработчиков.

RIP. Плавали, знаем.

anonymous
()

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

Сенсация, второкласник Вася реализовал маппинг приложений (экшенов) к [окнам/вкладкам/спискам/элементам списка]. Просто пока нету нормальной спеки уровня freedesktop. Все в ожидании спецификаций, дабы добавить поддержку во все ведущие DE.

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

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

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

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

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

Смотри какая у меня картинка: c:\Мои документы\Фото387.jpg - ваще абаржака ))))

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

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

Как пример - очень хочется адресную книгу (отдельным приложением)

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

anonymous
()

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

А вот у меня названия вкладок в гуглокалендаре анимированные, мигают. Что делоть?

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

было в windows95

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

Гораздо хуже, если приложение вообще не выдает информацию о происходящем. Например, грызет винт, но ничего не показывает (ffmpeg). Может предусмотреть набор костылей на основе systemtap, дабы подглядывать за происходящим?

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

For lack of any better way of thinking about the problem, this might lead itself to a typical Macintosh user interface, circa-1984: a program that starts out with a blank card, with menu items for adding text, pictures, loading cards from a library, and sending cards. And then what the user is going to have to do is sit down and browse through the menus, trying to figure out all the commands available, and then do their own synthesis of how to put these atomic commands together to create a card.

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

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

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

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

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

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



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

kernel ★★☆
()
21 января 2012 г.
Ответ на: комментарий от geekless

Ну, короче, если что - я готов. Вдруг еще кто-нибудь захочет принять участие в работе?

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

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

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

Честно говоря, единственная книжка по Руби, которую я видел, это довольно объёмная pdf-ка в составе дистрибутива Руби для винды. Вроде бы, вполне годный учебник. Но не помню, как называется.

Также, на оффсайте были ссылки на литературу.

Я ж учебников уже давно не читаю, только справочники синтаксиса языка и API библиотек. :)

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

Я беру двенадцатиметровую палку

Тык. Тык. Тык.

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

я беру тридцатиметровую палку

Тык. Тык. Где спека?

netcat ★★
()

tl:dr

Если у тебя есть Semantic, то тебе не особо упёрлись Window.

Попробуй подумать над этим странным утверждением.

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

На гугл доксы. Как только более-менее целостные идеи появятся-можно будет пораскинуть мозгами.

X10Dead ★★★★★
()

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

а я об этом говорил уже
как обычно - «не нужно!»
[GUI][вещества] глобальные табы
там для примера есть картинки даже (панель специально уродской сделал)

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