а где письмо 2?

[Tcl/Tk] Показательный пример использования Tk для создания GUI

Письмо 2

Благодарю за ответ! Некоторые моменты остались неясны:

Tk умирающая платформа. Попытка вдохнуть в нее жизнь в версии 8.5 провалилась. Темезация так и осталась недоделанной. У sK1 тема на битмапах, т.е. все вручную отрисовано, поскольку интеграция с Gtk|Qt у обычного Tk невозможна из-за особенностей движка темезации. Чтобы это стало возможным, нужно вкомпилировать тему при компиляции пакетов Tk, т.е. это походит только для экспериментов но не для широкого круга пользователей. Да и код у нативных тем (автор Georgios Petasis) скажем мягко, не очень. Также абсолютно отсутствует интеграция с десктопным окружением.



sK1 изначально основан на коде Skencil, в котором Tk прибит гвоздями в MVC паттерне. Год назад окончательно достали Tk-шные проблемы и было принято решение о полной «перезагрузке» проекта. Последней каплей был «отвал» всех не latin-1 локалей в Tk под Ubuntu из-за того, что в Ubuntu локаль «UTF8» заменили на «utf8». Skencil мы переписываем на Gtk, а sK1 на Qt. На самом деле это полное переписывание - проект дошел «до руки», когда тащить старые костыли уже просто невозможно.

Основные проблемы получается:
1) темезация так и осталась недоделанной, а именно интеграция с Gtk|Qt у обычного Tk невозможна из-за особенностей движка темезации
2) отсутствует интеграция с десктопным окружением
3) некачественный код у нативных тем
4) окончательно достали Tk-шные проблемы

Пункты №1 и №2 не понятно как связаны с Tk. Разве это не общая проблема большинства GUI библиотек? Если берется любая графическая библиотека (за исключением таких хамелеонов как WxWidgets), то она конечно не будет интегрироваться в десктоп окружение написанное на другой библиотеке. Я так понимаю, что над такими задачами если и работают, то далеко не в первую очередь. Переписанные Skencil на Gtk и sK1 на Qt не будут нормально интегрироваться в десктоп окружение Windows и Mac OS X, они так же как и Tk смогут в лучшем случае использовать похожие по внешнему виду темы. Или оба редактора на Mac OS X будут выглядеть как родное приложение написанное на Cocoa? Я сейчас для проверки запустил gimp, так у него близко нет интеграции с десктопом мака. У openoffice и firefox судя по виду отчасти есть. Emacs имеет сборки на Cocoa, а без этого тоже не интегрируется. Может я не понял какая именно отсутствует интеграция с десктопным окружением у Tk, но имеется у Gtk и Qt? Неужели Вы хотите столько переписать только ради Gnome и KDE?

Со скоростью Tk проблем не было? Помню на форуме жаловались на торможение sK1 и насколько понял Tk был не причем, верно?

Правильно понимаю, что №4 это первые 3 вместе или это общее качество кода Tk из разряда: «„отвал“ всех не latin-1 локалей в Tk под Ubuntu»?

Ответ на письмо 2

Основные проблемы получается:

1) темезация так и осталась недоделанной, а именно интеграция с Gtk|Qt у обычного Tk невозможна из-за особенностей движка темезации

2) отсутствует интеграция с десктопным окружением

3) некачественный код у нативных тем

4) окончательно достали Tk-шные проблемы



Пункты №1 и №2 не понятно как связаны с Tk. Разве это не общая проблема большинства GUI библиотек?

Пункт №1 связан с особенностью библиотеки Tk: использование Gtk|Qt темы требует нативного экстеншина, но такой экстеншин успешно компилируется, но не может быть загружен в рантайме из-за бага в tk8.5|8.6 Возможно когда-то это исправят, но на данный момент это пофикшено только в ActiveTcl.

Пункт второй - это прежде всего системные диалоги. В юниксовом варианте они собственные tk-шные и выглядят жутко. Темезации они не подлежат (они написаны на тикле с использованием старых виджетов) и поэтому в sK1 используются свои диалоги. Такая же фигня с курсорами в Linux - пришлось делать специальный нативный экстеншин tkXcursor. C drag-n-drop'ом не решали проблемы, но DnD в принципе отсутствует в Tk. Вообще, для решения всех этих tk-шных косяков мы тащим отдельный пакет с «костылями» - sk1sdk. Да, все в проблемы решаемы, но когда половина времени уходит на перекладывание костылей - это откровенно достает.

Если берется любая графическая библиотека (за исключением таких хамелеонов как WxWidgets), то она конечно не будет интегрироваться в десктоп окружение написанное на другой библиотеке. Я так понимаю, что над такими задачами если и работают, то далеко не в первую очередь. Переписанные Skencil на Gtk и sK1 на Qt не будут нормально интегрироваться в десктоп окружение Windows и Mac OS X, они так же как и Tk смогут в лучшем случае использовать похожие по внешнему виду темы. Или оба редактора на Mac OS X будут выглядеть как родное приложение написанное на Cocoa? Я сейчас для проверки запустил gimp, так у него близко нет интеграции с десктопом мака. У openoffice и firefox судя по виду отчасти есть. Emacs имеет сборки на Cocoa, а без этого тоже не интегрируется. Может я не понял какая именно отсутствует интеграция с десктопным окружением у Tk, но имеется у Gtk и Qt? Неужели Вы хотите столько переписать только ради Gnome и KDE?

Как ни странно, переписывание GUI это самое простое :) На каждый из тулкитов ушло всего по одному месяцу. Гораздо больше времени уходит на специфические штуки, связанные с рендерингом в редакторе: то, что изначально закладывалось в движок, совершенно не соответствует нынешним задачам и переписывание модели и импортеров/экспортеров графических ворматов занимает массу времени.

Со скоростью Tk проблем не было? Помню на форуме жаловались на торможение sK1 и насколько понял Tk был не причем, верно?

Ну естественно тормозит Tk :) Ведь привязка к Tk сильно отличается от биндинга к gkt|qt По сути, каждое действие с виджетами это стринговая тиклевая команда, которую передает питон или лисп интерпретатору тикля. Т.е. один интерпретатор управляет другим интерпретатором. На все это наслаивается особенность тикля - он single thread и отрисовка виджетов происходит по таймауту после последнего воздействия на окно. В итоге если окно, например, ресайзится, визуально заметно, как происходит отрисовка виджетов. Композитный менеджер частично скрадывает эти проблемы, но не полностью. То же самое касается главного меню приложения.

Правильно понимаю, что №4 это первые 3 вместе или это общее качество кода Tk из разряда: «„отвал“ всех не latin-1 локалей в Tk под Ubuntu»?

Не совсем так. Здесь букет проблем: и качество кода свежих версий Tk (пример: появилась возможность установить TrueColor иконку для окна приложения. В кедах работает, в гноме нет), и качество поддержки версий. В Linux поддержка Tk идет по остаточному принципу и в каждом из дистрибутивов свои заморочки с Tk, в макоси поддерживается только старая версия 8.4, ну а в винде что запакуешь в инсталлер, то и будет.

Резюмируя, как простенький виджетсет Tk вполне жизнеспособен, но для сложных приложений он мало подходит, т.к. приходится решать массу проблем, которые должны быть уже решены в тулките (как напр. в gtk или qt).

Надеюсь данная информация будет полезна выбирающим. У меня сложилось впечатление, что если хочешь написать крупное приложение на Tk с современным внешним видом, будь готов дописать саму Tk.

спасибо

Жалко, последнего ярого апологета Tk забанили.

Ну нечего тут жалеть :) Де факто Gtk стал стандартом в Linux (прежде всего из-за количества убунтоидов), посему инфа пользительна для тех, кто выбирает тулкит для стартапов.

Де факто Gtk стал стандартом в Linux

Щас школьники как понабигут.

> Де факто Gtk стал стандартом в Linux

Ожидаем ора qtшников.

>> Де факто Gtk стал стандартом в Linux

Щас школьники как понабигут.

А фигли тут бегать? Против статистики не попрешь: Бубунта и Минт натягивают все остальные десктопные дистры не глядя.

Минт натягивает зюзю с мндривой? Орли?

вполне

я бы ещё добавил федору

Зачем нужна темезация?

>Минт натягивает зюзю с мндривой? Орли?

В совокупности Минт+Убунту вне конкуренции. А значит Гном ведущий DE.

>Зачем нужна темезация? потому что есть моменты, в которые, на пример tkabber, - использовать невозможно.

>Зачем нужна темезация?

да просто поклонники Мотифа как-то вымерли уже :)

Например?

в основном, работа с буфером обмена, на пример, копирование текста в буфер из хистори.

бывает глючная работа с деревом в Service Discovery

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

Эти проблемы вызваны отсутствием темезации?

А что, gtk1 vs gtk2 vs gtk3 стали уже нативными ?
И вообще,после появления Unity и Gnome3, разговоры о нативности пока несколько абстрактны.

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

нативными

разговоры о нативности

Как школьники связаны с нативностью?

> в основном, работа с буфером обмена, на пример, копирование текста в > буфер из хистори.

бывает глючная работа с деревом в Service Discovery

Ну и причем тут Tk ?
Или все болячки одной программы надо списать на Tk ?

Как школьники связаны с нативностью?

Почему школьники ?
Это все манечки линуксоидов, царственно вещающих про захват десктопа неким тулкитом.
В винде таких проблем у Tk нет.)

Это все манечки линуксоидов, царственно вещающих про захват десктопа неким тулкитом.

Выдыхай, анон. B где ты этого только понахватался?

Нативность это то, что на версию меньше :-) Причем не минорную

> естественно с его разрешения

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

По теме - ну правильно, зачем копаться в говне мамонта, если есть кошерный Qt.

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

Вообще-то, надо. Того, с кем переписывался.

Выдыхай, анон. B где ты этого только понахватался?

А зачем далеко ходить ?
Ну да, тут обсосали новость, что 0.7 ... 2 % присутствия линукс на десктопе.
Далее, озаренный TC привел тут переписку с унылым неудачником.
Невдаха разоткровенничалась и на радостях извергла:
Официально поддерживаемый Tk - rip, а официально рипнутый gtk2 - нет, ибо:
убунта, хомиячки и попса. Ну и он тоже хочет попасть в «обойму мейнстрима».

Привет, elipse. Сразу не узнал.

По мне, так никто Tk и не закапывал. В своей нише, быстрого кросплатформенного формоклепательства, он незаменим.

А то что авторы skencil/sk1 — cсзб, было ясно еще во времена оные.

Привет, elipse. Сразу не узнал.

)) и тебе привет

А то что авторы skencil/sk1 — cсзб, было ясно еще во времена оные.

согласен

На каком основании?

При чем здесь бубунта и минт? Будто в остальных дистрибутивах Gtk не является де-факто стандартом GUI-библиотеки... А Qt - так, как назойливая пришлепка какая-то: от нее бы избавиться полностью, да не получается (некоторые программы на Qt не имеют Gtk-аналогов).

На основании элеметарной этики.

Даю подсказку: в переписке обычно участвуют не менее двух человек.

Если же под

собственной личной перепиской

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

> Будто в остальных дистрибутивах Gtk не является де-факто стандартом GUI-библиотеки...

ты не поверишь..

А еще проблема такая-то. И еще такая то. А потом такая то.

Зачем себя мучить?

> На основании элеметарной этики.

Ясно. Т.е., кроме каких-то людских неписанных правил препятствий нет.

А какие нелюдские правила ты хотел? Чтоб тебя немедленно испепелял гнев господень?

Пользуюсь мандривой. На нетбук поставил арч. Qt на нетбуке вообще не буду ставить (т.к. они там нафиг не нужны). На компьютере кути установлены лишь из-за Qjackctl, rosegarden и кое-чего еще, зависимого от них.

молодец, чтож сказать, но будто бы из этого следует утверждение «Будто в остальных дистрибутивах Gtk не является де-факто стандартом GUI-библиотеки...».

ГК РФ или Конституція України.

Это тебе на другой форум надо.

Ну нечего тут жалеть :) Де факто Gtk стал стандартом в Linux

И правильно. Не Qt же им быть. Он вообще в опенсорсе волей случая и так же легко может поменять лицензию как стал свободным.

Таки да... Теперь когда Nokia крутит лубофф с МС и такое можно ожидать. Закроют сорс свежих версий и «всем спасибо - все свободны».

весьма давно использую tcl/tk во всяких поделках, опыт есть, к тому-же just-for-fun вожусь иногда с C-шным кодом tcl, поэтому прокомментирую пункты

1) темезация так и осталась недоделанной, а именно интеграция с Gtk|Qt у обычного Tk невозможна из-за особенностей движка темезации

2) отсутствует интеграция с десктопным окружением

3) некачественный код у нативных тем

4) окончательно достали Tk-шные проблемы

с начала критика :

по п1 - темизацией через tile не пользуюсь. Пробовал, но - Она ttk прибит гвоздями,сбоку и кривоват. Вроде как доделывают, дописывают, но неактивно. По поводу интеграции с Gtk,Qt можно спорить до бесконечности, и главный вопрос - кто такие Gtk,Qt ? Как там у них с интеграцией промеж собой. Вообще-то тулкит должен интегрироваться с X-Window, WM и DE. И в плане интеграции поведения Tk наверное может дать фору. А вот с внешним видом - увы..Но кстати что-то мне не встречались стандарты описания графических тем, так что интегрироваться по внешнему виду просто не с чем.

по п2 - (поминая заодно п1) кто-нить скажет как выглядит системный диалог X-window (или UNIX) открытия файла ? или хотя-бы как он должен выглядить? Да, Tk эмулирует старенький,страшненький OSF Motif - но так он же был последним общепризнанным стандартом. Скажите какие диалоги и как должен использовать граф.тулкит не претендующий на общесистемный?

по поводу скорости Tk - не смотрел код sk1, но если они хотели скорости при выводе сложных примитивов от canvas, то они сильно заблудились.

по п3. сложно сказать, про качество кода нативных тем..У нативных Tk тем вообще нет кода :) Только ресурсы и опционально диалоги. Про tile сказал выше.

по п4 - полностью согласен, ни в одном дистрибуитве нет нормальной поддержки tcl/tk, даже нет правильной сборки. Во многом это тормозит сам по себе tcl/tk. Кстати указанные проблемы (например про TrueColor) , они скорее не Tk-шные.

С чем согласен : Tk как тулкит наверное плохо подходит для приложений очень требовательных к графике и её скорости. Он не слишком красив, и медлителен и в принципе нужен только для построения общего (скриптуемого) интерфейса пользователя со всеми его менюхами, пиктограммами и диалогами. (для скорости вывода есть OpenGL). Текущее положение дел - если глянуть внутренности языка и тулкита, то там наглядно видны 2 вещи - изо всех сил соблюдается совместимость с предыдущими версиями и куётся многонитиевый код. Вещи плохо согласуемые :(

Вообще изначально tcl/tk созданны как клей (clue) для других программ и для быстрого создания простых скриптов и GUI. Не надо на них делать самостоятельных монстрообразных приложений. Попытки написать emacs на tcl/tk обреченны.

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

>по поводу скорости Tk - не смотрел код sk1, но если они хотели скорости при выводе сложных примитивов от canvas, то они сильно заблудились.

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

Касательно Gtk спорить бесполезно - newbe качает бубунту, запускает тиклевую прогу и тихо сползает под стол ибо выглядит оно... кароч, страшнее только FontForge :)

>Ну нечего тут жалеть :) Де факто Gtk стал стандартом в Linux (прежде всего из-за количества убунтоидов), посему инфа пользительна для тех, кто выбирает тулкит для стартапов.

а как связан линукс и стартапы? 0_о