После изменения свойств отмеченного в списке объекта изменения теряются при выборе другого элемента списка. Т.е. необходимо жать "Применить" перед выбором другого элемента.
Это не бага. Так и задумано.
(In reply to comment #1) > Это не бага. Так и задумано. Верю, но это баг.
А я так не считаю.
(In reply to comment #3) > А я так не считаю. Зря, все остальные считают.
Ну про "всех" это несколько сильно сказано, но что улучшить есть всегда: http://lists.altlinux.ru//pipermail/sisyphus/2005-July/063514.html
добавлено предупреждение.
Так, с control понятно. А здесь-то чем обусловлено такое поведение, когда нельзя сначала много поменять, а потом всё применить?
1. Менять сразу большое количество альтернатив одновременно требуется ооочень не часто. 2. Это существенно усложняет реализацию. Для такой сомнительной функциональности усложнения слишком большие. Потерю данных я устранил. Если вы хотите добавить такую функциональность, то пришлите патч или открывайте новый баг (enhancement).
(In reply to comment #8) > 1. Менять сразу большое количество альтернатив одновременно требуется ооочень не > часто. Зато часто приходиться выполнять требование нажать кнопку :-) > 2. Это существенно усложняет реализацию. По сравнению с "пол-пинка" - да. > Для такой сомнительной функциональности Представь, что после каждого щелчка мышью в X-ах будут выводить диалог с просьбой подтвердить. > усложнения слишком большие. Не слишком > Потерю данных я устранил. > Если вы хотите добавить такую функциональность, то пришлите патч или > открывайте > новый баг (enhancement). открыл
(In reply to comment #9) > > Для такой сомнительной функциональности > Представь, что после каждого щелчка мышью в X-ах будут выводить диалог с > просьбой подтвердить. Зерг, не передёргивай. Лёша прав. Если надо много действий, то или дефолты кривые, или надо обобщать совокупности типично производимых действий в профили настройки (назначение системы, требуемый уровень безопасности). А не мышиный подход и беспокойство о "лишних" вопросах. Лучше проверьте, чтоб _все_ "длинные" действия сопровождались сменой (и восстановлением) курсора, это больше юзабилити вредило. :-)
(In reply to comment #10) > Зерг, не передёргивай. Ты вообще видел то, о чем речь? Там так и есть на самом деле.
Именно видел и меня это _устраивает_. В т.ч. с учётом тех, за кого отвечаю.
(In reply to comment #12) > Именно видел и меня это _устраивает_. Тогда не читай это багу :-)
А как же пооппонировать? :-) (если серьёзно, то ещё раз скажу за себя и своих пользователей -- не надо эту проблему решать предлагаемым тобой методом, костыли заменой user level, security level и прочих _макро_характетистик даже в количестве тысяч не являются) (на пальцах: если есть двести болтов и гайключом долго/неудобно, надо не форму ручки трогать, а или болтовёрт приспособить, или на конвейер с автоматическим болтовёртом, или на сварку перейти -- если снизить количество болтов нельзя) (кстати, следующие грабли будут именно с количеством объектов control(8), и об этом подумали года два назад -- они у нас вроде как тогда и были сделаны иерархическими, в смысле control samba/domain)
(In reply to comment #14) > иерархическими У альтернатив тоже есть один подуровень. Это, кстати, повод для еще одного enhancement
(In reply to comment #15) > Это, кстати, повод для еще одного enhancement Кстати да, но я не о том. Подумай, что вместо установки .rpm тебе надо раскладывать файлики по файловой системе руками, права на них ставить. Слакварь получается. Я и тут говорю -- не надо делать удобно стреляющий очередями намордник на control(8), не то это место. См. комментарий 10. И с альтернативами точно так же -- системы надо делать не так, чтоб их фиксить было удобно, а чтоб они этого по возможности не требовали.
(In reply to comment #16) > control(8) Причем здесь control?
> Причем здесь control? Тьфу ты, мне на alterator-control почудилось. Но они настолько изоморфны, что даже передокапываться не приходится -- сам "в уме" об alternatives и думал. :-) А смотрел (где-то на rcчто-то) и то, и другое; с тех пор с месяц точно не видел.
worksforme
будем считать, что не хранит, но предупреждает об этом
