Re: [gnome-cyr] =?koi8-r?q?=F0=CF=DE=C5=CD=D5_=D5_=CD=C5=CE=D1?==?koi8-r?q?_=D0=CF=D3=D4=CF=D1=CE=CE=CF_=C2=DF=C0=D4=D3=D1_=D4=C5=CD?==?koi8-r?q?=D9=3F?=

["avl l14 ru" <avl l14 ru>]

Sergey V. Oudaltsov пишет:

> > > Это потрясяюще! Меня уже никто не спрашивает, сколько сил я на это
> > > должен буду угрохать, хочу ли я это делать ваааще. Я просто балдю!
> > >      
> > взялся за гуж... :)
> >    
> Кто-то тут утверждал, что я, типа, руководитель проекта:)
Угумс.  Вот и руководь, а не задавайся вопросом "хочу ли я это делать 
ваааще".  :)
Руководитель отличается от прочих тем, что принимает и обрабатывает 
мнения, а затем распределяет нагрузку в соответствии с "инициатива 
наказуема".
 

> > > Да, а механизм доп. раскладок (не переключаемых через клаву) - это не
> > > близко к желаемому? Или нужно доп. раскладки per WM_CLASS делать (как и
> > > начальную раскладку)? Я умучаюсь...
> > >      
> Подумав про это, я осознал - это приведет переинициализации конфигурации
> XKB при переключении окон. Мне этого очень не хочется. Настолько не
> хочется, что скорее всего я это оставлю плагиноделателям (в смысле - сам
> я этого делать не буду) и - то, если я еще окажусь таким добрым, что дам
> им для этого API. В базовой утилите конфигурации xkb этого, скорее
> всего, не будет (да и gnome usability может не обрадоваться).
>  
Это уже второй вопрос. Естественно такую функциональность в core 
запихивать не стоит. А вот посмотреть во что выливается API с учетом 
возможности написания такого плагина вполне можно.
И тогда уже исходить не из того, писать или не писать плагин, а из того, 
стоит ли такая возможность самого плагина трудов в core.

> > Я бы до утряски списка функций погодил кодить. Что то должно уйти в 
> > плагины, что то нужно убтрать и только разобравшись с существом всех 
> > надстроек - кодить базу.
> >    
> М-м... "Всех надстроек" - это как? Всех возможных плагинов? Что-то эта
> мысль для меня сложновата, кажется, я ее не понял:)
>  
1)Нарисовать дерево функционала переключателки и конфигуратора
2)Решить, что будет в core, а что вылетает в плагины
3)Решить, какие плагины нужно делать, а какие оставить на 
third-development (просто сделать их написание принципиально возможным 
путем внесения нужной функциональности в API)
4)Оценить затраты и провесть усекновение до хорошего показателя 
трудоемкость/функционал
5)Написать TODO и ROADMAP
6)Кодить

*функционал xkb-properties-capplet*

*список раскладок*  (я понимаю, что ограничение на 4 раскладки, но 
закладывать это в дизайн странички как то недальновидно)

   *     добавить раскладку
   *     удалить раскладку
   *     редактировать раскладку


*свойства раскладки *

   *     горячая клавиша для переключения в эту раскладку


*общие свойства*

   *     горячая клавиша для переключения раскладок.
   *     дефолтная раскладка (нужна в апплете и... вообще нужна :).


*Вызов*

   *     control-center
   *     из командной строки (для интеграции с другими приложениями)
   *     с указанием parent виджета для встраивания в приложения.
     (экстра, вполне можно потом)


Все пишется сразу, никаких плагинов, с совещаниями в гноме и т.д.

Наверное, что то пропущено.


*Функционал монитора:*

*Логирование*

   *     логирование пойманных событий
   *     логирование факта передачи события в "плагин" и обязательно с
     параметрами.
   *     логирование срабатывания action
   *     уровень логирования

Проблем при настройке монитора без логов будет очень много, кроме того 
логи (веренее их обработка) отлично заменят xprop.
*
API*

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

*Конфигуратор*

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

Усекновение:

Воля ваша, а я бы флажки _временно_ (до stable релиза) прибил.
1) все эти локальные соответствия, картинки в апплете и прочее ломкое дело.
2) картинка - красиво, но малоинформативна. у текста есть цвет надписи, 
цвет фона, жирность, курсив которыми можно рулить из плагинов легко и 
непринужденно (через соответствующие action) , а что делать с картинкой?
3) Устаканится action лист - станет ясно, что можно сделать с их 
индикацией в случае флажков.
4) Кодить, кодить, кодить будет проще... :)


*rule-based engine*

rule-based engine надо или дорабатывать до универсального вида и 
впихивать в core или делать в виде плагина.
То, что у Вячеслава, чистый плагин. Если же делать по другому - правила 
(логическое выражение с операндами маска wmclass group, имя события) и 
action (смена раскладки, передача события в плагин, ничего не делать), 
то это чистый core, причем без гуя. Гуй - плагин, который рисует 
актуальный для решаемой им задачи набор виджетов и добавляет правила в 
этот engine.
Плагины в таком случае тоже регистрируются правилами. Нажал чекбокс 
"активизировать плагин" и плагин через API прописал пару правил для 
передачи нужных ему событий на себя. Отжал - отписался. Резко упрощается 
конфигурирование плагинов, оптимальность некотрая.

> > Вячеслав правильно уловил слабое место переключателки, которое можно 
> > сделать сверхсильным.
> >    
> :)
>  
>
> > Это прямая работа переключателки с xkb с хранением конфига в gconf.
> > Либо это будет минусом (грузим конфиг при старте и больше не трогаем. 
> >    
> Это именно так и есть - только почему это минус?
Отсутствие плюса - потому что не дает возможности манипулировать 
раскладками на лету, хотя все для этого есть.
а минус в том, что работает толькол в гноме.
так что приходящие ничего нового не найдут, а уходящие - соскочат.

>  
>
> > Вызов конфигуратора раскладок не в счет), либо плюсом  (быстрое 
> > включение/выключение предконфигуренных раскладок, настройка раскладок в 
> > соответствии с окружением). В первом случае дублируется усекновенная 
> > функциональность конфига в XF86Config-4, во втором появляется мощный 
> > механизм динамической адаптации раскладок во время сеанса работы. Такого 
> > лично я еще не видел и такая функциональность весьма актуальна и 
> > дорогого стоит...
> >    
> Дорогого? Маркетингово это стОит столько, сколько пользователей будут
> реально эту фишку пользовать:). 
Везде, где есть три и более раскладки - одна или более всегда лишняя.
Переключение происходит по кругу. И в нем постоянно сидят "мертвые 
души". Так что использовать будут.

> Программно это стОит перезагрузки
> конфигурации xkb в XFree - чего я до сего дня всеми силами пытался
> избегать. 
нечасто. раз в полчаса, раз в день.
насчет пооконной конфигурации - наверное, перебор. А включить/отключить 
раскладку (не стирая ничего! просто enable/disable)- очень полезно.

> И еще. Я считаю достоинством сегодняшнего gswitchit то, что конфигурялка
> - конфигурирует (активная сущность), отображалка - отображает
> (реактивная сущность). Да, некие "активные" задачи отображалке
> приходится выполнять (например, переключение per window) - это немного
> портит общий имидж. Но то, что вы предлагаете, товарищи, это резкое
> усиление активной роли отображалки. Концептуально это меня немножко
> напрягает - соббсно, отображалка начинает становиться какой-то
> менеджилкой.
>  
Ага. Она наполняется актуальностью. А жирок стрясем, прежде чем 
расчехлять анюту...


> Короче, против предлагаемой идеи XKB config per WM_CLASS у меня такие
> возражения:
> 1. Перегрузка конфигурации сильно дороже переключения группы.
> 2. Наращивание мускулов апплета - мне не кажется удачной идеей. Вот
> всякий макияж, удачная стрижечка, маникюрчик - вы понимаете, о чем я:)
>  
Надо обсуждать.