Tcl/Tk 8.5a5 is released.

Так скриншот таки будет или нет? Я ничего не имею ни против Tile, ни против его разработчиков, ни против sk, ни против тебя лично - но раскрашенных менюшек в Tile как не было так и нет. Аргументация его разработчиков - "А в вендовсе всё и так хорошо работает!"
Собственно эту мысль я и хотел донести до пользователей ЛОРа. Возражений я пока не слышал.

>> Tcl это не язык для кода. Это язык для скриптов.

> согласен, хотя он и для скриптов не канает.

Ага. Скрипты лучше на C. А ещё лучше на ассемблере.

> но -- так таки а tk-то зачем если к tcl-ю привязки нет?

К тиклю привязки не может не быть. Но не надо ограничиваться тиклем вообще. Он не для больших программ.

> он не проще, не красивше ни разу, не функциональнее всего остального прочего.

Например, тикль не функциональней C или ассемблера. Или не функциональней транзистора КТ315. И совершенно не функционален против пластмассового стаканчика из под кофе... (ключевое слово -- ВСЕГО).

> Ломают, как правило, новомодное и сквозь дырявое. wuftpd я не просто так упомянул..

Ага. У меня proftpd.

>>ага. и зоопарк кода.

Это уже называется домотался. Типа, зайти куда-нибудь на сайт типа CTANа и начать возмущаться : "Что тут у вас такое! Зоопарк кода, нах! У вас кто-нить тут сертифицирует совместимость пакетов? Мне нужно чтоб beamer вместе с prosper одновременно работали. Бардак тут, панимаишь, нах.Что типа пользователь будет этот ваш CTAN размером в парочку гигабайт себе на диск скачивать, нах! Нех! Да если мне надо я служебную записку лучше в KWord накарябую. " Ну и тд

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

Да и не виста это ни разу.

Мосье устроит такое? ;)

http://sk1.sf.net/screenshots/sk1_menu.png

Надеюсь понятно, что иконки просто не проставлены еще для всех пунктов?

>>http://sk1.sf.net/screenshots/sk1_menu.png
Ну, так бы сразу и говорил. А то - "показывать или нет, меню и меню итемов там нет"
Что это за версия tile и какой командой выпадающее меню сделано?

Шрифты гавно!

>Ну, так бы сразу и говорил.

Угу, пока скрин сделаешь, пока на SF выставишь... Tile 0.7.2 но меню сделано стандартными тиклевскими средствами, без тайловских виджетов.

>>http://sk1.sf.net/screenshots/sk1_menu.png > Ну, так бы сразу и говорил. А то - "показывать или нет, меню и меню итемов там нет" Что это за версия tile и какой командой выпадающее меню сделано?

Смутно догадываюсь, это всё делается и без tile. В особенности меню. Просто вместо separator там, догадываюсь, вовсе не сепаратор, а command с опцией disabled и натянутым поверх image. Ну и -bd 1 везде.

Ещё раз -- ОНО НАСТРАИВАЕТСЯ. Весьма разнообразно. Это вам не Gtk/QT, где всё гвоздями прибито.

Шрифты, шрифты... Мне вот интересно, когда какая-нить ананимуса наконец-то заметит CMYK colorspace саппорт в девелопмент версии sK1?

анонимус -- мудак!

Милостиво позволяю быть затейником;)

Неужто всего лишь хп???;)

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

Это все замечательно, но как это реализовать с помощью ресурсов? Пусть даже не image на menuitem наложить, а даже в простейщем случае просто bevel у всех виджетов сделать поуже? Чтоб они не такими выпуклыми были... Даже на приведенном выше скриншоте с tkabberом bevel довольно нестандартный. Как этого добиться?

На одних ресурсах далеко не уедешь.

Колись тогда!

echo "*Menu*BorderWidth: 10" > ~/.Xresources && xrdb < ~/.Xresources

На хорошие программы, в которых гвоздями не прибито, это оказывает впечатляющее воздействие.

Да не переживай ты так.
Это у онанимусов такой рефлекс, как у собаки Павлова. После предъявления скриншота нужно тяффкнуть -"Шриффты гаффно!"

>>echo "*Menu*BorderWidth: 10" > ~/.Xresources && xrdb < ~/.Xresources
А для кнопки? Любого виджета?

> неудобного,

Я смотрю, Вы высококвалифицированный специалист по юзабилити, угадал? Что по Вашему мнению удобно? Ущербный Gnome, или может быть, KDE?

> отсталого, плохо вписывающегося в современное окружение..

Ну, да. Ну, да. Знаем эти байки! :)

> Tcl это не язык для кода. Это язык для скриптов. Код надо писать на более других языках. Это -- ОПЫТ (негативный...)

Интересные господа fk0 && dmiceman. Один хвалит Тк, другой хз что. Но оба сошлись во мнении, что Tcl - это максимум для детских скриптишек. Но вот я не понимаю, как BMW и другие крупные конторы пишут на Тикле. И никак из головы не выходит скриншот с количеством ошибок и качеством кода в разных языках. Брались Ява/Си/не помню что еще/Тикль. И по качеству кода и ошибок он зарулил все.

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

foreach {array as value} {

...

} elseforeach {

...

}

Такую вещь вы не сделаете ни на Питоне, ни на Руби. Это практически полный аналог Лисповских деревьев, только без скобок.

Для Руби можно за счет анонимных блоков сделать примерно такое:

first_of (fvalue, svalue, tvalue) {|v| print v

}

В питоне нельзя сделать и этого (ибо лямбда кастрирована).

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

> Но не надо ограничиваться тиклем вообще. Он не для больших программ.

Откуда такое предубеждение? Что по Вашему "большая программа"?

foreach {array as value} {

...

} elseforeach {

...

}

А что это значит? C foreach понятно, но elseforeach нигде не документировано.

А в чем таки "конкретный ужас без вариантов" ? Голых баб нет на десктопе ?

Дык код есть на SF.... Конкретный пакадж - sK1_v.0.9pre01.tar.gz/sK1_v.0.9pre01/sK1/Sketch/UI/tkext.py

Со всем уважением к интересному языку Tcl, его возможностям и наследию (ничего не буду говорить про масштабируемость, бо мой опыт с ним скромен) - все-таки интерфейсы на Тикее выглядят действительно ужасно "из коробки". Очевидно, решение "полдня возиться с ресурсами, потом за полчаса долететь" не рассматривается.

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

Почему "ужасно"? Что именно Вам надо от интерфейса?

По-моему очень простенько, чистенько, быстренько и абсолютно никаких нехороших излишеств, никаких eye-candies и bells'n'whistles.

>решение "полдня возиться с ресурсами, потом за полчаса долететь" не рассматривается

А что, уважаемый Svu, вы считаете, что простому пользователю гораздо проще самостоятельно тему для GTK нарисовать и енжин сбоку присобачить? Или все-таки юзеру - юзерово, а дизайнеру - дизайнерово?

> Но, насколько я сужу по тенденциям(тот же sk1), все что можно скриптуется, а что нельзя, профилируется и пишется на СИ.

Логично подмечено :) Для кнопарей и диалогов скорость не нужна при работе - интерпретатора с головой. А для основного канваса - ясное дело не поскрипишь на нем. Именно поэтому тим sK1 и обходится скромным коллективом (прогер+дизайнер)

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

> Что именно Вам надо от интерфейса?

Вы, наверное, из тех, кому от автомобиля надо, чтобы ехал, а от мабилы - чтоб звонила.

Дык вот, есть понятие технического дизайна. Есть понятие современного и удобного технического дизайна. Относится оно в т.ч. и к графическому интерфейсу. Сегодняшний дизайн интерфейса (так получилось;) включает в себя то, что Вы называете "ай-канди" и "белз-н-вистлз". А то, где этого нет - не выглядит современным и удобным. Выглядит как Форд ТТ или Жигули "копейка" (и не надо пожалуйста, рассказывать, насколько они лучше современных железяк).

Простому пользователю не нужно делать темы и енжины. Ему просто достаточно выбрать из готовых. Сделанных теми, кто специально (чтобы не вешать красную тряпку, не буду говорить "профессионально") этим занимается.

2fk0: 2geekoo: сорри, но дискуссия зашла в закономерный тупик.

foreach {array as value} {

...

} elseforeach {

...

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

P.S. а кто-то же мне говорил что в питоне тоже корутины есть. нет?

> А что это значит? C foreach понятно, но elseforeach нигде не документировано.

Это пример того, что можно реализовать средствами языка :). Идея взята из section/sectionelse для пхп smarty. Тоесть можно сделать конструкцию форич, которая, если массив пустой будет выполнять альтернативное действие. Очень полезная функция для вывода в шаблонах. Например подставляем список грядущих событий - в форич выводится список, в елзе - "на данный момент событий не запланировано".

>>echo "*Menu*BorderWidth: 10" > ~/.Xresources && xrdb < ~/.Xresources >А для кнопки? Любого виджета?

Полностью аналогично. Надо понимать только что бывают виджеты вроде кнопки -- "примитивные", а бывает во Frame напичкано всяких кнопок.

Виджет, как и любое окно имеет класс. Соостветственно при задании шаблона ресурса можно использовать его. Или имя окна. С последним сложней и имеет смысл только для конкретных приложений (для задач вроде "покрасить именно вот эту кнопку в зелёный цвет"). К сожалению, для Tk не работает editres. :-( Поэтому единственным способом изучить структуру окон приложения (раньше эту информацию было принято приводить в манах, см. например man xterm xedit) остаётся только использование второго wish: вначале получаешь имя окна (winfo interps), а потом в указанном окне структуру окон (send appname winfo children .) Разумеется, чтоб не повлиять на все приложения разом будет разумным включить в шаблон имя или класс toplevel окна, если настраивается одно конкретное приложение. Да, класс виджета можно узнать примерно следующим образом: send appname winfo class <имя окна>. Большая часть "примитивных" виджетов, очевидно, узнаётся по внешнему виду...

При составлении ~/.Xresources надо помнить -- последними действуют строки оказавшиеся В НАЧАЛЕ ФАЙЛА. А при чтении ресурсов командой option readfile -- строки В КОНЦЕ ФАЙЛА. Это на случай, для конкретного виджета подходят сразу несколько шаблонов.

Имена опций можно посмотреть в man-странице, можно получить с помощью команды "send appname .имя.окна configure".

Если что-то не работает, то почему так можно понять поэкспериментировав с командами option add и option get.

Да, и ещё надо представлять как работает механизм ресурсов в X. Ресурсы могут браться (в порядке приоритета):

1) из файлов самого приложения (одним из механизмов тут является считывание файлов из каталога /etc/X11/app-defaults/ средствами самого приложения, например путём вызова XrmGetFileDatabase());

2) из ~/.Xdefaults (читаются приложением);

3) из X-сервера, куда они загружаются из ~/.Xresources, /etc/X11/Xresources при старте пользовательской сессии (это делает xdm или xstart).

~/.Xdefaults использоваться в настоящее время вроде как не должен... Пользовательские настройки должны лежать в ~/.Xresources -- и тогда они зависят от хоста где логин делался, а не где программа запускается (кажется, я уже сам запутался), а app-defaults служит для настроек именно приложения, а не пользователя.

>> Что именно Вам надо от интерфейса?
> Вы, наверное, из тех, кому от автомобиля надо, чтобы ехал, а от мабилы - чтоб звонила.

Абсолютно верно подмечено. Телефон для того, чтобы звонил (у меня Nokia 6310i уже много лет), а автомобиль, чтобы ездил и везде проходил (вседорожник).

На мой взгляд - тайловские темы проще. Присобачил в фолдере с аппликухой тему и есть гарантия, шо аппликейшин будет таким, как аффтар задумывал, а не так как бог на душу положил. Я Fontforge когда первый раз запустил - волосы дыбом встали ;)

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

> Это пример того, что можно реализовать средствами языка :).

нуу.. немного не то, но почти:

[1, 2, 3].each_else proc{|v| puts v}, proc{puts 'nothing'}

[].each_else proc{|v| puts v}, proc{puts 'nothing'}

не устроит?

> Интересные господа fk0 && dmiceman. Один хвалит Тк, другой хз что. Но оба сошлись во мнении, что Tcl - это максимум для детских скриптишек.

Почему как скрипт -- так сразу детский? Иной скрипт 10000 строк кода заменяет. Но это именно скрипт. Самое важное, наверное, в нём то, что ОН ПРОСТОЙ. Когда скрипт становится сложным (>1000 строк плюс-минус в 10 раз) -- НАДО БРАТЬ БОЛЕЕ ПОДХОДЯЩИЙ ЯЗЫК ПРОГРАММИРОВАНИЯ. Почему -- смотри ниже.

> Но вот я не понимаю, как BMW и другие крупные конторы пишут на Тикле.

Что именно они на нём пишут? Вот в чём вопрос. Если tcl используется в качестве скриптового языка в других приложениях, если tcl использустся как RAD средство для быстрой склейки чего-нибудь из чего попало -- это то для чего он предназначен. Если на тикле пытаться писать, например, Mozilla или OpenOffice оно развалится не успев начаться. Первой проблемой будет -- нужна объектная система. Это уже первый признак того, что НУЖНО МЕНЯТЬ ЯЗЫК.

Тикль прекрасный инструмент что-то сделать *быстро*, в качестве макета, когда нужен именно скрипт, когда объём кода небольшой и весь умещается в голове. Он даёт средства визуализации, программирования, интерфейсы (программные) к чему угодно. Даже с COM-портами более-менее единообразно работает. Это КЛЕЙ, который позволяет из всего чего угодно склеить новую программу. СКЛЕИТЬ, но не написать. Написать на нём сложно и плохо.

> И никак из головы не выходит скриншот с количеством ошибок и качеством кода в разных языках. Брались Ява/Си/не помню что еще/Тикль. И по качеству кода и ошибок он зарулил все.

Очень интересен был бы подобный скриншот для 100, 200, 500, 1000, 2000, 5000, 10000 и 50000 строк кода. Было б видно, как тикль выигрывая "на коротких дистанциях" начинает резко отставать на длинных. Хорошо, когда всю программу можно разделить на "короткие дистанции". Независимо от использования или неиспользование тикля. А когда нельзя -- на первое место, боюсь, выходят такие монстры как Java и C++ -- для программ с большим объёмом кода и сильными связями в нём. Для TCL основными проблемами, при росте кода, будет являться, как ни странно, то самое, что называют его преимуществами: отсутствие такого понятия как тип данных, как собственно для данных, так и для процедур -- ошибки времени исполнения; отсутствие компилятора -- синтаксические ошибки времени исполнения как расплата за динамическую компиляцию; отсутствие чётко устаканившейся объектной системы с единообразным интерфейсом ко всем объектам; отсутствие элементов "декларативного программирования" (например, как объявления в C) только усугубляет путаницу и ведёт к росту числа ошибок. Такие программы как "static syntax checker" помогают мало -- для этого и писать на tcl надо как на C... Писать многочисленные тесты -- ими все возможные ситуации не охватить, просто тестов не напасёшься.

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

Поэтому есть смысл стараться разделить всё на "короткие дистанции" и постараться их закодировать на C/C++, где это возможно. Если дистанция исключительно длинная -- TCL может быть лишь дополнением к логике программы реализованной на более подходящем языке (python, c++, java).

> Простому пользователю не нужно делать темы и енжины. Ему просто достаточно выбрать из готовых. Сделанных теми, кто специально (чтобы не вешать красную тряпку, не буду говорить "профессионально") этим занимается.

Я простой пользователь. Дурак вообще. Компутером пользоваться не умею. Как мне в QT или Gtk покрасить кнопку "Пуск" в одном из приложений в красный цвет. Никаких возражений не принимается -- хочу и всё тут, хоть убейся, но чтоб в красный цвет. Систему X-ресурсов я кое-как освоил. Не-профессионально, так, по-пользовательски. Умею перекрашивать кнопки в Xaw/Motif/Tk приложениях.

КАК НАПИСАТЬ ~/.gtkrc -- Я НЕ ОСИЛИЛ! Как сделать собственную тему для Gtk или QT не осилю тем более. Особенно если учесть, никакой документации (опять же -- осилил man, info и т.п.) на этот счёт нет.

Так вот для меня, как простого пользователя, я соглашусь, что внешний вид Tk приложений страшноват, система конфигурации GTK и QT представляется идиотской и не работающей. А X-ресурсы -- чётко работающий, ДЛЯ МЕНЯ, ПРОСТОГО ПОЛЬЗОВАТЕЛЯ, механизм, вполне доступный и понятный. Осталось только пожелать, чтоб авторы Tk-приложений и mantainer'ы дистрибутивов писали к ним вменяемые файлы ресурсов, чтоб покрасивее был.

Повторюсь -- Я ПОЛЬЗОВАТЕЛЬ. Может где я и программист, но не в области десктопных приложений. Да я "кое что в этом понимаю", но не слишком сильно, и глубоко вникать в это не хочется.

Странные ссылки на индустрию и миллионы потребителей (мух?)

У меня тоже нокия 6310i (как и у всей фирмы), меня не смущает и не раздражает вид motif или tk, я езжу на бюджетной Subaru, а не на порше.

В чем экзотика?

Цель индустрии продавать больше товара и для это потребители должны менять свои старые надежные вещи на модное и блестящее.

Только причем тут "убогость", по вашим словам, старых решений?

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

Отсутствие типа данных -- ФИЧА. Массив -- список. "Хеш" -- array или dict (tcl>=8.5).

Но опять, повторюсь, НА ТИКЛЕ НЕ НАДО ПРОГРАММИРОВАТЬ. Тогда и типы данных не прогодятся.

Что касается "," -- на нём ЛОМАЕТСЯ АБСОЛЮТНО ВСЁ. И единственным разумным выходом будет LC_NUMERIC=C и забыть этот кошмар. Просто потому, что иначе это ломает всю идеологию Unix -- нельзя сказать пойдёт вывод в глаза пользователю или на вход другой программе (да юзер может мышкой на десктопе перетащить -- чёрт знает куда). В языках программирования, например, используется всегда ".", а не что-то из локали. Понятно почему. Так и у postscript. С которым из-за этого тоже проблемы. Это НЕТЕХНИЧЕСКАЯ ПРОБЛЕМА. Хотя бы потому, что сам пользователь может такие числа засовывать в такие места, где формат ввода не определяется локалью. Поэтому разумный выход -- оставаться в рамках C-локали. А где очень нужно -- предусматривать ввод того и другого, предусматривать вывод чего-то конкретного в зависимости от того куда оно попадает или по команде от юзера. Иного разумного выхода (в качестве неразумного -- смотрим пример open office) НЕТ.

Спасибо :)

Стоило только заменить вставить *BorderWidth: 1 как дизайн TK приложений полностью преобразился. Как-то они посовременне выглядеть стали...

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

Да суть-то в чём, ОДУМАЙСЯ, чтоб ЮЗЕР МОГ СВОЙ ДЕСКТОП НАСТРАИВАТЬ, К А К Ю З Е Р З А Д У М А Л ! ! ! А не как аффтар. Хотя бы потому, что мне как юзеру, имея экран высокого разрешения не рассмотреть буковок в миллиметр размером, которые имели изначально мелкий размер на экране 800x600 у автора, а у меня зрение плохое. ВОТ ГДЕ ЮЗАБИЛИТИ. А не в идиотских разрисованых скинах.

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

У тайла из серьёзных плюсов -- функциональность виджетов отсутствующих в Tk вообще.

> Что касается "," -- на нём ЛОМАЕТСЯ АБСОЛЮТНО ВСЁ.

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

это если в узком контексте. а если в широком, то оно конечно да, согласен.

> Ваше право. Только почему же Вы (и многие подобные) до сих пор не справились понять, что Вас подавляющее меньшинство

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

> Никаких возражений не принимается -- хочу и всё тут, хоть убейся, но чтоб в красный цвет.

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

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

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

> Систему X-ресурсов я кое-как освоил

На основании чего позвольте вынести Вас из списков "простых пользователей";)

> Как сделать собственную тему для Gtk или QT не осилю тем более

И не надо. Вы же простой пользователь. Довольствуйтесь art.gnome.org

> система конфигурации GTK и QT представляется идиотской и не работающей

Они делают то, для чего предназначено (набор юз-кейзов прилагается). Ваш юз-кейз не укладывается. Это проблемы Ваши. И это точно не делает интерфейс Тикея симпатичнее;)

> Осталось только пожелать, чтоб авторы Tk-приложений и mantainer'ы дистрибутивов писали к ним вменяемые файлы ресурсов, чтоб покрасивее был.

Вот и посмотрим, когда это случится. Пока что Тикей из коробки убог.

> и глубоко вникать в это не хочется.

Вы не поверите - мне тоже! У меня есть дела интереснее (например, на ЛОРе флеймить;). В gtkrc я ковырялся в эпоху gtk1. Не одной темы я не сделал (не с моими дизайнерскими способностями...). Зачем, если этого барахла кругом навалом?

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

Вот почему все-таки нокия 6310i а не 3210 или вообще ериксон-кирпич на пол-кило? Может потому что когда брали был "модное и блестящее"?

И мне все-таки кажется что нормальный и не фанатеющий человек возьмет таки новый (пусть модный и блестящий, что для некоторых не труъ) УДОБНЫЙ, ЛЕГКИЙ, с БОЛЬШИМ экраном с которого удобно читать, и в придачу с bluetooth-ом чтоб hands-free на ухо повесить и спокойно разговаривать за рулём, а не вьехать в толпу или забор оттого что кирпич типа-телефон не дает нормально рулить.

> я езжу на бюджетной Subaru, а не на порше.

Как раз это скорее атрибут нормального потребителя (ну, возможно, Гольф был бы еще типичнее).

> В чем экзотика?

Именно в том, что Вы не больны консюмеризмом, как полагается;)

> Только причем тут "убогость", по вашим словам, старых решений?

Они не то чтобы убоги в абсолютном смысле (если такое бывает)... Они не отвечают представлениям потребителя о том, как должен выглядеть потребляемый товар. Убог ли Форд Т? Смотря как посмотреть... То же, кстати, про 6310.

> Я -- один

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