Tkabber Wiki

Особенности реализации
Login
☰Home Timeline Branches Tags Tickets Wiki Login

Материал из Tkabber Wiki

Содержание

Преамбула

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

Tcl/Tk

Ткаббер написан на языке Tcl и использует библиотеку Tk для создания графического интерфейса пользователя (GUI).

Несмотря на наличие некоторых (практически беспрецедентно) мощных виджетов (таких как text (используются в окнах чата) и canvas (на нём сделаны ростеры)), в Tk нет таких "примитивов" как: "progressbar", "notebook" (виндовым программистам более известный как "page control" или "tab control"), "сплиттеров", готовой поддержки стандартных диалоговоых окон. Однако для Tk написана масса сторонних реализаций, компенсирующих этот недостаток; Ткаббер широко использует один из подобных "наборов виджетов" — BWidget.

(!) Сделать: добавить про Tcllib

Почему Tcl?

Вообще говоря, здесь проще всего ответить вопросом на вопрос: "а почему нет?" — Tcl является продвинутым "скриптовым" языком; тот факт, что вокруг него значительно меньше того шума, который именуется термином "hype", и он никогда не был "в моде" у населения /., не говорит о том, что на нём нельзя создать серьёзный проект. Более того, некоторые бывают удивлены, узнав, что Ткаббер даже не является единственным Jabber-клиентом и уж тем более не единственным Instant Messenger'ом, написанном на Tcl/Tk.

(!) Сделать: развить

Почему Tk?

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

Почему Tk, а не GTK/Qt/что-то ещё?

Ответы можно условно разбить на две категории:

А почему нет?

99% претензий к Tk касается вовсе не его технических характеристик, а того, как он выглядит (и вообще ощущается) на конкретной системе конкретного пользователя — не секрет, что на 97% "десктопов" в современном мире установлена одна из ОС, сошедших со стапелей Microsoft, а на жалких остатках, занятых, в основном, решениями на базе Linux и *BSD, царят GNOME и KDE, то есть имеет место "обоснованное засилье" приложений, использующих в виде GUI-тулкитов GTK и Qt, соответственно.

Сейчас уже поздно стенать о том, что авторы GTK и Qt не дочитали спецификации на X Window System, а также о том, что они изобрели (каждый — свою) системы конфигурации тулкитов, несовместимые с когда-то бывшей хоть каким-то стандартом систему конфигурации Xt и Motif (XRDB). В результате мы имеем то, что имеем: несовместимые между собой тулкиты, некоторые из которых борются за "мировое господство".

Отсюда и наш слабый аргумент: а почему, собственно, GTK или Qt? Потому, что он доминирует на вашей системе? Но в любом случае всем угодить не получится: GTK-приложение будет чужим в окружении Qt и наоборот. А приложение GTK или Qt никогда не будет выглядеть совершенно нативно в Windows, пусть даже оно будет ближе к "натуральному виду", чем Tk.

Наконец, Ткаббер был рождён как "иксовое" приложение, а довольно весомая часть пользователей X Window вообще не использует "desktop environments", такие как GNOME и KDE — они используют "каноническую" концепцию: window manager + набор приложений, окнами которых он позволяет управлять. Приложения при этом могут быть какими угодно, наглядно демонстрируя "разброд и шатание" иксовых тулкитов во всей его неприглядности. Tk в этом случае выглядит не хуже и не лучше других.

Следует также понимать, что у других тулкитов хватает своих "тараканов в голове", и переезд на другой тулкит запросто может создать проблем больше, чем решить.

Техническая сторона дела

У Tk есть несколько интересных особенностей, которые выделяют его в ряду GUI-тулкитов:

Это позволяет создавать дистрибутивы "всё-в-одном" из приложений, написанных на Tcl/Tk — старкиты и старпаки.

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

(!) Сделать: развить

Почему не отделить интерфейс от реализации?

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

Самая главная проблема состоит в том, что разные GUI-тулкиты имеют разную философию программирования. Это приводит к тому, что для поддержки разных тулкитов нужно: а) писать "ядро" в очень общем виде, разрабатывая некие абстрактные интерфейсы для взаимодействия ядра с тулкитом; б) писать ещё по одному слою кода для каждого тулкита — для привязки этого тулкита к ядру. В результате код Ткаббера увеличится хорошо если вдвое, а его читабельность уменьшится, видимо, даже более чем вдвое. Неплохую идею о том, к каким проблемам приводит подобный подход, можно почерпнуть, глядя на GiTK.

Ещё одна проблема, незаметная при поверхностном осмотре, состоит в том, что создание "чистого" кода практически невзоможно — любая платформа имеет собственные заморочки, что требует "твиков" кода, создания "костылей" и прочих уродств в определённых случаях. К сожалению, в Ткаббере вынужденно хватает подобных мест. В случае с "многоинтерфейсным" подходом мы автоматически множим и подобные проблемы.

Наконец, подумайте о координации разработки (а одна команда не станет окучивать все направления — для этого требуются конкретные группы), а также о поддержке пользователей: даже сейчас, когда Ткаббер широко используется только на двух платформах (в Windows и Unix-based системах; в Mac OS X ситуация далека от радужной в силу отсутствия в команде Ткаббера разработчиков, заинтересованнных в улучшении ситуации), зачастую можно говорить о двух разных Ткабберах, так как эти платформы имеют слишком много собственных особенностей. Представьте теперь, что будет, если умножить число платформ на число поддерживаемых тулкитов?

Наконец, возможно, ключевой момент: разработчиков вполне устраивает Tcl/Tk, а идеи "портировать Ткаббер под <место для тулкита>" проистекают в основном от тех, кто свой труд вкладывать в это не хочет.

Почему нет "внешнего API"?

"Внешнего API" (такого, как, например, API плагинов у Миранды) в Ткаббере нет потому, что он написан на Tcl, а не на Си; соответственно, предполагается, что "скриптование" Ткаббера производится кодом на Tcl.

Обвинение в отсутствии C API обычно приводят как причину "невозможности скриптовать Ткаббер на языках, отличных от Tcl" (более конкретно — "на любимом языке"). Теоретически это обвинение обоснованно. Однако давайте посмотрим на проблему с практической точки зрения (игнорируя тот факт, что создание C API для Tcl кода относится к области ненаучной фантастики):

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

Ткаббер выглядит отвратительно!

<zayza> почему говорят, что ткабер страшный? о_0
<teo> zayza: потому что видели его

Ткаббер (а точнее — Tk) находится в ловушке всех без исключения кроссплатформенных GUI-тулкитов — невозможно выглядеть "нативно", работая на ненативной платформе. К сожалению, как было сказано выше, это относится не только к проблеме "Tk в Windows", но и к "Tk в GNOME/KDE".

К сожалению, выглядеть "в струе" самых последних веяний моды Windows и прочих "desktop environments" Tk, скорее всего, не будет никогда — тяжело прочно сидеть на нескольких стульях разной высоты, формы и конструкции сразу.

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

Заодно расскажем ещё об одной часто всплывающей теме:

Tile в Ткаббере

Tile — это надстройка над Tk, призванная решить некоторые проблемы с "луком и филом", присущие Tk:

Проблема с Tile состоит в том, что она не является "drop-in replacement" для Tk. Это важно понимать: простое подключение Tile к существующему проекту, использующему Tk, не привьёт ему "волшебным образом" все преимущества Tile. В частности, если стандартные виджеты Tk ещё могут (с некоторыми приседаниями при сборке Tile) "переехать" на новый движок, то все "левые" виджеты (например, виджеты из BWidget) "сушат вёсла" — выглядят и работают по-старому.

Другими словами, Ткаббер нужно портировать под Tile, чтобы он с этой Tile нормально заработал.

Тут возникает другая проблема. Она состоит в том, что Ткаббер позиционируется разработчиками как максимально портабельное приложение. Это означает, в числе прочего, что:

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

На сегодняшний день состояние дел таково, что если мы бросим все дела и "привяжем" Ткаббер к Tile, то это ударит как по разработчикам (им понадобится оперативно следить за изменениями в Tile), так и по пользователям (Tile, насколько нам известно, нет ни в одном серьёзном дистрибутиве Linux) — Ткаббер потеряет одно из своих главных качеств — способность работать без чрезмерно серьёзных телодвижений со стороны пользователя на любой системе, в которой есть Tcl/Tk.

Ещё одна (менее серьёзная) проблема состоит в том, что Ткаббер действительно сильно зависит от BWidget — с его помощью делаются: почти все диалоги, главное меню, интерфейс с табами (правда, в альфе 0.10.1 уже реализован другой подход), деревья, выпадающие списки так далее. Так как BWidget не поддерживает Tile и, судя по-всему, не будет её поддерживать, портирование Ткаббера под Tile — это очень серьёзный шаг: прежде чем его сделать, разработчики должны быть уверены, что Tile получила такую же доступность, как BWidget.

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

This page was generated in about 0.012s by Fossil 2.22 [66ee0beb9b] 2023-05-31 15:26:08