GNOME 2.10.2

> Это accessibility(или как-там-оно-называется) для слепых.Просто бюджетное.

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

> Во-первых, ты просил работающий пример изменения размеров в gtk-приложениях - я тебе его привел. Эти параметры затрагивают кнопки, которые находятся внизу. Я не искал (и не собираюсь это делать) параметры, которые меняют ВСЕ кнопки. Это просто пример, а не решение твоей "проблемы".

Да я изначально просил тему или просто gtkrc, которые бы мне вписали save as гимпа в 800x600. Все заговорщически молчали, поэтому я начал сам ковырять, где там можно выиграть по паре пикселов, чтобы ещё уменьшить размеры окна. В итоге - неудача.

> Во-вторых, ну скажи мне, куда еще уменьшать эти кнопки? они и так маленькие, даже для моего разрешения.

Дык цель смотри выше. Я ж не говорю, что я с этим в итоге буду работать (хотя при 800x600 или даже 1024x768 это ещё вполне реально, мышью попасть не так сложно). Я и сам понимаю, что высоту кнопки меньше, чем высота синей иконы дискеты, уже не сделать :) Но всё равно там зазор ещё есть.

> Диалог abiword спокойно влезает в экран, даже полностью раскрытый. Давай не будем говорить о вещах, о которых не знаем?

Я не о том, влезает он или нет. Я о том, сколько места в нём потеряно впустую. Сам посмотри. В итоге список файлов уже даже не найти с первого взгляда, а ведь он там наиболее важен IMHO.

> Советую, посмотри как выглядит на самом деле GtkFileChooser (например в bmp). Все остальное нагородили разработчики GIMP! И в следующий раз прошу аргументировать крики типа "gtk СПОСОБСТВУЕТ".

Ну, а какой вывод ещё можно сделать из сравнения диалогов gtk2 с остальными на http://saveasdialogs.narod.ru ? Какое-то у них выборочное сумасшествие, только любителей gtk2 настигает.

> Ты сам себе противоречишь. То ты говорил, что во всем виноваты разработчики gtk, то в голову ударило разработчикам гимпа...

Не, gimp - это критический случай. Это называется "они нашли друг друга" (разработчики gimp и gtk), результат получился просто неописуемый. Ты сам посмотри, там список расширений в два раза шире списка файлов. Это клиника уже какая-то :)

> В 48-й раз говорю.

По-моему, 40 из них ты говорил сам себе :)

> Мне с 800x600 еще НИ РАЗУ не приходила в голову мысль о том, что диалоги gtk слишком большие, даже когда я сохранял в гимпе (я просто не разворачивал тип файла). Это надуманная проблема!

"Если мне удобно - удобно всем". Всё, больше вопросов не имею :)

> Это называется "они нашли друг друга" (разработчики gimp и gtk),

Осподя, ну зачем-же так дико тупить-то, а? :)

Gtk = The GIMP ToolKit

> Осподя, ну зачем-же так дико тупить-то, а? :) Gtk = The GIMP ToolKit

Ой, блин, ну вы с init'ом бы хоть сначала договорились, что ли, а? :) Вот это я кому выше писал, а? "В курсе, как расшифровывается gtk?", http://www.linux.org.ru/view-message.jsp?msgid=986566&nocache=110997929#9...

по поводу синей иконки, - создай в теме свой икон стайл ,сделай 1x1 пикс. в цвет фона обзови как положено, например:

stock["gtk-goto-last"] =
{
{ "stock_last.png", *, *, *}
}

м по-идее можешь ужимать кнопку дальше, если уж на столько мешает. Но с эргономикой у gtk-писателей действительно недружба. Имхо, от лени.

О, знающий человек! Кстати, это правда, что первые разработчики Гимпа давно забросили свое детище, которое подхватили потом совсем другие люди?

> Что касается GIMP. Основной смех в том, что в GIMP 2.0 диалог save as был ещё вполне себе небольшой и, кстати, позволял изменять свою высоту в отличие от 2.2.3): http://saveasdialogs.narod.ru/gimp-2.0.4-linux.png (промежутки меж кнопками и границами окна, впрочем, такие же огромные, но тогда это ещё не было столь страшно). Но потом разработчикам в голову ударила мо... пардон, креатив, и получилось в итоге вот это: http://saveasdialogs.narod.ru/gimp-2.2.3-linux.png :)

Да... У меня в gimp-2.0.3 этот самый диалог выглядит ещё лучше, чем у вас в 2.0.4. Видать у них полный регресс происходит в интерфесе от версии к версии.

С/у, Ден.

>>Видать у них полный регресс происходит в интерфесе от версии к версии.

Уж незнаю почему, но виндовый гимп самой распоследней версии выглядит просто замечательно. Вот что значат жёсткие стандарты там, где они действительно нужны :).

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

Хамура Кусаки, адмирал

>Мне просто интересно, почему заточка программы под графический фреймворк должно сказываться на функциональности программы?

потому что в кде к примеру, есть не только чисто визуальные вещи. есть KConfig, kio-slaves, dcop и т.п. тебе объяснить как программа использующая этот функционал будет ущербнее без оного или сам поймешь?

>потому что в кде к примеру, есть не только чисто визуальные вещи. есть KConfig, kio-slaves, dcop и т.п. тебе объяснить как программа использующая этот функционал будет ущербнее без оного или сам поймешь?

с тем, что в таких фреймворках как кде или гном есть много невизульных компонентов, я и не спорю. только есть одна маленькая деталь - можно написать прогу, которая будет использовать в работе некую библиотеку (абстрагируемся от имен и названий), являющую собой конгломерат вызовов других либ, плюс обертка в виде своего апи. что получим в итоге? бинарник, завязанный на кучу либ, без которых он работать просто не будет. такая прога наврядли получит большое распространение. или я не прав? в пример могу привести xmltv - кто ставил из сырцов, поймет (там одних перловых модулей метров на 12 ставить надо, да у них еще и свои зависимости есть). И не потому что мне трафика жалко, или винта. нет! Просто на кой мне девелоперские перловые модули, если я не являюсь разработчиком на перле? "чтобы было"? это уже похоже на одинокую лыжу, торчащую у многих на балконах "на всякий случай"...

ИМХО не стоит превращать винт в файлопомойку только потому что бинарнику А для работы нужна либа Б, а ей еще с добрый десяток прог, которыми я никогда не воспользуюсь. Природа любит красоту и простоту, а человек стремится все усложнить. зачем?

Бросить и подхватить != Передать разработку :)

Полагаю, будет излишне говорить, что разработчики GIMP _очень_ активно работают над gtk. Что касается диалога open/save file, которому уже все косточки промыли, то, вроде бы, не секрет, что он может быть _очень_разным, вплоть до копирования вида и функционала любимого многими диалога из gtk 1.2.

Это разве хорошо, когда в разных приложения диалоги примерно одинакового содержания (save/open) выглядят по-разному? Вообще, стандартными диалогами должна заниматься системная либа, такая как System.Windows.Forms вкупе с Win32, а не какой-нибудь там AbiWord ;)

Также интересно, а к работе над GTK-темами и GTK-диалогами, вообще, привлекаются профессиональные дизайнеры, или это во многом продукт just-for-fun сильно увлеченных творчеством программеров?

> Я не о том, влезает он или нет. Я о том, сколько места в нём потеряно впустую. Сам посмотри. В итоге список файлов уже даже не найти с первого взгляда, а ведь он там наиболее важен IMHO.

Что может не нравиться в диалоге save as абиворда? Маленькое окошко, можно будобно выбрать куда сохранить файл, если в нестандартный каталог - разворачиваем список. Причем и развернутый он влезет даже в 640x480. Где там впустую место тратится?

> Ну, а какой вывод ещё можно сделать из сравнения диалогов gtk2 с остальными на http://saveasdialogs.narod.ru ? Какое-то у них выборочное сумасшествие, только любителей gtk2 настигает.

По мне, из этих скриншотов самыми удобными кажутся диалоги из программ на gtk-2.6 и kde. Единственное, что выбивается из колеи - так это развернутый диалог гимпа, но это уже притензии к самому гимпу, а не к gtk.

> "Если мне удобно - удобно всем". Всё, больше вопросов не имею :)

Я думаю, тебе стоит посмотреть на себя, ведь ты даже не используешь gtk в 800x600, а просто решил придраться к чему-нибудь. Или ты тоже за всех говоришь?

> Это разве хорошо, когда в разных приложения диалоги примерно одинакового содержания (save/open) выглядят по-разному? Вообще, стандартными диалогами должна заниматься системная либа, такая как System.Windows.Forms вкупе с Win32, а не какой-нибудь там AbiWord ;)

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

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

> Что может не нравиться в диалоге save as абиворда?

Ты погоди, к нему тоже есть вопросы ;)

Итак, AbiWord 2.2.8, Linux.

1. Нафига лейбл "Save file as type:" прижат к левому краю, тогда как соотвествующий комбо-бокс находится справа? Что это за такой огромный интервал между ними?

2. Совсем не понятен смысл горизонтальных иконо-кнопок над списком файлов (какая-то иконка, tmp и tmpdir). Если глубина вложенности будет большой, то это будет выглядеть красиво?

3 (менее важно). Зачем нужны кнопки Add и Remove, если их можно переместить в контекстное меню? Неужели так часто приходится добавлять и удалять разные каталоги?

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

В общем, у меня остается впечатление какой-то общей недоделанности.

> Мне бы было интересно посмотреть на стандартный диалог, который бы удовлетворял требованиям к примеру gimp (превью картинки), ethereal (что именно сохранять) и обычного программы, которой просто нужно выбрать место.

Мне нравится то, как сделано в винде. Там есть такой стандартный режим показа как "Эскизы страниц", хотя он конечно не отменяет Preview. Кстати, показывать Preview или нет - это может быть определено как параметр или разновидность стандартного диалога (так сделано в Swing), ведь превью всегда глобально и не зависит от конкретного приложения.

Случай с ethereal сложнее. Лично мое мнение таково, что объект сохранения должен определяться до открытия диалога Save, то есть не здесь. К сожалению, почти ничего больше не знаю об ethereal - могу судить о нем только по тем выложенным в интернете скриншотам. В данном случае многое зависит от специфики приложения. Если кратко, то во время Save лучше заниматься только самим сохранением.

> Мне бы было интересно посмотреть на стандартный диалог, который бы удовлетворял требованиям к примеру gimp (превью картинки), ethereal (что именно сохранять) и обычного программы, которой просто нужно выбрать место.

Посмотри, как это сделано в винде. Скриншот есть. Верхняя часть у всех стандартная, а вниз диалог можно расширять, добавяя свои извраты. Не позорься :)

> Также интересно, а к работе над GTK-темами и GTK-диалогами, вообще, привлекаются профессиональные дизайнеры, или это во многом продукт just-for-fun сильно увлеченных творчеством программеров?

По-моему, достаточно посмотреть на сами темы, чтобы понять, кто их делал :)

Например, движок Clearlooks и ряд тем вокруг него, на мой взгляд, -- достаточно профессиональная работа.

При этом хватает тихих ужасов, особенно среди немногих тёмных тем.

> Что может не нравиться в диалоге save as абиворда?

Ну, поехали.

1) Чудовищное количество места пропадает между FileBrowser и кнопками внизу. Что, никак нельзя было пихнуть "Save file as type" справа от "Save in folder" под "Name" (что было бы, кстати, ГОРАЗДО логичнее)? Сколько места освободилось бы для ОСНОВНОЙ вещи - file browser!

2) Хочу в file browser просто иконы с именами, в несколько столбцов. В подавляющем большинстве случаев мне на..ать на modified при сохранении.

3) Зачем вообще большие промежутки между виджетами, особенно по горизонтали? Какую смысловую или технологическую нагрузку они несут? Просто забить собой экран, чтоб из-под диалога save as не было видно других окон?

4) Кнопочки папок слева от Create Folder - это неуклюжая попытка заменить дерево каталогов? Не логичнее ли было сделать это дерево раскрывающимся слева, из FileSystem?

> Маленькое окошко, можно будобно выбрать куда сохранить файл, если в нестандартный каталог - разворачиваем список. Причем и развернутый он влезет даже в 640x480. Где там впустую место тратится?

Интересный критерий. Если окно влезло в 640x480 - значит, место нигде не потрачено? А чё его тогда точно размером в 640x480 не сделали, а? Потраченное место - это место, которое пустует, хотя могло бы быть занято тем же file browser'ом, я об этом писал выше. Один проём между "Save file as type" и самим списком чего стОит.

> По мне, из этих скриншотов самыми удобными кажутся диалоги из программ на gtk-2.6 и kde. Единственное, что выбивается из колеи - так это развернутый диалог гимпа, но это уже притензии к самому гимпу, а не к gtk.

Объясни мне принцип, в соответствии с которым разработчики решают, делать опцию "Show hidden files" в диалоге СОХРАНЕНИЯ файла или нет. В Bluefish есть, в Abiword - нет. В чём разница? Покажи мне пальцем юзабельность в диалоге bluefish, где список файлокаталогов занимает весьма незначительную часть окна и теряется среди прочих элементов. Зато пустого места под ним - необъятно. Это и есть твоё удобство? Разработчики gliv не сделали "save as type", но пустое место внизу всё равно оставили. Так, на всякий случай. А то диалог маленький получается - несолидно. Зато Inkscape'овсцы постарались этот элемент (тип файла) выпятить по максимуму - за счёт высоты. Или у них просто руки тряслись? И эти люди ругают windows-приложения за неудобные диалоги? У меня вообще ощущение, что gtk-диалоги делаются для людей с расстройством координации движений. Размеры кнопок сравни с виндовыми (см. скриншот из photoshop). Виндузятники как-то умудряются не промахиваться мышью мимо таких кнопок и не жаловаться, но пользователям gtk-приложений это, похоже, недоступно.

> Я думаю, тебе стоит посмотреть на себя, ведь ты даже не используешь gtk в 800x600, а просто решил придраться к чему-нибудь. Или ты тоже за всех говоришь?

Меня просто коробят такие безграмотные диалоги. Да, обычно использую 1024x768 и 1280x1024, но иногда приходится иметь дело с 800x600.

>> Также интересно, а к работе над GTK-темами и GTK-диалогами, вообще, привлекаются профессиональные дизайнеры, или это во многом продукт just-for-fun сильно увлеченных творчеством программеров?

> По-моему, достаточно посмотреть на сами темы, чтобы понять, кто их делал :)

Ну ладно, а диалоги?

> а человек стремится все усложнить. зачем?

вот именно! допустим я разработчик и делаю "тесно интегрированную" в кде софтину. зачем мне усложнять и делать в ней кучу проверок и своих эмуляций dcop kio-slaves и т.п.?

>й на кучу либ, без которых он работать просто не будет. такая прога >наврядли получит большое

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

>в пример могу привести xmltv - кто ставил из сырцов, поймет (там одних >перловых модулей метров на 12 ставить надо, да у них еще и свои >зависимости есть). И не потому что мне трафика жалко, или винта. нет! >Просто на кой мне девелоперские перловые модули, если я не являюсь >разработчиком на перле?

А какая разница? просто Perl язык такой, что у него в модулях находятся и "хидеры" и "либы" и "документация к ним"

>ИМХО не стоит превращать винт в файлопомойку только потому что >бинарнику А для работы нужна либа Б, а ей еще с добрый десяток прог, >которыми я никогда не воспользуюсь. Природа любит красоту и простоту, а >человек стремится все усложнить. зачем?

Имхо в файлопомойку превращается виндовый винт, после минимальной доустановки....

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

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

> Покажи мне пальцем юзабельность в диалоге bluefish,

Покажите пальцем на Вашу соответствующую запись в багзилле

> Разработчики gliv не сделали "save as type", но пустое место внизу всё равно оставили.

То же самое

> Зато Inkscape'овсцы постарались этот элемент (тип файла) выпятить по максимуму - за счёт высоты. Или у них просто руки тряслись?

Спросите их об этом через багтрекер

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

Уже было. Вылилось в DLL Hell. Люди не умеют ничего делать организованно, им нужен человек с ружьём. Или с молоточком, чтобы по башке стучать.

> Мне нравится то, как сделано в винде. Там есть такой стандартный режим показа как "Эскизы страниц", хотя он конечно не отменяет Preview. Кстати, показывать Preview или нет - это может быть определено как параметр или разновидность стандартного диалога (так сделано в Swing), ведь превью всегда глобально и не зависит от конкретного приложения.

Так тут и есть стандартный GtkFileChooser, можно превью и все остально делать как параметры - но это неуниверсально. А так есть виджет для выбора файлов/каталогов и его можно пихать куда хочется.

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

> 1) Чудовищное количество места пропадает между FileBrowser и кнопками внизу...

Почему бы это не написать в багзиллу, а не на лор?

> 2) Хочу в file browser просто иконы с именами, в несколько столбцов. В подавляющем большинстве случаев мне на..ать на modified при сохранении.

А я не хочу и что дальше?

> 3) Зачем вообще большие промежутки между виджетами, особенно по горизонтали?..

Вполне нормальные

> 4) Кнопочки папок слева от Create Folder - это неуклюжая попытка заменить дерево каталогов? Не логичнее ли было сделать это дерево раскрывающимся слева, из FileSystem?

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

> Интересный критерий. Если окно влезло в 640x480 - значит, место нигде не потрачено?

Я не говорил, что там все место оптимально занято. Просто это окно достаточно маленькое и удобное. Что еще нужно-то?

> Объясни мне принцип, в соответствии с которым разработчики решают, делать опцию "Show hidden files" в диалоге СОХРАНЕНИЯ файла или нет. В Bluefish есть, в Abiword - нет.

Спроси об этом разработчиков bluefish. Такой опции делать отдельно не надо, так как она включается в контекстном меню.

Размеры кнопок зависят от темы и от шрифта.

> Покажите пальцем на Вашу соответствующую запись в багзилле

Мэтры гнома переходят в состояние глухой обороны... Кстати, [IMHO] был выбран не самый удачный про... пост с описанием недостатков GTK-диалогов. Поэтому хотелось бы услышать конструктивный ответ на другой пост от 12.07.2005 14:31:49, хотя знаю, что он явно адресован не Вам, но затронутая в нем тема совпадает.

Итак, кто готов защитить тот нелепый GTK-диалог из AbiWord 2.2.8 без этих смешных отмазок на багзиллу?

Произошла небольшая накладка. Имеется в виду пост от 12.07.2005 15:07:44 с описанием тех нелепостей, что были найдены в диалоге сохранения для AbiWord 2.2.8.

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

в пределах разумного - да, спорить не могу. но когда это доходит до опеределнного размера, то превращается в фреймфорк - а это уже, имхо, "закрытая" вещь "в себе". попробуйте написать приложение сложнее банального "привет, мир", чтобы оно имело функционально одинаковй интерфейс в разных фреймворках. например, в гноме и кде. очень сложно. а линукс именно и ценен свободой выбора. если ее не будет, получится второй оффтопик. к этому собственно и идет. "optimized for gnome 2.x.x", "required kde> x.x.x." - ничего не напоминает?

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

от себя, как разработчика, скажу спасибо за наставление на путь истинный. только вот давайте определимся, что считать "общей базой знаний"? то что работает в одной конкретно взятой среде, или то, что реализуемо на оснобе базовых библиотек, не зависящих от ДЕ? Или по-прежнему будем считать, что весь мир ездит на таком же отполированном запорожце с тонированными стеклами, как у нас? и куда при этом уходят рекомендации posix и стандарты ieee?

>вот именно! допустим я разработчик и делаю "тесно интегрированную" в кде софтину. зачем мне усложнять и делать в ней кучу проверок и своих эмуляций dcop kio-slaves и т.п.?

встречный вопрос - на кой это надо было людям, разрабатывающим kdiff3? или тем, кто пишет приложения на чистом qt? чисто чтобы выпендриться?

заметьте, я ни от кого ничего не требую. просто мне обидно обламываться, когда прога "тесно интегрирована" куда-то. где тот самый unix-way, которым так славится линукс?

> А я не хочу и что дальше?

Предоставить эту возможность на выбор. Что, так сложно додуматься? Я думал, ты умный мальчик. Тем более, что образец уже есть - диалоги в windows. Бери и сдирай удачные находки :)

>> 3) Зачем вообще большие промежутки между виджетами, особенно по горизонтали?..

> Вполне нормальные

Ты не ответил, в чём их назначение.

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

Зачем они мне, если я хочу сохранить совсем не в той ветви, которая сейчас текущая? А это частая ситуация.

Если они тебе так нужны, можно оставить. Но почему не сделать оба варианта?

> Я не говорил, что там все место оптимально занято. Просто это окно достаточно маленькое и удобное. Что еще нужно-то?

Это твоё IMHO и не забывай его указывать. Для меня оно неудобное, могло быть существенно меньше и разумнее занято. Но - не судьба с gtk, видимо.

> Размеры кнопок зависят от темы и от шрифта.

Ты видел шрифт на моих скриншотах? А gtkrc я тебе показал? И? В чём теперь дело, что им теперь мешает?

> Покажите пальцем на Вашу соответствующую запись в багзилле

Как я понимаю, это прямое признание ляпов? Даааа, а много их, я смотрю. В одном только диалоге save as. А уж сколько в остальных местах...

Проблема вот в чём. Это не баг, это генетика. Если дизайнер делает такие очевидные ляпы, то багзилла не поможет. Ему просто надо в школу :)

> Это не баг, это генетика. Если дизайнер делает такие очевидные ляпы, то багзилла не поможет

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

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

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

P.S. Самый первый пост про недостатки диалога SaveAs в AbiWord был мой. Также мне принадлежит один из постов про недостатки SaveAs в GIMP :)

> Мэтры гнома переходят в состояние глухой обороны...

Да нет, просто я не вижу проблемы. Нынешние диалоги кажутся мне _в целом_ более удобными, чем старый из gtk1, хотя _мелочей_ не хватает.

Что касается остального... Если сто человек будут обсасывать одно и то же с такими же пользователями как и они сами, их проблемы точно не решатся. Если они будут обсасывать свои проблемы с разработчиками через багтрекер -- это будет выглядеть уже не как выёживание одиночки, а как признак того, что и правда что-то не так. И что это что-то надо исправлять.

Поэтому аргумент про "смешные отмазки на багзиллу" я принять, извините, не могу.

По поводу "поста от 12.07.2005 14:31:49". Вы знаете, я не понял, на что именно я должен ответить :) Я могу специально поставить abiword и посмотреть, что в нём не так, если Вы скажите, чего именно от меня хотите :)

> Произошла небольшая накладка. Имеется в виду пост от 12.07.2005 15:07:44

Ааа, ну значит поставлю, посмотрю и отвечу. Хотя init по существу уже ответил про возможности и то, как их используют :)

> Как я понимаю, это прямое признание ляпов?

У меня нет проблем с признанием того, что какие-то вещи в любимых мной программах реализованы не совсем корректно для всехили для некоторых. Я даже могу признать, что vim может быть очень неудобен для фаната емакса, а корел -- для фаната иллюстратора. Вам от этого станет легче дышать? Тогда я с радостью :)

> Если дизайнер делает такие очевидные ляпы, то багзилла не поможет. Ему просто надо в школу :)

О такой вещи как "замыливание глаз" слышали? А о недостатке времени на то, чтобы поправить все мелочи? Ну чего Вы тогда в школу всех отправляете? Может Вам просто скучно одному в этой школе, компанию ищете? :)

> Предоставить эту возможность на выбор. Что, так сложно додуматься? Я думал, ты умный мальчик. Тем более, что образец уже есть - диалоги в windows. Бери и сдирай удачные находки :)

Я имел в виду то, что если тебе так нравится - это не обязательно должно нравиться другим. Вот разработчикам так понравилось, скорее всего в будущих версиях добавят что-то еще (gtkfilechooser еще совсем молодой), но пока они сделали так и я чувствую для этого были причины. И кстати, я не понимаю, зачем там вообще нужна горизонтальная прокрутка с несколькими столбцами? По-моему это ужасно неудобно.

> Ты не ответил, в чём их назначение.

Зачем нужны вообще нормальные промежутки? Хорошо, скажу, они нужны, чтобы все не "слипалось" вместе.

> Зачем они мне, если я хочу сохранить совсем не в той ветви, которая сейчас текущая? А это частая ситуация.

Они не для таких случев сделаны. Для этого есть Ctrl-L и закладки.

> Но - не судьба с gtk, видимо.

Давай в раз и навсегда определимся. Ты ругаешь gtk или abiword с гимпом? В GTK *возможно* делать очень маленькие окна и виджеты.

> Ты видел шрифт на моих скриншотах? А gtkrc я тебе показал? И? В чём теперь дело, что им теперь мешает?

Хорошо, шрифт такой же. Но если ты уж и начал сравнивать с виндой, то там тоже многие диалоги не влазят во весь экран. Я молчу про дефолтовый стиль заголовков окон в WinXP и меню пуск, который просто ужасно выглядит при 800x600. А видел скриншоты лонгхорна? Там же все просто огромное. Наверное они тоже не разбираются в дизайне UI.

> Итак, кто готов защитить тот нелепый GTK-диалог из AbiWord 2.2.8 без этих смешных отмазок на багзиллу?

Большинство этот диалог вполне устраивает, зачем его защищать? Тебя не устраивает - пиши в багзиллу. Может разработчики изменят его, а может объяснят, почему они этого делать не будут.

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

А разве плохая "юзабельность" - это факт?

> Поэтому аргумент про "смешные отмазки на багзиллу" я принять, извините, не могу.

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

Как вы себе представляете следующую ситуацию? Предположим, что человеку, который уже несколько лет работает над AbiWord, вдруг приходит письмо, где приводятся "ошибки" его artwork дизайна. Какой будет его дальнейшая реакция?.. В лучшем случае он просто проругается.

Еще раз повторю основную мысль. Если бы дизайном GTK-диалогов занимались бы профессиональные дизайнеры, а не девелоперы, то меньше было бы ляпов. Лично для меня разнобой среди GTK-диалогов Save говорит об очень многом. Что касается виндовых- и KDE-приложений, то там дела обстает с этим гораздо лучше - их интерфейс единообразнее и продуманнее.

> А разве плохая "юзабельность" - это факт?

Здесь фактов быть не может по-определению, зато есть стойкое ощущение неудобства и некоторой нелепости GTK-диалогов по сравнению с диалогами KDE и Windows. Причем этот топик показывает, что подобные ощущения разделяют многие.

Еще такое дополнение. Вряд ли мы сможем договорится о том, что является юзабельным, а что нет. Также трудно определить то, каким следует быть диалогу Save. Здесь будут бесконечные споры. Зато мы можем пойти по другому пути - пути отрицания, согласившим в том, чего заведомо не должно быть в диалогах и прийти, так сказать, к "консенсусу" :)

Итак, в одном из своих прошлых постов я утверждал, что в диалоге SaveAs для приложения AbiWord есть 2.2.8 есть серия ляпов в дизайне, который позволяют мне считать тот диалог SaveAs неюзабельным. Можете опровергнуть?

>. "optimized for gnome 2.x.x", "required kde> x.x.x." - ничего не напоминает?

да. это и есть выбор. не под что то одно как в оффтопике. xcdroast, k3b, graveman

>или то, что реализуемо на оснобе базовых библиотек, не зависящих от ДЕ

поверьте мне, небольшая kdelibs не зависит от kdeartwork, kdegraphics, kdemultimedia, etc. ;)))

>разрабатывающим kdiff3

вы привели не самый удачный пример

>просто мне обидно обламываться, когда прога "тесно интегрирована" куда-то

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

>где тот самый unix-way, которым так славится линукс

dcop, kio-slaves =)

> Как вы себе представляете следующую ситуацию? Предположим, что человеку, который уже несколько лет работает над AbiWord, вдруг приходит письмо, где приводятся "ошибки" его artwork дизайна. Какой будет его дальнейшая реакция?.. В лучшем случае он просто проругается.

Неа. Здесь Вы как раз ошибаетесь. Мне уже приходилось писать в багтрекеры разных программ о таких вещах и _ни разу_ я не получал в ответ ругательства или любой иной негатив. Обычно -- нормальные толковые обсуждения о том, как именно можно исправить ошибку, вслед за чем ошибка или исправлялась, или это откладывалось ввиду более важных дел.

Теперь Вы понимаете, почему я действительно не могу принять Ваш аргумент про отмазку? :)

>вы привели не самый удачный пример

ну почему же? объясните причины его "неудачности". желательно, с аргументами, а не только "потому что!".

>dcop, kio-slaves =)

проекты с аналогичной функциональностью (альтернативы) назовите пожалуйста. желательно, существующий вне рамок кде, например, в такой ДЕ как гном. (хотя как api ipc может зависеть от ДЕ я пока не понимаю)

>да. это и есть выбор. не под что то одно как в оффтопике. xcdroast, k3b, graveman

5 баллов за неознозначный ответ на неоднозначный вопрос! ,) хороший выбор! "Сына, ты какую кашу будешь: гречневую или манную?" про то, хочет ли дитя кашу или котлеты никто не интересуется. Объясните, чем лучше наличие выбора между 2-мя ДЕ в будущем линкса, или выбор между двумя версиями "самой лучшей оси"? имхо, принятие одного из двух монстроидальных ДЕ, одобренных партией это уже как обращение в определенную веру.

>поверьте мне, небольшая kdelibs не зависит от kdeartwork, kdegraphics, kdemultimedia, etc. ;)))

верю, здесь Вам наверное виднее, т.к. у меня нет кде. только "небольшая" я бы все-таки взял в кавычки.

Но здесь идет речь не об ошибке в том смысле, который привычен для технически образованного человека. Речь идет о том, что конкретный диалог по сравнению с точно такими же диалогами из KDE и Windows смотрится нелепо по приведенным выше причинам [с моей точки зрения, точки зрения некоторых моих знакомых, а также некоторых посетителей ЛОРа]. К тому же, судя по скриншотам это явление стало массовым для GTK-приложений... О каком багрепорте может идти речь? Другое дело - провести время на ЛОРе ;)

В конце концов, "на цвет товарища нет". Посему предлагаю закругляться с этой темой.

> Итак, в одном из своих прошлых постов я утверждал, что в диалоге SaveAs для приложения AbiWord есть 2.2.8 есть серия ляпов в дизайне, который позволяют мне считать тот диалог SaveAs неюзабельным. Можете опровергнуть?

Я не специалист по дизайну и согласен, что в abiword могут быть проблемы с этим в диалоге save as. Но это относится к самой программе, а не к gtk. Та же самая ситуация и с gimp.