особености на приложението Tkabber уики
Тази статия предоставя подробни отговори да се опаковат различни въпроси периодично задавани от потребителите по отношение на езика Tkabber неговото прилагане, както и свързаните с тях въпроси - по отношение на външния му вид.
Tkabber написани на Tcl език и използва Tk библиотеката, за да създадете потребител (GUI) графичен потребителски интерфейс.
Въпреки наличието на някои (почти безпрецедентни) мощни джаджи (като текст (използва се при отворени прозорци), както и на платното (върху него направена за печене на кафе)) в Tk не като "примитивни" като: "progressbar", "преносим компютър" (vindovyh програмисти повече известен като "контрол страница" или "контрол раздела"), "сплитери", готова да подкрепи стандартните прозорци dialogovoyh. Въпреки Tk написани много от трети страни приложения на компенсиране този недостатък; Tkabber широко използване на един от тези "джаджи" комплекти - BWidget.
Смятате: добавете около Tcllib
Най-общо казано, това е най-лесният начин да се отговори на въпроса с въпрос: "Защо не?" - Tcl е усъвършенстван "скриптов език"; на факта, че всички около него много по-малко от шума, който се нарича с термина "свръх". и той никога не е била "на мода" в населението / .. да не кажа, че това не може да създаде сериозен проект. Нещо повече, някои от тях са изненадани да научат, че Tkabber не са единствените Jabber-клиенти и със сигурност не е единственият Instant Messenger'om. написани на Tcl / Tk.
Tk е "естествен" избор за създаване на GUI в заявление писано в TCL, което се дължи на факта, че сухожилие Tcl / Tk е почти уникален (с изключение на много, много "езотерични" решения) в смисъл, че GUI-инструментариумът е много удобно Тя закачен с езика - както по отношение на философията, така и по отношение използва при работа с него езикови конструкции.
- Стандартната мантрата: "защо не?";
- Техническа обосновка.
И защо не?
99% от претенции към Tk отнася не и неговите технически характеристики, както и как изглежда (и като цяло се чувствах) на дадена система, определен потребител - не е тайна, че 97% от "десктоп" е една от операционните системи, инсталирани в съвременния свят, да слиза на хелинг Microsoft, но по-жалки останки, ангажирани предимно решения, базирани на Linux и BSD *, царуват GNOME и KDE. т.е. има "разумно доминиране" приложения, като използват GUI-инструментариуми GTK и Qt. съответно.
Затова нашата слаб аргумент: защо, всъщност, GTK или Qt? Тъй като това доминира във вашата система? Но в никакъв случай не е в състояние да задоволи всички: GTK-заявление ще бъде чужденци в среда Qt и обратно. А заявление GTK или Qt никога няма да изглежда доста роден на Windows, дори и да е по-близо до "естествен ума" от Tk.
И накрая, Tkabber е роден като приложение "Х", а по-скоро като значителна част от потребителите X Window не използва "десктоп среди", като GNOME и KDE - те използват "каноничен" концепция: прозорец мениджърът + пакет от приложения, прозорците на която той може да контролира , Приложения в същото време може да бъде всичко, което ясно показва "объркване и нерешителност" "X комплекти инструменти в цялата си грозота. Tk в този случай, не изглежда по-зле и по-добри от другите.
Също така е ясно, че други комплекти от инструменти липсват техните "хлебарки в главата ми." и се стигне до различен набор от инструменти могат лесно да се създаде повече проблеми, отколкото решават.
Техническата страна на нещата
В Tk има някои интересни функции, които се открояват в редица GUI-инструментариуми:
- Много малък размер;
- Масови разширения написани на "чист" Tcl;
- Tk е неразделна част от желанието на обвивката. тоест, една програма, която изпълнява скриптовете Tcl в "прозорец" среди.
Тя ви позволява да създадете дистрибуции "всичко-в-едно" от приложенията, написани на Tcl / Tk - starkity и starpaki.
С други думи, "близостта" на инструментариума на Tcl Tk, който дава главата няколко точки, да започнем отначало другия или инструментариумът, който е необходим, за да я носите:
- Специални автомати в комплекта инструменти;
- Самата Toolkit като библиотека (или набор от десет библиотеки, какъвто е случаят с GTK2 +).
Хората, които четат няколко книги за програмиране, тази идея изглежда разумно. В действителност всичко е много по-сложно.
Основният проблем се крие във факта, че различните GUI-инструментариуми имат различна програмиране философия. Това води до факта, че различни комплекти от инструменти за подкрепа на необходимостта от: а) пише "ядрото" по много общ начин, развивайки някои абстрактни интерфейси за взаимодействие с основния инструментариум; б) да напише още един слой на код за всеки набор от инструменти - Този инструмент за свързване към ядрото. В резултат на това кодът ще се увеличи Tkabber добре, ако се удвои, а нейната четливост е намален, вероятно дори повече от два пъти. Една добра идея за това какви проблеми води подобен подход може да бъде придобит, като погледнете в GiTK.
Друг проблем, незабележими при повърхностен преглед, е, че създаването на "чиста" код почти nevzomozhno - всяка платформа има свои собствени проблеми, което изисква "ощипвам" на код, създаване на "патерица" и други деформации в определени случаи. За съжаление, Tkabber принуден липса на такива места. В случай на "multihomed" подход, ние автоматично ще умножа и подобни проблеми.
И накрая, може би най-важно- са доста доволни от Tcl / Tk и идеята за "порт под Tkabber разработчиците <место для тулкита>"Стани най-вече от тези, които имат своята работа да сложите в него не иска.
"Външно API" (като, например, на API плъгин Миранда) в Tkabber там, защото е писано в TCL, а не на C; съответно, се приема, че "скриптове" се произвежда Tkabber код на Tcl.
Обвинението в отсъствието на C API обикновено води като причина за "невъзможност Tkabber сценарист езици, различни от Tcl" (по-точно - "за любимия език"). Теоретично, това обвинение е оправдано. Все пак, нека да погледнем на проблема от практическа гледна точка (игнорирайки факта, че създаването на C API за Tcl код се отнася до не-научна фантастика):
- Наличието на C API не означава автоматично предоставя на автомати API за други езици - тези, които за пръв път някой трябва да напише. И подкрепа. Следователно, твърдението, че "не мога да сценарист / Tkabber разшири на любимия си език" в повечето случаи, трябва да се превежда като "Знам само C ++ и Java, и си Гъди не искат да учат."
- Ако приемем, че съществуването на C API и автомати за други езици, ще видим възможностите и проблемите на преносимост: Да предположим, че сте писали приставка, за да Tkabber, да речем, Python. Има ли много хора са готови да предоставят в Времетраене питон да използвате плъгин? Как да се справим с разпространението на плъг-ин "опаковани" версии Tkabber? Дори ако приставката е написана директно в C, - че има проблем на различни платформи изграждане, че е пълен пакет от проблеми с поддръжката на множество компилации системи (които имат, например, в случай на монтаж на Tcl разширения, написани на C).
От друга страна, скриптове / разширение Tkabber своя "роден" език е лишен от всички тези проблеми, в допълнение към проблема за себе dopilivat.
Tkabber (или по-скоро - ТК) е в капан във всички, без изключение, междуплатформени GUI-инструментариуми - това е невъзможно да се търси "роден", работи по неместни платформа. За съжаление, както е споменато по-горе, това се отнася не само за проблема с "Tk в Windows", а да "Tk в GNOME / KDE".
За съжаление, на външния вид "в руслото" на най-новите модни тенденции, както и други прозорци "десктоп среди" Tk, най-вероятно, никога няма да бъде - трудно твърдо седи на няколко стола от различни височини, форма и дизайн веднага.
Няколко подслади хапчето може да няма достатъчно възможности за промяна на външния вид на ТК приложения, които (някога ще бъде), описани тук.
В същото време ви кажа повече за един от темата изскачащия:
Плочки в Tkabber
Плочки - е добавка на Tk, предназначена за решаване на някои проблеми, свързани с "лък и Фил" присъщ Tk:
- Прилагане на "родния" поглед в Windows XP (т.е. на двигателя, за да го използвате);
- Прилагане на няколко нови джаджи, римейк възраст.
Плочка е проблем, е, че тя не е "капка в замяна" за Tk. Важно е да се разбере: Плочка проста връзка към съществуващ проект, който използва Tk, не privot той "магически" всички плочки предимства. По-специално, ако стандартните джунджурии Tk все още може (с някои клякам на плочки монтаж) "преместени" в нов двигател, всички "ляво" запособия (например джаджи от BWidget) "сушени гребла" - изглеждат и работят по стария начин.
С други думи, трябва да пристанище под Tkabber плочки, така е и с тази плочка работи правилно.
Това повдига друг проблем. Тя се състои в това, че Tkabber позиционира от разработчиците като максимално прилагане преносимост. Това означава, наред с други неща, че:
- Tkabber (официално) работи дори и на Tcl / Tk 8.3;
- Tkabber независим (в смисъл на "не може да работи без") само на софтуерни компоненти, които са били дълго време широко достъпни в нито една от платформите, на които работи Tcl / Tk. И само един от тези компоненти (Tcl / ТК) е написан на C, и той трябва да се "събира" на целевата платформа, ако тя не е там в завършен вид; други компоненти (Tcllib и BWidget) е код на TCL - достатъчно от тях "разшири" от архивите - и те са готови да отидат.
Плочка тези компоненти не се прилагат. Достатъчно е да се каже, че в природата няма и такова нещо като "стабилна версия на плочката", което означава, че неговото API може да се променя два пъти на ден.
Към днешна дата, състояние на нещата е такова, че ако ние се хвърлят всичко и се "върже" Tkabber с теракот, а след това ще се появи както за програмисти (те трябва бързо да ги последват промени в плочки), а за потребителите (плочката, доколкото знаем, не във всеки сериозен дистрибуция Linux) - Tkabber изгуби една от основните му качества - способността да се работи без прекалено сериозни движения от страна на потребителя на всяка система, която има Tcl / Tk.
Друг (по-малко сериозен) проблем е, че Tkabber наистина силно зависи от BWidget - общо с това: почти всички на диалога, на главното меню интерфейс с табове (въпреки че в алфа 0.10.1 вече се прилага различен подход), дървета, падащия списъци така нататък. От BWidget не поддържа плочки и, съдейки по всичко, няма да го подкрепят, пренасяне Tkabber под плочки - това е една много важна стъпка: преди да го направи, разработчиците трябва да бъдат сигурни, че плочката получи същия достъп както BWidget.