just wondering

извините, но зачем пользоваться Tk, если есть более удобные инструменты?

Tk сложная?! Ты сделал мой день. Tk простая и надежная как автомат Калашникова. Надо иметь мотивацию, чтобы в нем

Вообще вопрос походит на: «Хочу чтобы курятина стала свининой». Хочешь работать с Tk? Работай с Tk. Знаешь как работать с Qt? Тогда работай с Qt. Не надо пытаться «навязывать свои правила в чужом монастыре». Tk - фреймворк со своими традициями, историей и не нужно из него делать Qt.

Что ты мутишь там вообще? То ruby в другой язык превратить хочешь, то tk тебе слишком сложная.

ковыряюсь в ruby=) Может я не так выразился, tk не сколько сложная, сколько не совсем привычная, по сравнению с тем что я использовал ранее. Да и документации по ней сравнительно меньше чем в Qt, приходится исходные библиотеки разбирать, чтобы понять как что сделать.

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

у tk есть плюсы - хорошая переносимость, изкоробочность и удобная лицензия.

я не собираюсь делать qt из tk. я просто искал более юзерфрендли методы для работы с ней.

Более юзерфренли как раз таки нет. Tk проще, чем Qt. Он использует более примитивные методы работы с фреймворком, которые может понять даже тот, кто первый раз в жизни видит Tk. И это его большой плюс. Городить интерфейсы и обертки к нему - смысла особого не вижу. И надо учитывать, что Tk уходит корнями в tcl, ввиду чего и имеет «такие» принципы работы. Тикль - язык меттапрограммирования, который в большей степени является процедурным. Отсюда и все «неудобства» Tk.

Ты просто не понял Tk, он как раз и есть идеальный тулкит (ИМХО). Ничего, на мой скромный взгляд, более гибкого просто не существует. У Tk главная проблема - по сравнению с Qt мало виджетов. Qt это уже даже не графический тулкит, а целый фреймворк, который дает возможность в том числе доступа к базе данных и встраиванию JS в виджеты. Насколько это правильно - судить каждому (на вкус и цвет все фломастеры разные), но ИМХО - это не слишком хорошо.

Для работы с БД должен быть отдельная библиотека, для работы с интерфейсами - другая, для обработки скриптов - третья. Это дает возможность выбора и делает «легче» сам фреймворк (меньше лишних сущностей).

BWidget, BLT, iTcl и.т.п , должны быть в стандартной поставки ruby.

На tcl-tk.ru можно почитать о tk на русском.

Ты просто не понял Tk, он как раз и есть идеальный тулкит (ИМХО)

грустно и смешно, даже что-нибудь в таком духе: http://www.haskell.org/haskellwiki/Phooey и то приятнее (по подходу, про wx под капотом молчу)

Вот спасибо! За то что реально ответил по теме, без демагогии.

Может я избалован новомодными библиотеками, но Tk::Tile::TreeView есть метод создания колонок configure(:column => [«id1», «id2»..«idn»]). Как адекватным методом добавить еще одну колонку и почему в результате получается на одну колонку больше (#0 всегда там есть), для меня остается секретом...

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

Потому что #0 зарезервирован для корня дерева. Что бы его не показывать нужно (в оригинальной Tk-шной записи)

configure -show headings

Как адекватным методом добавить еще одну колонку

Просто передать в columns список из n старых и еще одной (или больше) новой колонок.

Как адекватным методом добавить еще одну колонку

.tree configure -columns "[.tree cget -columns] newcol"

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

Да, в Tk сплошь и рядом такие штуки - берешь какое-то свойство через cget и подставляешь в configure с нужными добавками. В Tcl это очень естественно и просто, благодаря строковым подстановкам. Вообще, Tk сильно заточен под Tcl и в других языках смотрится несколько чужеродно и необычно.

Для работы с БД должен быть отдельная библиотека, для работы с интерфейсами - другая, для обработки скриптов - третья. Это дает возможность выбора и делает «легче» сам фреймворк (меньше лишних сущностей).

Вообще-то в Qt всё так и сделано.

Читай маны по tcl/tk как и говорили. Ну и попробуй сам по себе tcl. Может быть понравится больше Рубина (есть в tcl прекрасная библиотека для Ъ-ООП - XOTcl). А так - в доках по TkRuby есть только то, что относится к биндингу, а не тонкостям виджетов. Последнее оф.доках.

Педевикия

Библиотека разделена на несколько модулей, для четвёртой версии библиотеки это:

• QtCore — классы ядра библиотеки, используемые другими модулями;
• QtGui — компоненты графического интерфейса;
• QtNetwork — набор классов для сетевого программирования. Поддержка различных высокоуровневых протоколов может меняться от версии к версии. В версии 4.2.x присутствуют классы для работы с протоколами FTP и HTTP. Для работы с протоколами TCP/IP предназначены такие классы, как QTcpServer, QTcpSocket для TCP и QUdpSocket для UDP;
• QtOpenGL — набор классов для работы с OpenGL;
• QtSql — набор классов для работы с базами данных с использованием языка структурированных запросов SQL. Основные классы данного модуля в версии 4.2.х: QSqlDatabase — класс для предоставления соединения с базой, для работы с какой-нибудь конкретной базой данных требует объект, унаследованный от класса QSqlDriver — абстрактного класса, который реализуется для конкретной базы данных и может требовать для компиляции SDK базы данных. Например, для сборки драйвера под базу данных Firebird/InterBase требует .h файлы и библиотеки статической линковки, входящие в комплект поставки данной БД;
• QtScript — классы для работы с Qt Scripts;
• QtSvg — классы для отображения и работы с данными Scalable Vector Graphics (SVG);
• QtXml — модуль для работы с XML, поддерживается SAX и DOM модели работы;
• QtDesigner — классы создания расширений QtDesigner’а для своих собственных виджетов;
• QtUiTools — классы для обработки в приложении форм Qt Designer;
• QtAssistant — справочная система; Qt3Support — модуль с классами, необходимыми для совместимости с библиотекой Qt версии 3.х.х;
• QtTest — модуль для работы с UNIT тестами;
• QtWebKit — модуль WebKit, интегрированный в Qt и доступный через её классы;
• QtXmlPatterns — модуль для поддержки XQuery 1.0 и XPath 2.0;
• Phonon — модуль для поддержки воспроизведения и записи видео и аудио, как локально, так и с устройств и по сети;
• QtCLucene — модуль для поддержки полнотекстового поиска, применяется в новой версии Assistant в Qt 4.4;
• ActiveQt — модуль для работы с ActiveX и COM технологиями для Qt-разработчиков под Windows.
• QtDeclarative — модуль, предоставляющий декларативный фреймворк для создания динамичных, настраиваемых пользовательских интерфейсов.

Да неужели. Qt - монструозно большой фреймворк. И замена QtScript, скажем тем же интерпретатором tcl будет смотреться очень инородно в приложении.

В догонку ссылка TkDocs с примерами как это сделать на с Tk в разрезе четырех языков - Ruby, Python'a, Perl'a и самого Tcl'я.

У меня было предположение, что это так и должно быть, как в java через get/set, но ни одного примера не нашел, вот уже сделал, что за объектом Массив колонок таскается.

но вот tk выбивается из концепции.

Помню, когда я выбирал GUI, то перепробовал: Qt, Gtk, Tk, FOX, Wx. Для меня было важно, чтобы гуй был кроссплатформенным. Поэтому я пробовал как в линукс, так и в виндовз.

Qt не устроил лицензией. Он свободен только для частного использования.
Виджеты Tk мне показались убогими, как внешне, так и по функционалу.
Wx почему-то глючил под виндой. К тому же я вычитал, что в линуксе он работает через Gtk.

С точки зрения эстетики и соответствия идеалогии ruby мне больше всего понравился FOX (и даже виджеты под виндой неплохо выглядели). Но я исппугался его малой популярности.

В итоге остановился на Gtk. Лицензионная чистота. На винде гладко работает, вменяемо выглядит, легко ставится, занимает мало места. На линуксе вобще всегда стоит «из коробки» (обвязку поставил - и вперед). Хорошо документирована. Код в ruby тоже приятно выглядит.

А почему ты на Tk запал?

гуйню можно и как сайт сделать

Qt не устроил лицензией. Он свободен только для частного использования.

Вы смотрели на него еще в те древние время когда он был не-gpl-ной хренью, а молодой KDE был толи первой, толи второй версии ? :) Поверьте с тех времен он успел стать не только свободным по версии FSF, но и упасть до уровня GTK в LGPL.

Виджеты Tk мне показались убогими, как внешне

Это которые были в 8.4 или Tile из 8.5 c темой Alt например?

1. Тебе предоставляется огромный выбор модулей, но никто не заставляет использовать их всех. Никто не заставляет юзать QtScript только потому, что ты используешь Qt.

2. Какая разница, какой общий объем всех модулей? Ты можешь таскать со своей программой только нужные тебе.

3. Каждый модуль ты можешь использовать отдельно. А можешь не использовать. Никто не мешает в программе заюзать только QtCore и QtSql, но взять сетевую часть от boost, и совершенно левый скриптовый движок.

Хватит таскать Web-приложения на десктоп!

я руководствовался тем же! за последние 7 лет я выпал из мира Windows, встречаюсь с ним только на работе, а там некогда GUI проверять) все доводы у меня были такие же, но GTK в каких-то не очень достоверных источниках я прочитал что он глючит под виндой. Вот и выбрал меньшее из зол.

HTML5 тебя не слышит =)

:-(

Хватит таскать Web-приложения на десктоп!

Но почему? Это ведь чертовски удобно!

Наиболее приятный способ написать GUI на Ruby — это, наверное, взять sinatra+sprockets(или node-webkit+какой-нибудь-костыль-для-require), bower, angular, lodash, twitter bootstrap(или foundation)...и написать его на Coffeescript.

А если без шуток, то, судя по активности в Ruby GUI Community, самое живое сейчас — Visual Ruby.

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

я конечно имел ввиду межплатформенность.

Вы смотрели на него еще в те древние время

Выбирал в 2008 году. Возможно, уже тогда инфа про лицензию устарела. Но осадочек остался ))
К тому же Qt постоянно под какой-нибудь корпорацией лежала. Меня это настораживает. Вот Gtk сразу сообщество развивало. Не доверяю я корпорациям, пусть хоть как они доброе лицо делают. Продукт от корпорации - это обычно продукт на стероидах. Корпораха уходит - и начинается ломка. И не факт что продукт нормально её переживёт.

8.4 или Tile из 8.5 c темой Alt например?

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

Да не за что. Должно работать везде, где можно поставить Ruby и Glade — http://visualruby.net/site/Download.html

Решил перейти на GTK, но у меня такой вопрос возник, поможешь решить?

Создаю надпись

element = Gtk::Label.new("")
form.add(element)

как теперь имея ссылку на element, задать ему размер и координаты позиции? То есть хотелось бы, чтобы до того как я менял его координаты, элемент размещался по умолчанию на форму, а после изменения, только по правилам ширина/высота/координатаХ/координатаУ

Много эмоций, мало конкретики. Но ваше мнение я понял.

какая там была в 2008м году...

8.4 скорре всего. В 8.5 улучшили внешний види добавили новых виджитов.

как теперь имея ссылку на element, задать ему размер и координаты позиции?

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

Контейнеры могут быть одновиджетные, вертикальные (VBox), горизонтальные (HBox) и другие. Рекомендую ограничиваться VBox и HBox. Контейнеры могут (и должны) вкладываться один в другой. Хитрость программирования Gtk заключается в трёх вещах:
1) создать необходимую комбинацию контейнеров
2) определить свойства ячеек контейнера
3) при необходимости жёстко задать размер виджета

Ячейка может быть «резиновой», или с жесткой шириной/высотой. У ячейки может быть свой бордюр (пустое поле). Свойства ячейки задаются в момент добавления виджета в контейнер:

window = Gtk::Window.new('Cool programm')
hbox = Gtk::HBox.new
label = Gtk::Label.new('Фамилия')
entry = Gtk::Entry.new
entry.text = 'Иванов'
hbox.pack_start(label, false, false, 2)
hbox.pack_start(entry, false, false, 2)
window.add(hbox)
window.set_default_size(640, 420)
window.show_all

У виджетов в плане размеров обычно можно менять только рекомендательную ширину и высоту методом:

entry.set_size_request(300,50)

Я всегда ищу инфу по функциям таким запросом в гугле например:
«ruby gtk entry»

Много эмоций, мало конкретики.

Да, зачастую, попробовав своими руками и то и другое, я принимаю решение интуитивно. И потом с трудом могу его объяснить )

я что-то прочитал и про размещение gtkwidget *gtk_table_new, но никаких объектов в руби там не нашел, ни в библиотеках, ни через .methods. Предположил что если задать сетку с количество колонок и рядов = количеству пикселей, то можно примерно прийти к координатам, но это попробую разобрать в будущем. Я просто иногда занимаюсь переносом какого-то кода на Ruby, а формы иногда проще автоматом перебрасывать. Если элементы на форме в другом коде была расположены по координатам, то переносить их в HBox и VBox весьма затруднительно.

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

Ой, не рекомендую Table, хотя описание там же:
http://ruby-gnome2.sourceforge.jp/?Gtk::Table

Глючная довольно-таки штука, мне не понравилась.

Что касается координат, то в Gtk вобще не принято задавать позиции в координатах. Т.е. просто распихиваешь по контейнерам, задаешь размеры виджетов и их выравнивание.