пилять 15 лет языку а до сих пор в локали koi8-r работать невозможно. окна ввода в Tk нифига не принимают русский, кое-где в widgets нельзя вывести русский, потому что iso-фонты намертво вбиты в код Tk. просто tcl имеет большие проблемы с прозрачной конвертацией koi8-r->internal unicode->koi8-r. кто держит русифицированных ирк-ботов, тот меня поймет

Может он там у них и успешен... Если оценивать меру успешности языка по количеству изданных книг, то очень странная катрина получается. Книжек про perl разной степени качества и понятности--море. Про python--в последнее время тоже хватает. Про тикль была ождна доненькая книжка страниц на 80 и все. Есть Welch, да он немного того. дорог. Да и найти его сложно. В Москве--разве что в Волькоме.

Tk, так просто и не описан. Приходится разбираться по примерам и исходникам

Так что, про успешность и популярность я умолчу.

Был приятный пакет tix, содержащий неплохое расширение виджетов для Tk, да и тот загнулся.

Опять же. несколько раздражает необходимость держать одновременно установленными несколько версий tcl. И иметь геморрой с выяснением того, какой tclsh/wish у меня сейчас запущен...

В общем странный он какой-то, этот tcl...

TCL сосет аднозначно, Perl рулит... ну и Python тоже ниче.

Для web'а всё любопытней глянуть на ruby.

> Был приятный пакет tix, содержащий неплохое расширение виджетов для Tk, да и тот загнулся.

это почему загнулся. на SF последний релиз (8.1.4) датирован 14.12.2002

меня вот интересует что такое tix-8.2.0b1 которое не один год идет в дистрибутивах redhat и крайне глючно по сравнению с tix-4.1.0.6 который я привык использовать...

>>>15 лет языку а до сих пор в локали koi8-r работать невозможно. окна ввода в Tk нифига не принимают русский, кое-где в widgets нельзя вывести русский, потому что iso-фонты намертво вбиты в код Tk. просто tcl имеет большие проблемы с прозрачной конвертацией koi8-r->internal unicode->koi8-r. кто держит русифицированных ирк-ботов, тот меня поймет

ирк ботов у меня нет, как и проблем с русским в тикле. Можно привести пример, который воспроизводит ваши проблемы, "кое-где в widgets" - это не разговор. ИМХО может быть стоит ~/.Xdefaults поковырять? "iso-фонты намертво вбиты в код Tk." - это вааще бред (мб имелись ввиду фонты по-умолчанию?).

Tcl, не буду говорить про Tk, удивительно простой и прозрачный язык, к тому же у него очень хорошее взаимодействие с другими языками (С, Java, тот же Perl), за счет чего можно быстро клепать свои Tcl-подобные языки. Так что он еще долго проживет.

dea (*) (2003-03-13 14:23:22.243)

Ужас!

geekkoo ну вот вы подскажите что и где нужно поковырять чтобы в обычную entry используя xxkb можно было что-то по-русски написать

> ирк ботов у меня нет, как и проблем с русским в тикле.

наверное, вот этот товарищ http://www.45.free.net/~vitus/ice/tcl/locale-tcl.html с потолка свои проблемы брал... посмотреть на отношение к кириллизации со стороны скриптикс так и все желание юзать tcl пропадет

> где нужно поковырять чтобы в обычную entry используя xxkb можно было что-то по-русски написать

xxkb не использую. русский вводится на-ура везде. что я делаю не так?

wish8.3 [~]grid [entry .e -textvariable z]
wish8.3 [~]set z
Привет
wish8.3 [~]string toupper $z
ПРИВЕТ

Как видите проблем нет. Можно еще попугать tk опцией -font cronyx-*, но это уже екстрим.

Тоботрас же предлагал патчи для тиклей весьма лохматых версий (последняя была альфа 8.3.1). Приведенный пример на 8.3.3.

Вот еще пассажи из интервью, которые мне понравились

What do you like most about Tcl?

Andreas: The power in simplicity.

What is the coolest thing you've seen Tcl used for?

Mark: Two early Tcl projects that totally blew me away were the Shell Auger Platform (in which Tcl programs controlled all the wellhead operations for 32 drillheads on a floating oil well thing floating in the Gulf of Mexico), and the use of Tcl in the Mars Explorer project (the one that didn't crash!).

Во-первых, уже давно не скриптикс, а ActiveState. Во-вторых, в ветке 8.4 проблемы с i18n решены. Если с этим глюки -- вешайте багу на sourceforge, можно на меня (a_kovalenko).

В-третьих, проблемы со вводом через xkb были очень быстро решены в tk -- и то, что RedHat не обновлял tk ещё пару лет, -- это проблемы redhat'а.

По поводу Tix -- версия 8.2.0b1 хоть как-то работает с utf-8, в отличие от 4.x. И особых глюков там не замечено.

Все замечательно, но только пользовать его нельзя, ибо
каждая следующая версия не совместима с предыдущей. Наблюдал пару раз -
люди, соблазнившись мощью и простотой Tcl/Tk, начинают на ем ваять нечто
серьезное, и через пару лет им приходится мучительно переползать на
что-нибудь типа питона или (ужас!) джавы.

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

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

> в ветке 8.4 проблемы с i18n решены

Проблема в том, что ветка 8.4 появилась совсем недавно -
в сентябра 2002-го года! О каких 15-ти лет можно говорить,
если реально юзать его стало возможным всего полгода назад?

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

2Die-Hard

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

А теперь давайте прислушаемся к обоснованному мнению настоящего программиста, первого лауреата премии ACM Брайана Кернигана (B. W. Kernighan, далее -- BWK), автора знаменитого языка программирования C: "Tcl/Tk придает работе магическую продуктивность, за несколько часов можно достигнуть тех же результатов, что за дни или недели при разработке на C или C++... Tk весьма эффективен для большинства приложений, многие элементы интерфейса (виджеты) реализованы настолько хорошо, что остается только удивляться, как подобная работа могла быть выполнена так качественно... Удачным кажется и то, что разделение задач между Tcl и С/С++ осуществляется достаточно легко, надо только знать, какой инструмент лучше справляется с задачей... Расширение системы дополнительным Tcl-кодом, загружаемым напрямую в Tcl-библиотеку приложения, в полном согласии с оригинальной идеей Остирхоута, повышает эффективность программы в целом, упрощает ее структуру и улучшает мобильность... Я не уверен, что Tcl мог бы выжить, как самостоятельный продукт -- у него слишком много конкурентов. Но у сочетания Tcl/Tk в Unix-мире нет конкурентов... Система исключительно надежна, очень хорошо документирована... свободно доступна... безукоризненно высокого качества".

Саныч :)

2anonymous (*) (2003-03-13 17:30:55.131)aka Саныч :
Согласен со всем, тобою процитированным. Сам был поражен продуманностью
и красотой концепций Tcl/Tk, когда впервые с ним познакомился.

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

Kak chelovek rabotayushij s TCL ezhednevno skazhu chto luchshe vsego ego ispolzovat po pryamomu naznacheniyu a imenno kak yazyk scenariev. Dlya razrabotki celyh prilozhenij on ploho podhodit v vidu svoej cherezmernoj uproshyonnosti i slaboj tipizacii.

Vsyakie domysly o prisushej TCL magicheskoj produktivnosti po sravneniyu s C++ verny tolko esli C++ ispolzovat golyj bez kakih libo dopolnitelnyh bibliotek dlya postroeniya polzovatelskogo interfejsa i raboty so strokovymi dannymi.

Vzaimodejstvie s drugimi yazykami tozhe vesh vesma ne odnoznachnaya tak kak ona privodit k mnogokratnomu hraneniyu odnih i teh zhe dannyh. Naprimer C++ hranit dannye, TCL poluchaet ih i opyat taki hranit v svoej strukture, zatem TCL posylaet eti dannye v Tk dlya otobrazheniya, Tk opyat taki hranit te zhe samye dannye. Esli polzovatel dannye menyaet to eshyo prihoditsya hranit informaciyu dlya ustanovleniya sootvetstviya mezhdu tem chto narisovano v Tk, tem chto hranitsya v TCL i tem chto nuzhno poslat C++ chtoby dannye v rezultate obnovit.

2RONA. Описанная вами ситуация с дублированим данных может быть решена если C/C++ библиотека пишется с учетом работы с TCL. Тогда исп. возможности TCL для работы с данными. Я так делал когда писал парсер на C для TCL, а DOM интерфейс уже был на TCL.

Да ну? Книг про тикл не меньше, чем про Перл. В магазинах под них отдельные полки выделяют (правда, про блядскую сраную Жабу - вообще целые отделы).

А кто знает, почему все-таки так часто меняют tcl/tk и делают
новые версии несовместимыми со старыми? Что это, недостатки
архитектуры или как?

2Korwin:

V smysle v C vse dannye v Tcl_Obj hranyatsya?
Togda zachem C ispolzovat? Obychno C ispolzuyut chtoby bolee effektivno dannye hranit i obrabatyvat.

Vot eshyo kstati. Kto znaet kak iz TCL v C peredat associativnyj massiv?

А вот меня тошнит от ихнего look and feel. Сколько можно держаться за Motif ? И что еще меня взбесило в нем пару лет назад так это неподдержка колеса мыши.

Лучший скриптовый язык -- Ruby (мощный и гибкий). А widget toolkit -- GTK

> А вот меня тошнит от ихнего look and feel

Именно. Как так - для "убогих и кривых" gtk и qt - "engine" это внешний (и след. легко заменяемый) модуль, а для "прямого и замечательного" tk - усе (ну цвета/шрифты - мелочь) намертво вбито в код? То же относится и к motif.

Саныч, скажи поточнее, из какой книги взята цитата, буду тебе сильно благодарен - хочу такую почитать :)

2anonymous (*) (2003-03-14 08:53:01.866)

http://www.cs.bell-labs.com/who/bwk/workshop.ps.gz

Experience with Tcl/Tk for Scientific and Engineering Visualization

А это откуда я взял цитату, весьма интеснасная статья

http://www.itc.ua/article.phtml?ID=1228

Саныч

>наверное, вот этот товарищ http://www.45.free.net/~vitus/ice/tcl/locale-tcl.html с потолка свои проблемы брал...

Вот сейчас все брошу, пойду и напишу аналогичную страничку по проблемам в perl. Единственное что патч для их исправления придется писать не час, как у меня заняло изготовления патча для tcl, а неделю.

И это будет страничка о проблемах в ТЕКУЩЕЙ версии perl 5.8, а не historical tcl<=8.3.3.

Заметим, что, скажем в Debian проблем с русской локализацией Tcl не было, начиная чуть ли не со slink. Я не помню, точно в slink или в potato был включен мой патч. Помню только, что посылал я патч для 8.0.5, а патч для 8.2 мейнтейнер пакета сам у меня выкачал.

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

А я слышал, что gtk не приспособлено для работы с удаленным
X-терминалом, и вообще плохо интегрировано с X-ами. Это правда?
Имеются ввиду всяческие иксовые настройки, с которыми нормально
работают tk и motif. Кстати, из этих настроек берутся в
частности "намертво вбитые в код шрифты и цвета" ;)

> А вот меня тошнит от ихнего look and feel.

К красоте, как и к уродству привыкают одинаково ;)
Ну а внешний вид можно подстроить. В дефолтном варианте голый
gtk без тем выглядит еще хуже, чем tk. Лично мне не нравятся
только чекбоксы с ромбиками. Но это не принципиально.

> в нем пару лет назад так это неподдержка колеса мыши.

Сейчас поддерживает. Можешь возвращаться ;)

> Кстати, из этих настроек берутся в частности "намертво вбитые в код шрифты и цвета" ;)

Ты читать умеешь? Если нет то чего вы.бываешься? Речь шла о том, что _кроме_ "шрифтов и цветов" ничего через правку иксовых ресурсов изменить нельзя.

Расскажи как правкой .Xчегототама заставить Tk быть похожим на thinice или aqua или не засоряй эфир.

P.S. Извиняюсь за выражения, но не люблю когда меня держат за идиота (справедливо или нет - другой вопрос).

> Речь шла о том, что _кроме_ "шрифтов и цветов"

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

извините за оффтопик, но объясните пожалуйста, что такого хорошего и удобного в это пресловутой акве???

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

> извините за оффтопик, но объясните пожалуйста, что такого хорошего и удобного в это пресловутой акве???

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

>Бизнес-приложения имеют вполне устоявшийся стандарт на внешний вид. Это должны быть
серенькие, некричащие цвета.

Нет такого стандарта. А "кричащие" цвета будут у Tcl/Tk, когда их запустят из-под Gnome/KDE/Mac.

>Если оценивать меру успешности языка по количеству изданных книг, то очень странная катрина получается. Книжек про perl разной степени качества и понятности--море. Про python--в последнее время тоже хватает.

Действительно, странная... По Qt на русском вообще ни одной, и что из этого?

> Ну извини, не понял тебя. Если бы ты сразу вот так, как сейчас написал, то вопросов бы не было.

Ну да - смутновато написал.

> Что касается тем и оформлений, то меня это волнует меньше всего.

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

> Бизнес-приложения имеют вполне устоявшийся стандарт на внешний вид. Это должны быть серенькие, некричащие цвета. Люди работают с такими приложениями весь рабочий день, и глаза ломать они не хотят.

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

> Так что в этом плане у tk никаких проблем нет.

Ну мне кажется то, что в к tk нельзя (или трудно - раз до сих пор никто не сделал) добавить поддержку "настоящих" тем и свидетельствует о серьезных проблемах в архитектуре tk.

>Ну мне кажется то, что в к tk нельзя (или трудно - раз до сих пор никто не сделал) добавить поддержку "настоящих" тем и свидетельствует о серьезных проблемах в архитектуре tk.

Остирхоут (автор Tcl/Tk) - лауреат премии ACM,

именно за реализацию архитектуры Tkl/Tk.

А "свистков и перделок" типа "настоящих" тем никто никогда

делать в Tk или Motif не будет, наверное по той же самой причине

по которой в *BSD Unix нет аналогов графических конфигурялок линух.

Саныч

Да уж - критерий...

>>>мне кажется то, что в к tk нельзя (или трудно - раз до сих пор никто не сделал) добавить поддержку "настоящих" тем и свидетельствует о серьезных проблемах в архитектуре tk.

Очередная tick-feature нафиг никому не нужная. Один раз в жизни менял тему в GTK (попробовать). Не сказал бы что usability от этого сильно повысилась.

anonymous (*) (2003-03-14 01:42:45.088):

> ... почему ... делают новые версии несовместимыми со старыми? Что это, недостатки архитектуры или как?

IMHO "...или как" - архитектура там вполне на уровне.

Просто tcl/tk в определенный момент стал самым модным GUI-скриптовым языком (вполне заслуженно!), и разработчики для обеспечения перманентной модности переняли тактику M$ - сделали акцент на привлечении НОВЫХ пользователей в ущерб всему остальному, в том числе, обратной совместимости.

Кстати, на примере M$ видим, что тактика вполне оправдана (с точки зреня коммерческого успеха). Положив во главу угла Win95 обратную совместимость с ДОС, M$ "подсадила" лохов "на иглу", и теперь стрижет с них бабки, плодя несовместимости своих продуктов различных версий и заодно привлекая новых лохов новыми бантиками.

Разработчики tcl/tk, конечно, сместили акценты - основной упор сделан на новые бантики, а несовместимость уже - производная. Но побудительный мотив один и тот же - стремление максимально расширять клиентуру в ущерб всему остальному.

Кстати, взгляните на Qt - похожая ситуация! Раньше (до 2.0) Тролли себе такого не позволяли, а, получив признание, пошли клепать несовместимые версии...

> Остирхоут (автор Tcl/Tk) - лауреат премии ACM,

Нет бога кроме Остирхоута и Саныч пророк его

> именно за реализацию архитектуры Tkl/Tk.

Так за реализацию или за архитектуру?

> А "свистков и перделок" типа "настоящих" тем никто никогда делать в Tk или Motif не будет, наверное по той же самой причине по которой в *BSD Unix нет аналогов графических конфигурялок линух.

Да, да! Модульность - отстой. Монолит - эта крута. Точно пророк.

> Очередная tick-feature нафиг никому не нужная. Один раз в жизни менял тему в GTK (попробовать). Не сказал бы что usability от этого сильно повысилась.

Один раз попробовал и не понравилось - серьезный аргумент. Гибкость в настройках - недостаток, так что ли? Кстати, что менял - тему или engine? С какого на какой? Что конкретно не понравилось?

> Дело не в конкретной "акве" ... а в том, чтобы инструментарий мог обеспечить приложению внешний вид, стандартный для платформы, на которой выполняется это приложение. Gtk и Qt это могут, а вот Tcl...

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

btw, дефолтная тема и дефолтный движок gtk (по крайней мере до 2.0) тоже имели мотиф лук-н-фил.

сейчас это уже больше винду напоминает.

btw, по поводу отсутсвия тем для Motif

http://motifzone.net/themes/
http://www.5dwm.org/

"Гибкость в настройках - недостаток, так что ли?" Истинно говоришь! Чем больше в программе возможностей настроек, тем хуже для пользователя. Можешь спорить хоть до хрипоты, но это так. Советую почитать что-нибудь по проектированию интерфейсов и эргономики пользования (к примеру недавно вышедшую книгу - Джеф Раскин. Интерфейс. Новые направления в проектировании компьютетрных систем).

А вообще-то я в сети видел проект позволяющий к TK цеплять KDE темы. Да и сама архитектура TK это позволяет делать.

> btw, по поводу отсутсвия тем для Motif

> http://motifzone.net/themes/

> http://www.5dwm.org/

Извини, не катит. Цвета разные, а виджеты выглядят одинаково. Сравни со скриншотами GTK с engine'ами motif, thinice, xeno- и aqua.

> сейчас это уже больше винду напоминает.

Чем?

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

Я сам как бы и пользователь тоже. Можно мне за себя решать?

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

Спасибо, почитаю если найду. Но не думаю, что от прочтения книги изменятся мои _личные_ вкусы.

> А вообще-то я в сети видел проект позволяющий к TK цеплять KDE темы. Да и сама архитектура TK это позволяет делать.

Да? Интересно. Именно _KDE_ темы?

> Цвета разные, а виджеты выглядят одинаково. Сравни со скриншотами GTK с engine'ами motif, thinice, xeno- и aqua.

не вижу принципиальной разницы.

> > сейчас это уже больше винду напоминает.

> Чем?

look&feel-ом (я про gtk2)