[Непонятно же] Tk

а че тут думать ? pyGTK спасет тебя, других вариантов нет.

Спроси у gaa - он автор tkLor. А вообще, just use QT4.

> тем, что тупо проще прикрутить?

А qt без плясок с бубном не прикрутить, что-ли?

> а че тут думать ? pyGTK спасет тебя, других вариантов нет.

Я сам склоняюсь к выбору GTK (правда, в моём случае - ruby-gtk2).

Но всё-же я не понимаю такую любовь разработчиков ЯП к библиотеке Tk

> Спроси у gaa - он автор tkLor.

Буду надеяться его появлению в этом треде.

> А вообще, just use QT4.

Я ещё не решил, но Qt4 обязательно посмотрю.

> Но всё-же я не понимаю такую любовь разработчиков ЯП к библиотеке Tk

хз, у меня уходит минут 5-10 на разработку GUI на pyGTK, я доволен :)

> А qt без плясок с бубном не прикрутить, что-ли?

В том-то и вопрос: почему разработчики ЯП поставляю Tk "out-of-box"?

Возможно, дело в универсальности. Tk есть буквально везде и крайне просто в портировании.

> Страшный внешний вид,

Это миф. Есть tile, есть tk8.5 с нормальной отрисовкой шрифтов, есть xresources наконец.

> феерические тормоза (по сравнению с gtk или Qt).

Это субъективно.

> Чем она так притягивает, тем, что тупо проще прикрутить?

Она удобна. В особенности вкупе с тиклем.

* How about Graphical Development Tools?
* We should use a cross platform GUI... Tk is it.
* Robyn: I'm concerned about the footprint of Tk
* Roger: I don't think the memory problems in Tk are a perminant problem. Both Tk and Tkinter have leaks but these should be fixable in the long term.
* Greg: I want native look-and-feel for my users, they are too easily confused.
* Guido: Tk on the MAC and Windows is *not* a motif "program". It's buttons and scrollbars that just don't happen to be native look-and-feel... they are not that different!
* Roger: The Tk folks have promised native look-and-feel eventually
* Jim: We've heard all this before... let's assign this conversation to a 'macro' so we can replay it for the benifit of those who've not heard it before... Lets call it Macro 57 :-)
* Fred: I'm going to try and implement a Tkinter based GUI class browser in my spare time.
* OO Browsers storage format is ascii... which is a good starting point for the persistance so the tools can interoperate.

>Roger: The Tk folks have promised native look-and-feel eventually

Ээх. И это 1996 год :((

Для летней практики - Tk самое милое дело. Там есть лайоутманагер, так что пишется все просто на ура. Гулять больше надо, а не забивать себе голову низкоуровневым говном типа qt или gtk.

>> Roger: The Tk folks have promised native look-and-feel eventually

> Ээх. И это 1996 год :((

Дык авторы Tk абсолютно не виноваты, что qt и gtk не используют для своих настроек xrdb :)

> Это миф. Есть tile, есть tk8.5 с нормальной отрисовкой шрифтов, есть xresources наконец.

Вместо того, чтобы тащить tile для ruby (если он вообще есть), можно утащить gtk. tk8.5 стоит, всё-же погоняю его ещё.

> Она удобна. В особенности вкупе с тиклем.

Но я пишу на ruby :)

Ибо для Tk очень легко делать обёртки. У GTK или Qt надо делать свою обёртку для каждого класса и каждой функции, а в Tk надо обернуть только сравнительно небольшой сишный API, который позволяет работать с любыми объектами. Есть, правда, специализированные функции для работы со специфическими виджетами, типа канвасов, но их немного.

> Она удобна. В особенности вкупе с тиклем.

Ну и распишу немного:

1. Легко описывать гуй
2. Легко работать с event-driven задачами, одной из которых является гуй (это больше для связки с tcl)
3. Не надо компилировать => внезапно по месту демонстрации не вылезут странные глюки, которых ты не видел
4. Легко(опять же за счёт tcl) работать с бекэндами. Например, я одну лабу написал на языке maxima-ы, легко и непринуждённо приделав tk-шный гуй.

> Для летней практики - Tk самое милое дело. Там есть лайоутманагер, так что пишется все просто на ура.

Я ещё погоняю, но пока склоняюсь к выбору gtk.

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

Если qt или gtk - низкоуровневое говно, то что же такое xlib? :)))

>> Она удобна. В особенности вкупе с тиклем.

> Но я пишу на ruby :)

Дык напиши логику на руби а гуй на tk. Вполне себе юниксвейно.

Никаких оберток вообще не надо. Там есть wish и рисовать в него можно хоть из баша.

> Легко работать с event-driven задачами, одной из которых является гуй (это больше для связки с tcl)

А в gtk разве не так?

я когда пробывал гуй делать Tcl+Tk очень нравилось. Может и мне что-то сделать летом.

eveel, а ты над чем хочешь попрактиковаться летом? может вместе?

>> Легко работать с event-driven задачами, одной из которых является гуй (это больше для связки с tcl)

> А в gtk разве не так?

В GLanguage, на котором написан gtk, нет after/tkwait/vwait/update в явном виде, для fconfigure $fd -readable $command тоже придётся изрядно повозиться.

или есть желающие попрактиковаться в Tcl+Tk? знаю его посредственно, но хочу подучить.

Есть FXRuby, чем не подходит?

>В GLanguage, на котором написан gtk, нет after/tkwait/vwait/update в явном виде, для fconfigure $fd -readable $command тоже придётся изрядно повозиться.

фонатег тикля ниасилил замыкания.

>> для fconfigure $fd -readable $command тоже придётся изрядно повозиться.

> фонатег тикля ниасилил замыкания.

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

> Есть FXRuby, чем не подходит?

Тем, что FOX Toolkit...

> или есть желающие попрактиковаться в Tcl+Tk? знаю его посредственно, но хочу подучить.

Извиняюсь, но не хочется кучу времени убивать на всю это компьютерную хрень. Лето же: озеро, дача, всё остальное... :)

> Тем, что FOX Toolkit...

Извини, не понимаю. Что с ним не так?

>Можешь привести мне пример на C,

а почему на C?

for i in os.popen(cmd).readlines(): some_func(i)

чем не устраивает?

>А потом тупо сравним количество комманд.

то что ты мастер тупых сравнений - уже все давно знают =)

На Tk очень легко GUI делать. Очень легко. Причём без специальной среды разработки типа Visual TCL.

> for i in os.popen(cmd).readlines(): some_func(i)

> чем не устраивает?

Очевидно, тем, что открывает пайп в синхронном режиме :)

> Извини, не понимаю. Что с ним не так?

Один внешний вид чего стоит... Ей богу, Tk и то симпатичее, к тому же - идёт в комплекте :)

>Очевидно, тем, что открывает пайп в синхронном режиме :)

open3

тьфу, popen3

>> Очевидно, тем, что открывает пайп в синхронном режиме :)

> open3 

Чё? Приведи полный пример, где ведётся обработка содержимого
 пайпа в асинхронном режиме.

Вот тебе на тикле, чтоб видел, что требуется:

set s [open "find / -name \*.o"]
fconfigure $s -blocking 0
fileevent $s readable "readMe $s"
proc readMe chan {
   if {[gets $chan line] < 0} {
      if {[eof $chan]} {
         close $chan
         return
      }
   } else {
      puts stdout $line
   }
}

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

>Вот тебе на тикле, чтоб видел, что требуется:

на сях напиши, чтобы понятнее было

> Приведи полный пример, где ведётся обработка содержимого пайпа в асинхронном режиме.

Полный пример писать лень, асинхронные события ввода/вывода можно сделать с помощью g_io_add_watch.

> на сях напиши, чтобы понятнее было

Даже я не зная Тикля понял что там написано. geek, ты прикидываешься требуя расписать _асинхронную_ обработку на Сях ?

> Полный пример писать лень, асинхронные события ввода/вывода можно сделать с помощью g_io_add_watch.

Конечно, можно. Вопрос _только_ в удобстве. И "полный пример лень писать" говорит об отсутствии удобства для написания подобных вещей в glanguage.

>Даже я не зная Тикля понял что там написано.

ну так объясни.

> ну так объясни.

с треском слил и косишь под дурачка?

> ну так объясни.

открывается пайп в нонблок режиме, при появлении в нём данных, (типа select на fdr) вызывается процедура печатая на stdout строку из пайпа. Пока данных нет основная программа работает как обычно.

>Вопрос _только_ в удобстве.

удобство тут как бы ни причем. Или ты понимаешь, что программа делает - или нет. Если не понимаешь - то тебе и php лучше и vb удобнее =)

>И "полный пример лень писать" говорит об отсутствии удобства для написания подобных вещей в glanguage.

нет никакого glanguage =)

могу запостить куда-нить модуль watcher.py

>открывается пайп в нонблок режиме, при появлении в нём данных, (типа select на fdr) вызывается процедура печатая на stdout строку из пайпа. Пока данных нет основная программа работает как обычно.

open, fork, select, read и print? так бы и сказал сразу

причем тут glanguage, который тут попрекает gaa - я так и не понял. Может объяснит кто?

>Для летней практики - Tk самое милое дело. Там есть лайоутманагер, так что пишется все просто на ура. Гулять больше надо, а не забивать себе голову низкоуровневым говном типа qt или gtk.

Редкий случай, однако не согласиться с санычем нельзя.

> удобство тут как бы ни причем. Или ты понимаешь, что программа делает - или нет. Если не понимаешь - то тебе и php лучше и vb удобнее =)

То-то ты питон расхваливаешь...

> нет никакого glanguage =)

Это чтобы его с C не перепутать.

> могу запостить куда-нить модуль watcher.py

А сюда он по размеру не влезает? :)

> причем тут glanguage, который тут попрекает gaa - я так и не понял. Может объяснит кто?

Причём? При Gtk.

http://www.vitanuova.com/inferno/man/2/tk.html