Линус Торвальдс: Используйте KDE

> Не работают .. и ~. Я уже писал, что согласен с тем, что это баг, который нужно исправить.

Так ты определись для начала, что является ДЛЯ ТЕБЯ багом: '..','~' или 'N','P'.

Или одно баг, или другое. Или мы по нажатию клавиш ищем файл, или они у нас (не|слабо)документированные шоткаты. Или, или. Понимаешь? (NB. За невозможность искать файлы ~* и ..* тебе руки оторвут. Или голову. ;) Или еще какой орган.)

> Но это недочет всего лишь

О!!! Это огромная непоследовательность диалога. Или ты начинаешь набирать, и это -- путь; или ты начинаешь набирать, и это -- имя файла. Или, или. А тут и ни то, и ни сё. Так, сбоку бантик. Да еще и прибит криво...

> где тут минус самого смысла открывать строку только по требованию?

В неочевидности реакции диалога на требование. Вот если бы у Вас с браузере Location: по жизни отсутствовал, а при начале печати появлялся, если бы в консоли приглашение (readline, или кто там еще) отсутствовало, а при тычке в кнопку появлялось. Если бы текстовый ре..., хм, подобное есть (это у которого два режима: пищать и всё портить)... Если бы почтовый клиент про наборе буквы создавал бы новое письмо и услужливо начинал печатать. Если бы... Если бы...

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

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

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

>> Ну не удобен С для написания гуев.

>Походу - плюсы тоже (не говоря уж о ....)

А в гномовских прогах гуй разве не на xml делается(libglade)?

> Так ты определись для начала, что является ДЛЯ ТЕБЯ багом: '..','~' или 'N','P'.

Отсутсвие обработки ~ и .. - это баг, но про ~ я уже писал, что фикс в TODO. Следующий/предыдущий файл по hig должен выбираться стрелками на клавиатуре, а не P и N, поэтому это тоже баг.

> За невозможность искать файлы ~* и ..* тебе руки оторвут. Или голову. ;) Или еще какой орган.)

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

> О!!! Это огромная непоследовательность диалога. Или ты начинаешь набирать, и это -- путь; или ты начинаешь набирать, и это -- имя файла. Или, или. А тут и ни то, и ни сё. Так, сбоку бантик. Да еще и прибит криво...

Нет, все правильно. Когда ты просто набираешь имя файла - это "поиск" в текущем каталоге, а когда тебе нужно указать полный путь - ты пишешь обычно /usr/share.., по которуму открывается строка Location.

Это как в firefox, ты можешь по ссылкам ходить, набирая их имена (внизу появляется строка поиска) или писать полный путь в строке Location.

>Так ты определись для начала, что является ДЛЯ ТЕБЯ багом: '..','~' или 'N','P'.

Для меня багом является отсутствие явной строки адреса в диалоге. Она там должна быть - дружественность к домохозяйке означает "как в винде" - в винде она есть. То, что для продвинутых юзеров ввод адреса с клавы необходим - тоже, ИМХО, очевидно.

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

>Массовый приход мозиллы на десктоп начался с появлением "конечного продукта" огнелиса.

Сравните ФФ и Гном по удобству наращения функциональности.... хотя и не сравнивайте даже! :)))

Ну мы же не про это. Мы про разницу подходов "готовый продукт vs полуфабрикат". Зачем же сразу в другую плоскость переводить?;) Кстати, гном нарастить куда легче - достаточно использовать zenity в шелл скрипте. А вот попробуйте из шелла нарастить огнелис?;)

>минус разделение больших и малых букв - это "путь вводить"?:)

- это "не асилили", проигнорировали или "не заметили"?:)

>Мы про разницу подходов "готовый продукт vs полуфабрикат".

Тут уже даже init признал, что в "готовом продукте" куча "багов" в тривиальном окне открытия файла:)

"баг" написал в кавычках, потому что это "условный баг" - ИМХО баг - это то, что получается непроизвольно, здесь же это сделано явно НАМЕРЕННО. Я не знаю как правильно обозвать "намеренный баг" - в голову приходит только "ламерство", "вредительство", "снобизм" и т.п.:)

Есть идея. А есть реализация. И кривая реализация способна загубить самую распрекрасную идею.

<Кстати, гном нарастить куда легче - достаточно использовать zenity в шелл скрипте.>

А можно об этом поподробнее ? В документации как то не очень заметна наращиваемость и упор на возможность работы из скрипта с gtk-шным gui

Ну мы же не про это, елы палы (почему как аргумент в одной теме приводится вывод из другой?). Качества диалога открытия файлов никак не влияют на то, что гном рассчитан на то, чтоб работать из коробки и поставлять практически в том виде, в котором он лежит на gnome.org. Никто не говорит "вот вам заготовка диалога открытия файлов - а вы уж как-нибудь ее доработайте напильником". Раз сделали так - так и пойдет к пользователям. Хорошо или плохо - но так.

Это точно. Но это уже совсем другая история;) Мысль, которую я отстаивал в последних каментах - для успеха у конечного пользователя идея конструктора совсем не обязательно является выигрышной. Готовый продукт (если, конечно, справиться его собрать;) с минимальным брендингом может оказаться лучшим решением...

На самом деле, zenity - это так, малюсенький костылечек. Ничего серьезного реально не сделать.

>Я не знаю как правильно обозвать "намеренный баг" - в голову приходит только "ламерство", "вредительство", "снобизм"

Вредительство - это в точку. В принципе претензий к гному на данном этапе не так уж много по существу - с появлением таки нормального режима в наутилусе крупными плюшками являются файловый диалог и редактор меню - вернее отсутствие оного. Другое дело агрессивная упертость гномов что отсутствие возможности редактировать меню и for mouse use ony файловый диалог есть благо. И стремление идет не улучшить качество продукта, а ухудшить - при этом впихнуть юзерам под маркой "мы круты, за нами корпорации - и какую бы какашку мы не сделали, будете ее кушать."

>Никто не говорит "вот вам заготовка диалога открытия файлов - а вы уж как-нибудь ее доработайте напильником". Раз сделали так - так и пойдет к пользователям.

Вот-вот. Так сделали --- так и пойдет.

А ведь можно и по-другому: так сделали. Можете так и отправить, а можете и напильником доработать.

Последнее, имхо, к Гному слабо применимо, т.к. его заранее обточили....

>А ведь можно и по-другому: так сделали. Можете так и отправить, а можете и напильником доработать.

Да надо будет доработать. Но они там сейчас массовое переколбасение всего и вся начали - API ломается постоянно. ИМХО даже браться не стоит - вот как стабилизируются чуток, можно будет и хакнуть этот диалог - выкинуть какашку и встроить что-нибудь человеческое. Тем более что пока есть еще надежда что корпорации продавят таки удобный диалог - тут у тог о кто платит есть возможность заказывать музыку. Другое дело что они пока эту возможность не используют, позволяя гномерам самим рулить проектом как им хочется.

>Ответ на: Re: Линус Торвальдс: Используйте KDE от jackill 19.12.2005 23:37:02. Может все-таки надо читать не только ответы на свои посты? Тут все участвуют.

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

> Отсутсвие обработки ~ и .. - это баг, но про ~ я уже писал, что фикс в TODO.

То есть в TODO у них -- сознательное внесение бага в диалог и нарушение своих же правил? Моя смешно.

> Следующий/предыдущий файл по hig должен выбираться стрелками на клавиатуре, а не P и N, поэтому это тоже баг.

В TODO не сказано, когда этот баг уберут?

>> За невозможность искать файлы ~* и ..* тебе руки оторвут.

> Точно, это же такая важная возможность. Так каждый второй файл называется.

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

> Когда ты просто набираешь имя файла - это "поиск" в текущем каталоге

Да-да... Если только файл не начинается с определённых символов...

> когда тебе нужно указать полный путь - ты пишешь обычно /usr/share..

Когда нужно указать _полный_. НО! Мне _редко_, _крайне_ редко необходимо указывать полный путь, чаще всего обхожусь _относительными_. Полный указываю только для всяких http:/, ftp:/, smp:/ и прочих fish:/...

Кстати, как мне открыть в стандартном диалоге гнома файл с fish:/user@host/pash/file или webdavs:/?

> Это как в firefox, ты можешь по ссылкам ходить, набирая их имена (внизу появляется строка поиска) или писать полный путь в строке Location.

В FF уже спрятано поле ввода Location:, и появляется при начале набора (f|ht)tp:/ ?

PS. А меж тем я уже много сообщений назад говорил, как избавиться от непоследовательности интерфейса -- позволить в строке поиска файла указывать путь. Или отказаться от этого "поиска", и добавить поле Location: (Name:), можно по аналогии с диалогом сохранения.

Linus Torvalds Tue Dec 13 13:44:23 PST 2005

> I suspect that what you see as a raging hatred for user configuration is
> instead just a symptom of what we consider important in GNOME. We are
> willing to prioritize "working well out of the box" and "consistent and
> easy to use" over user configuration. So that particular set of
> features just never bubbles up to the top. As near as I can tell it
> just is a question of priorities.
I don't understand why you and Havoc seem to be of the opinion that
working well out of the box and having good defaults is in any way
something I argue against.

I absolutely don't. I think it's very important that defaults should be
sane, and the "out of the box" experience should be what a user can be
expected to, well, expect. I was kidding about "focus-follows-mouse" being
the only true window focus method: click-to-focus does actually make sense
as a default, because it's what a lot of users are brought up to expect.

Similarly, I do actually agree with people who say that KDE is cluttered.
The KDE menu system is overwhelming. But that's a totally separate issue
from the notion of _capabilities_. You can decide to have a uncluttered
desktop that is still _capable_. I believe we've seen that with some of
the distros that do use KDE, eg Linspire.

So you can have your cake and eat it too. It's not an either-or thing.

> That doesn't mean that we don't need to fix printing, and the printing
> dialog - we still do. But it means that fixing printing is probably
> going to take a higher priority than adding new features to the window
> manager. :)
I really don't care about the mouse thing. It's the reason _I_ hate using
gnome, but hey, I've got alternatives.

The reason I exploded is that (a) I've been watching this desktop thing
because I got added to the mailing list by mistake and (b) the gnome
disregard for flexibility has been grating me for a _long_ time.

To me, open source _is_ about flexibility. And no, I'm not talking about
people re-compiling their applications and making changes to them. The
fact that the source code is open is in some ways both the least important
and the most important part: it's the least important in the sense that in
practice, very few people actually change source code, and even those that
do tend to be very _focused_ on one particular project (or even just a
small _part_ of a project).

So the source being open is - on average - not important to people
directly. Even major developers only work on a small part of the whole
stack at a time, they don't go around changing all the programs they use
to suit them.

But _indirectly_, the thing that open source really excels at, is the
flexibility it offers thanks to having lots of users, and lots of users
whose needs get _heard_. THAT is the core of open source. You've got
different kinds of people that get attached to a project. It's _not_ a
corporate mono-culture, because people from different backgrounds can get
together and work on it _without_ going through the corporate mind-wash.

And to me, gnome is killing itself as an open source project, because it
ends up dismissing exactly that thing. Having strict UI rules ("The HID
says so-and-so") that are really a religion that you're not allowed to
question. The whole notion that things are supposed to be done just one
way is antithetical to what makes open source successful in the first
place.

I think the KDE development process has been a lot more "lively", and I
think a _lot_ of the reason for that has been that they haven't allowed
the "interface nazi" kind of stifling of what people feel they need to do.
Read the recent KDE-3.5 release announcement with the "visual guide to new
features", and you can _feel_ the energy. Sure, they have three different
kinds of desktop choosers. So what? You don't have to use them. But the
capabilities are there if you want to.

And I think that's important. It's important, because that developer
energy, in the end, is what get things done. And as a side effect, you
will automatically end up with a system that understands that defaults may
be good, but that different people have different needs and views. Because
you had a very diverse group of people that worked on it.

So developers are more energized, and I think users are also automatically
happier. They may not even realize why, but I believe it's to a large part
because their needs are taken care of - not necessarily because they ask
for it, but because the developers themselves are more varied and thus
tends to have more different needs, and often took care of the different
needs of the user base to some degree automatically.

This, btw, is also why a "enterprise desktop" should never be allowed to
drive development. It is, by definition, boring and same-old, same-old.

And if you don't see the parallels with "enterprise UNIX" and "Linux"
here, I think you're blind. The thing is, Linux (the kernel) got better
than just about any enterprise Unix kernel _not_ by trying to develop
itself for the enterprise, but by allowing and encouraging different kinds
of people to all scratch their own itch.

Yeah, the whole development process is a bit more chaotic, and maybe a bit
more "cluttered" and even scary, but the end result is BETTER. And yes,
Linux (the kernel) has a million drivers that the "serious guys" don't
care for. But that wild and crazy thing is exactly what made Linux a
success in the first place.

> In any case, this is a different question that hasn't been asked here,
> and one that I think people are stumbling over and that is "what are the
> effects of design decisions on the size of an open source-based
> community where choice is more important than design focus?" I suspect
> that given that question I would expect that the KDE community would be
> larger, but less focused on a single vision.
I agree - I think this is part of it. But see above. I think it's a small
part of a much bigger issue.

> > But the fact that users and developers don't know does NOT mean that
> > customization is bad. Quite the reverse. It means that defaults make
> > sense, but since you don't know what they'll be doing, you should always
> > strive to have ways to let _them_ make the choice when they have some
> > reason the default doesn't agree with them.
>
> I kind of agree with this statement, but I think it's overused to
> justify all kinds of nonsense and avoid good system integration.
The thing is, developers shouldn't see themselves as system integrators.
If they do, they just limit the end result.

This is a hierarchy. You don't put the developers at the top of the heap,
the same way you never put developers face-to-face with your customers.
That would just scare the customers away.

You let developers be developers. Encourage a bit of crazyness, because
the best developers _are_ a bit crazy. It's ok. Let them do things that
you don't think necessarily always make sense for the user, because that
not only makes them happy, it's also how sometimes you get the really
great things that _do_ make sense after all.

And encourage them to make things configurable, so that the system
integrators and distributors can then make it all come together as a
more unified whole. Maybe it won't be _totally_ unified, but what you win
from allowing people to be people _more_ than makes up for it.

Thinking that developers should also have to be aware or care about the
crazy UI HID notion of the day is just stupid. It just alienates
developers. And don't tell me that Gnome as a project hasn't alienated a
lot of developers, because some of them have been emailing me privately as
a result of this flamewar.

Linus

Оказывается Линус --- это не только каждый второй анонимус на ЛОРе.

в цитаты +))))))))))

Вот.

http://www.linux.org.ru/view-message.jsp?msgid=1205436&back=group.jsp%3Fg...

Имхо замечательно демонстрирует проблемы гнома.

>Имхо замечательно демонстрирует проблемы гнома.

Замечательно демонстирирует только проблемы некоторых личностей :)

Т.к. во0первых, можно переключиться и в виндовй порядок.

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

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

Людям банально неудобно.

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

хех гномовцам плевать на привычки тех кто привык пользоваться виндой. Ну не глупо ли, при том что они хотят таких пользователей иметь под гномом, и таких пользователей > 90% ?

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

Забавно, что Линус использует словосочетание "interface nazi", когда намекает на гномовский HIG :)

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

Вообще-то, нормальным людям бросить взгляд на 3..5 градусов в ту или иную сторону - даже глазом водить почти не нужно, это практически в пределах поля чёткого зрения. Но даже если ты сидишь вплотную уткнувшись носом в 21" монитор, и то глазом двигать быстрее и проще, чем мышью :D

Хотя, может, у тебя и иная эргонимка... глаз, там, тяжёлый :D

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

А чё сказать-то хотел? Про то, что "нормальные люди" - это те, у которых "3..5 градусов" и не-21" монитор перед носом и постоянно вращающие глазами?:)

Не понимаешь. Давай еще раз.

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

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

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

>Вообще-то, нормальным людям бросить взгляд на 3..5 градусов в ту или иную сторону

А я и не спорю. Но ты начало предложения откуда ищешь? Неужели справа? Слева.

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

Вот ты посмотрел влево, вот сигнал пошел в мозг, клавиша cancel, посмотрел правее (ты же слева направо читаешь), клавиши нет, посмотрел левее cancel, не та клавиша, посмотрел еще раз левее. Клавиша ok, отдаем команду на руку, тянемся к кнопке указателем мыши, щелкаем.

Не дураки же сидели много лет и лепили ok слева, а cancel справа.

> Мне тут в треде (читай) сообщили, что юзеру удобнее и быстрее тянуться мышью к правой кнопке.

вам и гномерам навешали лапши полны уши!
дефолт справа удобнее только арабам.

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

В случае гнома уме прижется прочитать все кнопки, напрягая мозг по максимуму. В случае КДЕ и других мозгом обдумать придется только 1 кнопку.

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

> дефолт справа удобнее только арабам.

Парень ты какой рукой ширинку застегиваешь ? На какой стороне сотку носишь. Пальцем в детсве тыкал какой рукой ?

Может ты и левша, но правшей адин хер больше. Так-что учимся добавлять к таким петициям волшебное слово IMHO

>> дефолт справа удобнее только арабам.
> Может ты и левша, но правшей адин хер больше.

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

> ты не понял мой пост,

Да нет "дефолт справа удобнее только арабам".

А если к 3-м кнопкам. Согласен что _почти_ все процессы можно представить бинарным деревом, но не будет ли тогда диалог напоминать, то, что в M$ называют "мастерами" ? Т.е. безконечная цепь диалогов построенная по принципу да-нет. Хорошо - первый раз пользователю легче пройтись по этой цепочке, но во все последующие разы он будет тыкать в две одинаковые кнопки и мечтать об 1 диалоге со всеми настройками и кнопками разом.

>вам и гномерам навешали лапши полны уши! дефолт справа удобнее только арабам.

Вообще я об этом и говорю. Это был сарказм.

Дефолт удобнее слева, потому что взгляд читает слева направо.

>Парень ты какой рукой ширинку застегиваешь ? На какой стороне сотку носишь. Пальцем в детсве тыкал какой рукой ?

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

>Согласен что _почти_ все процессы можно представить бинарным деревом, но не будет ли тогда диалог напоминать, то, что в M$ называют "мастерами" ?

Представь-ка мне бинарным деревом OK Cancel. Потом OK Dismiss Cancel.

Обрати внимание как взгляд у тебя движется при появлении таблички.

> Линус Торвальдс: Используйте KDE

а кде не так страшен, как казалось из гнома:-)

> Ты читаешь справа налево

Несмотря на дислокацию еще нет ;) Просто дефолт справа - более логичен с точки зрения правши. А теперь представь интерфейс на тачскрине ? Какой из вариантов более юзабелен и универсален для тачскринов и обычных мониторов ? Пульты на станках видел ? Догадайся с какой стороны находится "шайба" (кнопка экстренного останова) ?

А вообще самое либеральное решение - дать пользователю возможность выбора какой интерфейс диалогов выбирать - "[левосторонний|правосторонний][простой|средний|продвинутый|ultra violence]" ;)

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

ok<->cancel

Ключевое слово почти , но второй пример не удачен тем что dismiss без apply не нужен.

Ты давал ссылку на ixbt-ую статью про маки. Так вот, хоть конечно это не по теме, но мне показалось, все проблемы маков решаются открытием исходников их макоосей, я конечно имею ввиду не ядро, а оболочки. Они вполне смогут вести бизнес как это делает redhat, novel. И всех овиндевших админов, которые привыкли админить движением мыши они могут увести к себе.

>Пульты на станках видел ? Догадайся с какой стороны находится "шайба" (кнопка экстренного останова) ?
По логике это должна быть не кнопка, а педаль (лучше две, нажимаемые одновременно :-)), а то не дай бог, руку (любую) в станок засосало :-)

Насколько помню (по работе на прессовке) педаль там наоборот запускает цикл. А шайбы в основном на фрезерных и распиловочных станках ставят под правую руку, a сам пульт достаточно далеко от рабочей зоны.

Затянуть может во фрезерный и то если тупо сунуть руку под фрезу. А в распиловочный не затянет - просто руку оторвет.

>Затянуть может во фрезерный и то если тупо сунуть руку под фрезу. А в распиловочный не затянет - просто руку оторвет.
И огрызок - пульнёт прямо на заветную кнопку :-)
P.S. Работал с разными станками, самый опасный из них - гильотина. Это буз шуток.

>Они вполне смогут вести бизнес как это делает redhat, novel. И всех овиндевших админов, которые привыкли админить движением мыши они могут увести к себе.
Заманить может и проститутка. А вот заставить остаться надолго - только настоящая женщина :-)

<Заманить может и проститутка. А вот заставить остаться надолго - только настоящая женщина :-)>

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

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

:-)

>Просто дефолт справа - более логичен с точки зрения правши

Если бы мы не умели читать - не вопрос. Если бы каждая кнопка кодировалась на рычаг и мы размещали рычаг - тоже не вопрос.

>Вот только что-то мне подсказывает что отцы Gnome будут долго этому сопротивлятся мотивируя это тем что "пользователь ниасилит многа буков"

Чорт, опять забыл (но в faq записал) есть переменная на эту тему.

>Ключевое слово почти , но второй пример не удачен тем что dismiss без apply не нужен.

Это реальный диалог, только не помню откуда. Там было dismiss или discard, ok и cancel. Ok - типа выйти и сохранить, cancel - прекратить выход и discard/dismiss - выйти и не сохранять.

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

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

>Насколько помню (по работе на прессовке) педаль там наоборот запускает цикл. А шайбы в основном на фрезерных и распиловочных станках ставят под правую руку,

Ты несколько путаешься. У тебя мышь ВСЕГДА под правой рукой (если ты правша). Я тебе и говорю - если на кнопки отдельные педали сделать, наверное HIG прав. Но у нас не педали.