[unity][d-bus][гвозди][не unix-way] Направление развития современных UI

Зачем надо было ограничивать разработчиков? Добавлять лишнюю сущность (dbus)? Придумывать протокол для этого

Значит, d-bus придумали специально для глобального меню? ню-ню.

> Приложение создает окно со специальным атрибутом, например, WM_MAINMENU

Дальше не читал. Идея говно.
Была такая поделка skypetab, пытающаяся реализовать по подобному принципу табы в скайпе. Артефакты, тормоза, неадекватное поводение (тащишь за заголовок, а «табы» на месте висят). Для такого иксы непригодны.

Глобальное меню - оно в перспективе глобальное. Глобальное меню должно принадлежать приложению и не меняться (или меняться минимально) при переходе от одного окна к другому.

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

Зачем надо было ограничивать разработчиков?

Где там ограничения для разработчиков?

Например в в Chromium появилась удобная фишка - кнопки для изменения масштаба, расположенные в меню. А с глобальным меню Unity так можно?

А они уже добавили интеграцию с Unity, правда, не знаю, насколько глубокую.

Почему в меню не могут быть ползунки для масштаба, поля ввода и другие элементы GUI (конечно если они там уместны)?

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

на opennet попадалась новость с концептом нового OpenOffice, в котором меню объединили с панелями инструментов (на вид лучше и удобнее чем ribbon). Вот и как такое сделать в Unity?

Unity будет ломать и корёжить такую панель? Не могут же разработчики охватить всё.

Можно было сделать гораздо проще, основываясь на окнах. Приложение создает окно со специальным атрибутом

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

>Значит, d-bus придумали специально для глобального меню? ню-ню.
Я этого не говорил. Имеется ввиду лишняя сущность при создании меню.
То что dbus - полезная вещь я не спорю.

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

>Гораздо легче переделать все существующие приложения, чем применить пару патчей к тулкитам, да.
Так это и реализуется патчами к тулкитам. Тулкит при создании меню рисует его в другое окно? Сложно?

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

Имеется ввиду лишняя сущность при создании меню.

Эта сущность как раз не лишняя. И уж всяко красивее смотрится, чем костыли вроде «специальный атрибут WM_MAINMENU», XEmbed и переделывание тучи аппликух.

Согласен с ТСом в постановке вопроса. Не согласен с его вариантом реализации меню.

> Эта сущность как раз не лишняя. И уж всяко красивее смотрится, чем костыли вроде «специальный атрибут WM_MAINMENU», XEmbed и

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

костыли

Давай навернём сверху еще десяток абстракций по причинам необоснованной костылебоязни.

переделывание тучи аппликух.

Худей.

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

И D-bus существует.

А DBus по реализации — редкостное говно.

Ну, может, конечно, и не такой эталон правильности реализации, как иксы, но it does it's job.

Давай навернём сверху еще десяток абстракций по причинам необоснованной костылебоязни.

Сверху чего и для чего? И да, я правильно понял, что ты согласен с предложенной ТС реализацией или пропустил твой вариант?

Худей.

72 кг при 176 роста. По мне так нормально.

Прочитал по диагонали, но за гуй через dbus и XEmbed надо расстреливать.

У dbus проблемы с сетевой прозрачностью.

Все (или почти все) фичи XEmbed можно легко и просто сделать обычными атрибутами окон.

>Согласен с ТСом в постановке вопроса. Не согласен с его вариантом реализации меню.
Ваши предложения!

>Все (или почти все) фичи XEmbed можно легко и просто сделать обычными атрибутами окон.
Так а я и предложил 2 варианта.

Все (или почти все) фичи XEmbed можно легко и просто сделать обычными атрибутами окон.

По крайней мере втыкание элементов в панель. Можно сравнить гномовский XEmbed трей и кдешный с атрибутами окон.

Ах, да, забыл написать что у dbus проблемы с сетевой прозрачностью.
Спасибо sergej'у что напомнил.

> И D-bus существует.

И? Нахрена использовать шину сообщений, чтобы [b]показать окно[/b]? Может еще веб-сервер поднять для этого?

Сверху чего и для чего?

Маршрутизировать работу с меню через xml, чтобы потом на том же икс-сервере и показать это меню. Software bloat as is.

И да, я правильно понял, что ты согласен с предложенной ТС реализацией или пропустил твой вариант?

Я не уверен, что вариант реализации ТС — лучший из возможных. Тут есть что обдумать, прежде чем с наскока решать. Но то, что он лучше dbusmenu — факт.

> Ваши предложения!

А хз. После небольшого размышления твой вариант выглядит концептуально вполне нормальным.

Написать спецификацию для такого взаимодействия и базовую реализацию — возьмешься?

Нахрена использовать шину сообщений, чтобы показать окно?

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

Маршрутизировать работу с меню через xml, чтобы потом на том же икс-сервере и показать это меню.

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

Но то, что он лучше dbusmenu — факт.

В том виде, как он есть сейчас? Если и факт, то крайне спорный.

>Написать спецификацию для такого взаимодействия и базовую реализацию — возьмешься?
Со спеками можно попробовать, надо обсудить что и как более подробно.
Надо объединиться.

Как сделан «dock» мне тоже не нравится, по тем же причинам.
Когда-то я об этом писал на ЛОРе, попытаюсь найти ссылку.
Эту же идею дока я описывал на gnome-look - http://gnome-look.org/content/show.php/AppBar?content=105590

> Так. Наверное, я что-то упустил в этой схеме. Кинь ссылочку, где написано, как d-bus показывает окно. В моём представлении он ничего не показывает, а используется несколько ближе к своему назначению.

Ага, сообщения мимо dbus летят, через астрал. Не придуривайся.

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

Давай вообще всё IPC повесим на DBUS? Вон достаточно скинуть в корзину каталог с большим количеством файлов, а потом сказать в наутилусе очистить корзину — и гарантированы 5 минут 100% CPU, сожранных nautilus, dbus демоном и gvfs. Как пишут в интернетах, на серверах, обслуживающих большое количество подключений с графических терминалов в сеансы gnome, CPU большую часть времени проводит в демоне dbus. Всё это из разряда «гладко было на бумаге, да забыли про овраги». Гонять туда-сюда xml по любому поводу — это нужно же было до такого додуматься.

Я предлагаю убрать главное меню как сущность и перейти на контекстные и свёрнутые в кнопки.

Да правильно-то оно вообще добавлять поддержку таких вещей в тулкит и унифицировать поведение. Только пока раскачаются это сделать, тулкит можно будет переписывать на новую версию. Тем более учитывая зоопарк всего и вся.
А Dbus — ну да, в чём-то грязный хак. Зато работает и не давится уже сейчас, а не в светлом будущем.

>То же я могу сказать и про док. Самый простой и в тоже время гибкий вариант - приложение само рисует небольшое окно, которое оконный менеджер кладет на панель. Писал уже об этом на ЛОРе, найду тему - выложу ссылку. Та же идея на Gnome-Look - http://gnome-look.org/content/show.php/AppBar?content=105590

Это получится жутко криво, я гарантирую это.

ох лол, гуй через d-bus
да, вендекапец еще не скоро наступит

> Со спеками можно попробовать, надо обсудить что и как более подробно.

Надо объединиться.

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

http://gnome-look.org/content/show.php/AppBar?content=105590

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

Я просто перечислю список вещей, которые считаю необходимыми для нормального десктопа:

* WM с возможностью объединения окон в табы и склеивания окон во фреймы в любых сочетаниях. Например, чтобы можно было склеить 4 терминала в набор вкладок, а потом приклеить их сбоку с текстовому редактору, и чтобы получившаяся конструкция ресайзилась, перемещалась, а также мигрировала между рабочими столами как цельное окно. (Про такую роскошь, как взаимодействие «скленных» вместе программ, чтобы, например, feh автоматом показывал ту картинку, которая выделена в файловом менеджере... — про такую роскошь заикаться пока не будем, ибо «тут не один кран, тут всю систему менять надо!»)

* Демон для ведения статистики недавно- и часто-используемых документов + спецификация интерфейса для общения с ним. Варианты использования:
** Приложение показывает в меню список недавних файлов.
** Файловый менеджер в отдельной панели может показывать список недавних файлов от текущего каталога и его подкаталогов.
** В контекстном меню у кнопок/иконок запуска приложения показывать такой список. (В семерке есть нечто подобное).

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

* Общий протокол для получения списка действий «контекстного меню» для указанного файла и выполнения этих действий. И внедрение его во все места, куда могут дотянуться руки. За все годы разработки gnome2, до разработчиков так и не дошло, что объекты в меню «переход» и «недавние документы» — это точно такие же файловые объекты, как и те, что видны в файловом менеджере. И набор действий для них должен быть доступен аналогичный. Или скажем, файловая панель в текстовом редакторе. Если она _выглядит_ как файловый менеджер, она _должна_ _быть_ им. «Интегрированное десктопное окружение», блджад — почти у каждой программы зависимостей на 300 метров, и нихрена толком не работает.

* Система уведомлений. Не знаю, есть ли нормальные демоны уведомлений для libnotify, не искал. Не удивлюсь, если нет.

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

иксы вообще не нужны

Ты все перепутал: это ты не нужен.

Кстати, оффтоп небольшой.

Смотрю сегодня: ldd показывает, что xneur-у нужны gtk, cairo, pango и прочая гуйня. Это демону-то без интерфейса. Фигею, лезу в исходники. Выкидываю лишнее из configure.in (в самой программе использования gtk замечено не было), пересобираю. Зависимости исчезли, resident set уменьшился на мегабайт, vsize — на 7 метров.

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

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

Кеды вроде почти все это умеют.

Не читал.

Но думаю стандартное нытьё аля «где кнопка пуск?»

>* WM с возможностью объединения окон
Полностью за!

* Протокол для взаимодействия приложения и дока, примерно как ты описал.

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

Я вот думаю, что тот же Unity можно допилить до всего описанного (теоретически).
Для начала надо собрать все идеи, подробно описать их,потом можно запостить на какой нибудь brainstorm.ubuntu.com показав народу что можно сделать гораздо лучше и гибче чем есть сейчас. У меня там уже есть кучка идей, но они обрывочные и с инглишем у меня не фонтан.
было бы не плохо как нибудь сконтачиться и все обсудить, или можно развивать идеи в этой теме...

За все годы разработки gnome2, до разработчиков так и не дошло

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

Кстати, вот есть интересный проект - http://etoileos.com/

Вот что настораживает:[code]GNUstep. The purpose of this project is to create a free and open version of the Cocoa (formerly known as NeXTSTEP/OpenStep) APIs and tools for as many platforms as possible.[/code] Во-первых, Objective-C. Под линукс на нём программистов днём с огнём не отыскать. Во-вторых, клон проприетарного API.

> Протокола нет, т.к. нет взаимодействия

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

А на лицо как раз взаимодействие и протокол.

смысл в том чтобы приложение само рисовало себе кнопку

Здесь следует рассмотреть ситуацию с разных сторон.

* С точки зрения дока, он выполняет роль WM для некоторого класса окон. Подход к доку как к WM даёт нам возможность встраивать туда вообще что угодно, при чем, фактически без накладных расходов на «протокол», без развесистых библиотек и т.п.

* С точки зрения приложения, кнопка в панели — необязательная внешняя служба, и хорошо бы иметь к ней высокоуровневый интерфейс. Если приложение _может_ само нарисовать кнопку, это не значит, что оно _обязано_ это делать. Очевидно, что большинство кнопок будут стандартными: иконка, меню, возможность показать прогрессбар на кнопке и т.п. Тут надо подумать над списком нужных функций. Но засовывать всё это в *.so нельзя — получится очередная развесистая лапша с прибитыми молотком зависимостями. Нужен демон, которому приложения будут делегировать функции по отрисовке кнопок. И в спецификацию идёт протокол общения с демоном, а не API библиотеки.

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

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

Теперь об особенностях реализации, которые я вижу.

Клиентская сторона должна иметь возможность получить от дока параметры отображения и согласовать размеры кнопки. К параметрам я бы отнёс:
* Режим: по одной кнопке на приложение, по одной кнопке на документ, по одной кнопке на окно.
* Тип отрисовки: обычный вид, краткий вид (для «трея»).
* может быть, еще что-то, но пока не приходит в голову.
Реализована передача данных будет через аттрибуты иксового окна.

Идентификация кнопок. Как минимум, нужны уникальный идентификатор приложения и приоритет (возможно еще роль как дополнительный элемент идентификации). Приоритет помогает доку перекрывать одни кнопки другими. Пример 1: кнопка-лаунчер имеет приоритет ниже, чем кнопка работающего приложения (а идентификаторы — одинаковые), и при запуске приложения, док отображает кнопку приложения вместо кнопки лаунчера. Пример 2: пользователя не устраивает кнопка, которую рисует некое приложение; он запускает программу, которая эмулирует наличие кнопок для «старых» приложений и настраивает её принудительно рисовать кнопку для данного приложения, выставляет повышенный приоритет.

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

потом можно запостить на какой нибудь brainstorm.ubuntu.com показав народу что можно сделать гораздо лучше и гибче чем есть сейчас

Получится много болтологии и мало дела. Нужны люди: 1) заинтересованные в этих программах и 2) умеющие и любящие программировать. По обоим пунктам аудитория brainstorm.ubuntu.com мало подходит, как мне представляется. Думаю, тебе с этим приходилось сталкиваться: описываешь подробно преимущества некой программной архитектуры, а потом получаешь гору советов «а вот приложение N реализует похожие фичи!». И пофиг, что ты им только что описывал, что приложение N работает через костыли.

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

Сначала надо сделать что-нибудь работающее. Хотя бы в рамках концепта и демонстрации идеи. А потом уже выходить к людям.

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

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

Зачем вообще это глобальное меню? Это же неудобно. Ну место может немного экономит, но мне кажется, что удобство важней.
То же и с новыми полосами прокрутки — тоже неудобно.

> неудобно

Кому как.

Чем оно удобнее отдельного меню у каждого окна?

Да. Я всё равно мышью практически не пользуюсь — зачем мне к каждому окну вешать меню?

А что, комбинации типа alt-Ф для меню Файл отменили?

Так для этого всё равно надо иметь в фокусе активное окно — какая разница, где при этом меню будет рисоваться. Это во-первых.

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

> Так для этого всё равно надо иметь в фокусе активное окно — какая разница, где при этом меню будет рисоваться. Это во-первых.
Но некоторые ведь могут захотеть всё-таки тыкнуть курсором. Я вот тачпад использую — и так как для жеста им можно не отрывать руки от клавиатуры — довольно активно. И не вижу в этом ничего плохого.

Вот если бы я опять пересел на комп с мышью, может было бы неудобно.

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

> Но некоторые ведь могут захотеть всё-таки тыкнуть курсором.

Тогда придётся сделать на 1 клик больше. Глобальное меню не мышефрендли, когда на экране видны одновременно несколько окон. Я с этим и не спорю.

было бы неудобно

Ну так не пользуйся глобальным меню, если не нравится. Я вообще за тотальную настраиваемость софта во всём, что только может прийти в голову пользователю.

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

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

> Вот пусть и висит где-нибудь на панели и не лезет на глаза.

Верхняя панель и так уже забита

> Уменьшает количество мусора на экране -> увеличивает удобство.
Не особо. А если ещё учитывая, что оно намного выше. Мне кажется, это для нетбуков. Только вот маководы его пихают везде.

http://s002.radikal.ru/i200/1104/19/6a44a145a9ea.png
http://s59.radikal.ru/i166/1104/48/db9115c1e560.png
http://s61.radikal.ru/i173/1104/ab/dc0b063ee55c.png

Вы однако, почти меня цитируете. Очень похоже на то, что я писал на gnome-look (что-то подобное писал и на ЛОР, но не могу найти).

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

To ensure backward compatibility with the applications does not support this feature, we need a small service that will create icons for apps.

Только есть небольшие различия в плане «может» и «должно» для приложений.

Подход к доку как к WM даёт нам возможность встраивать туда вообще что угодно, при чем, фактически без накладных расходов на «протокол», без развесистых библиотек и т.п.

Согласен, тоже об этом думал. При том, этот «WM» может определять наведение на док курсора мыши и увеличивать окна (как увеличиваются значки в доке mac os x), при этом приложение может выводить больше информации, а не просто показывать большой значок.
Еще одна моя идея на смежную тему: http://www.youtube.com/user/0alsh?feature=mhum#p/a/u/1/ngzAEeHQUys
(Часы/календарь тоже могут быть отдельным приложением)

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

Я думаю, что если приложению не надо ничего, т.е. просто у приложения есть куча окон, которыми надо управлять, то кнопку в доке может нарисовать и сторонний сервис/даемон. А вот если надо прогресс бар, то лучше бы приложению рисовать кнопку в доке самому, а то опять понадобится какой нибудь d-bus.

Но засовывать всё это в *.so нельзя

Да там много и не надо: как вывести список окон, прогресс бар и т.п.. Все это строится на стандартных виджетах. Ну, надо еще подумать...

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

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

* Режим: по одной кнопке на приложение, по одной кнопке на документ, по одной кнопке на окно.

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

Идентификация кнопок. Как минимум, нужны уникальный идентификатор приложения и приоритет (возможно еще роль как дополнительный элемент идентификации). Приоритет помогает доку перекрывать одни кнопки другими.

5) Unusual launchers

When application is not running, some light process can draw app icon with any information on icon or in popup. When application starts, it replaces icon by new one.

Теперь вопрос, с чего начать?
Идеи есть, спецификацию можно написать. А вот на основе чего это делать?
Все равно надо за основу какой нибудь тулкит и оконный менеджер.
Я думаю что подробное описание таки надо куда-то выложить, чтобы найти заинтересованных людей. Мой опыт программирования - dockbarx на python'е, да и то давно ничего не писал.
Надо как нибудь сконтачиться чтобы все обсудить и описать что вообще мы хотим. Этио возможно?

Можно начать с кода того же dockbarx, распиливанием его на части. Выделяем в нём два процесса: один поддерживает окна-кнопки приложений, другой управляет размещением этих окон-кнопок (т.е. собственно сам «док»). Чтобы сформулировать и отладить ту часть протокола, которая отвечает за взаимодействие дока с кнопкой этого будет достаточно.

Затем первый процесс распиливаем еще на 2: один будет предоставлять стандартную функциональность (демон 1), второй при помощи неё рисовать кнопки (демон 2). На этом этапе формулируем в черновом варианте протокол, при помощи которого реальные приложения будут общаться с «демоном 1».

Пробуем для нескольких приложений прикрутить работу с доком через «демон 1» и напрямую. Исправляем протокол по необходимости. Учим док правилам перекрытия кнопок по приоритетам или что-там-еще-будет. Учим «демон 2» не соваться к приложениям, которые умеют рисовать себе кнопки сами.

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

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

тулкит

Вероятно, gtk. Выбирать-то особо не из чего.

Надо как нибудь сконтачиться чтобы все обсудить и описать что вообще мы хотим. Этио возможно?

Мыло igeekless gmail com