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?=

[=?koi8-r?q?=E1=CC=C5=CB=D3=C5=CA_=EC=C0=C2=C9=CD=CF=D7?= <avl l14 ru>]

> > Мне кажется, что попытка вести девелопмент сразу на английском -
> > большая ошибка.
> >    
> А если я иначе не умею? Серьезно, это не выпендреж. Дискуссии на русском
> - сколько угодно. А вот документы, даже начального периода - рука не
> подымается на русском соображать. Уже много лет так живу. Я даже не
> помню, когда последний раз писал доки на русском - возможно, это была
> диссертация:)
>  
тады понятно.

> > Имхо, стоило бы переводить roadmap с обсужденного русского варианта и 
> > класть рядом.
> >    
> Я бы сказал так - берем ROADMAP.sxw (аглицкий, текущий - он уже в CVS, в
> модуле web) - и меняем (если надо). Если кто хочет - переводит на
> русский. Законодательно объявляю _оригиналом_ именно этот документ. Все
> прочие (html, переводы и пр.) - производные. То же будет с TODO и пр. Я
> надеюсь, OpenOffice как стандарт на документацию никого не обременит?
>  
меня -  нет.

> > и это ЗДОРОВО! :)
> > такие жалобы - двигатель прогресса.
> > А если никому не нужно более 4-х раскладок и никто не заметит?
> > А если таки снимут это ограничение? Редизайн?
> >    
> Видите ли. Это не просто API. Это реально протокол (точнее, расширение
> протокола X), по которому говорят клиент с сервером. Вы готовы начать
> борьбу за протокол XKBPLUS (условное название) в рамках XFree как
> "работу над ошибками" XKB (я уже не спрашиваю по переговоры с тем же Sun
> по реализации его в Solaris, например)? Боюсь, что я нет. Все-таки я
> "этим всем" занимаюсь в свободное от работы и семьи время - и его у меня
> не настолько много. Пока что ни RedHat, ни Sun (ни Alt:) меня на
> fulltime по департаменту клавиатуры не взяли:)
>  
речь не о войне за новый протокол, а о том, чтобы ограничение было 
адресным, коли оно есть.
Наличие ограничения в xkb еще не значит, что его надо всюду воспроизводить.
Мне вот четырех раскладок за глаза хватает. А кому то нет. И этот кто то 
не должен жаловаться на апплет, что там 4 кнопки, а сразу адресоваться к 
xkb.
Будет много народу - исправят.
Кроме того, я уже говорил, что список подготовленных групп может иметь 
больше 4x элементов. Из них 4 группы могут быть включены одновременно.


> > Я тут малек запутался.
> > Как я понял, связь между конфигуратором и монитором   (за исключением 
> >    
> паразитных связей) идет через xkb
>  
>
> > gconf <=> конфигуратор => xkb => монитор <=> gconf
> >    
> Более-менее так.
>
>  
>
> > Настройка default group концептуально должна быть в xkb и тогда 
> >    
> :))) В xkb много чего должно быть - чего там НЕТ. И что мы с этим делать
> будем?
Оценивать необходимость и либо обходить, либо нет.

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

> > Это важно, потому что такая настройка обязана быть общесистемной и 
> > используемой всеми (к примеру, виджеты для ввода паролей ). Иначе в
> > ней просто нет никакого толка.
> >    
> Ну да, ну хорошо. Но мы имеем тот xkb, который имеем. И капплет,
> конфигурирующий xkb, не должен задавать настройки, актуализируемые
> только апплетом. Тчк.
>  
>
> > Как костыль, конечно, можно ее продублировать в апплет. Она
> > пригодится, как хороший парметр для дефолтных предустановленных
> > правил. И то не уверен, что в аплете это так уж необходимо.
> >    
> А где???? Предложите решение, плиз, в рамках существующего XKB. И этот
> "костыль" в апплете - на века. Пока не протолкнете XKBPLUS.
>  
Отзываю предложение. Дефолтная группа в таком виде не нужна.

> > По минимумум, да.
> > В идеале бы сделать флаги в виде битовой маски , чтобы в уи можно было
> > лист с чекбоксами сделать и ловить только нужное, а не движок с
> > числом.
> >    
> Я думал про это. То ли число, то ли маска. Остановился на числе. По
> хорошему, надо бы 2 параметра - но это уже слишком сложно для такой
> маленькой системы. См. предыдущие письмо про log4j/log4c. Я думаю, на
> сегодня достаточно того, что есть.
ладно.

> > В конфигураторе имеем список групп с кнопками добавить/удалить/вверх
> > по списку/вниз по списку. Каждая группа имеет свойство - enable и
> > соответсвующий чекбокс в листе. Добавил я, к примеру, 4 группы. (лично
> > у меня -три рус, англ, фр) Но мне одна из них нужна только изредка
> > (лично мне фр. нужна для сестры раз в полгода). Я беру и выключаю
> > чекбокс этой группы и работаю с тремя раскладками.
> >    
> Вот опять Вы все в один флакон запихали! Добавление раскладок (не
> групп)! - сфера деятельности конфигуратора xkb. enable/disable работают
> только при присутствующем апплете (в данном случае - для групп, кстати -
> но мы их считаем взаимно-однозначными в 4.3.0:). Или Вы сознательно
> хотите сказать пользователю, что клавиатуру он _обязан_ конфигурить
> _только_ добавив апплет? Я - категорически против.
>  
Неа. Это другое.  Апплет через плагины управляет маской вторичных групп.
А тут все по взрослому. Есть галочка - есть раскладка, нет галочки - нет 
раскладки.
Таким образом можно завести 10 раскладок и пользовать любыми 4 
раскладками из них в любое время.
Естественно, придется перегружать xkb, что и делает конфигуратор. 
Операция вовсе не по оконная и относящаяся именно к конфигурации клавиатуры.

>  
>
> > Отчасти такое решение снимает остроту ограничения в 4-ре раскладки, 
> > поскольку перемещает его из области "4 раскладки" в еще более редкую 
> > область "4 активных раскладки"
> >    
> Да я понял. Я не против. Только не путайте настройки xkb с настройками
> каплета. Это все нормально - гибкость в установлении secondaryGroupMask
> глобально и per window (в перспективе - per widget).
>  
Не путаю. secondaryGroupMask - в апплете. перезагрузка xkb - в конфигураторе.
Это разные операции и разный функционал.



>  
>
> > нет. так никто писать не будет.
> > Стоимость реализации такой индикации в плагине заведомо превысит ее
> > пользу.
> >    
> Почему? Вдруг кто-то захочет написать крутой индикатор на основе GtkGL
> (например, в виде летящей русской двуглавой курицы - и потягивающегося
> британского левы)?:) Мне это не будет дорого - а людям приятно:) Это-то
> как раз все достаточно дешево реализуется.
>
>  
>
> > Функция могла бы быть
> > SetForeground(color)
> > SetBackground(color)
> > SetBorder(color)
> > AddMask (pixbuf)
> >    
> Угу. А с флагом как поступать? Плагин пыжится, пытается поставить
> Background - "а я в танке".
Вот поэтому флаг нефункционален.
для флага только AddMask (pixbuf).

> > А если два плагина начнут свои виджеты подставлять по очереди? Дожно 
> >    
> Приоритет. Мы же договорились, что плагины упорядочены. Первый плагин,
> предоставивший свой widget - получает право его отобразить. Остальные
> игнорируются. Правда, "второй круг" - произвести кастомизацию уже
> установленного виджета - предоставляется всем плагинам.
>
> Короче, вариант с подобной кустомизацией GtkWidget (как предложено выше)
> - с одной стороны, мне почти ничего не будет стОить чисто технически. С
> другой - позволит плагинописателям (если они захотят) добавлять bells &
> whistles (если хотят, конечно). Те самые "маникюрчик и стрижечку".
не думаю. скорее, глюков наловим по самое небалуйся.
добавлем плагин, а его виджет молча проигнорирован. А он к нему лезет с 
методами этого самого виджета, который выкинут. segfault?
Корректная кастомизация вида без знания типа виджета - тот еще гемор и 
опять стоимость этого действа будет запредельной.