[мысли thread] Стоит ли братья за GTK

Да GList-то Бог с ним, основная сложность - алгоритмы на нём, а не он сам :) Там и ногу проще отстрелить

С ассоциативными контейнерами, особенно без Glib, дело обстоит в разы печальнее

http://en.wikipedia.org/wiki/Qt_(framework)#Bindings

http://qt.nokia.com/products/programming-language-support

Такое чувство, что в этом коде работа с интерфейсом и обработка данных смешана в один поток

> В моих глазах C и C++ должны выполнять довольно узкий круг задач

это узкий взгляд на вещи )
Qt модульна - бери нужный модуль и не будет тебе «тяжести»

Правильно, а зачем их разделять? Интерфейса-то меньше, чем полстранички :)

PyGTK! Вот!

Тогда посмотри в сторону Gtk#.

Сейчас такое считается очень плохим стилем. В андроиде, например, работать с интерфейсом можно исключительно из ui потока, вызов большинства методов любого экранного объекта поднимает исключение.

> Я предпочту Mono/.NET, Qt мне очень напоминает VCL, к чему я возвращаться не хочу совсем.

В каком месте вы нашли у них что-то общее? VCL Вообще об принципах ООП не слишали, в то время как Qt весьма хорошо разработан.

В двух словах : Я не хочу писать на С++ с использованием тяжёлого фреймворка.

boost + gtkmm + ... + glade = Qt

gtkmm = QtGui

Два чая этому анонимусу

> boost + gtkmm + ... + glade = Qt

Я всё равно предпочту левую часть этой записи.

>У Qt кроме PyQt живых биндингов вроде и нету.

Ruby привязки живы. Брысь.

Я как-то и не пытался тебя переубедить, я хотел сказать что все преведенные тобою причины стандартные аргументры Т.Р.О.Л.Л.Я., которые не являются достаточно весомым фактом для отказа.

А о вас у меня сложилось мнение, что у вас тупо нет своего личного мнения и вы пользуютесь мнением ТРОЛЛЕЙ вместо того чтобы лично выбрать подходящий для вас инструмент.

Согласно этому сайту, последний релиз был 29.07.2010. Палкой тыкали?

ты себе противоречишь.

в каком месте?

И? 2010 это каменный век? Да вы, батенька, зажрались. Не все как GTK только функции выбрасывают, объявляя новые версии.

В IT год - это достаточно большой срок. А учитывая что разработчиков там 5 человек, я бы не стал брать это на долгосрочный проект.

Доо. Qt5 уже вышел что ле? Плюс оно базируется на Smoke. Тебе ещё туда надо смотреть.

не являются достаточно весомым фактом для отказа и нет своего личного мнения

получается, что я защищаю чьё-то мнение, важными для кого-то фактами что-ли ?

gtkmm предлагали?

> gtkmm предлагали?

да

окошки описывают в qt дизайнере. из получившегося ui генерится python или c++ код. руками это делают только извращенцы

>руками это делают только извращенцы

А если динамический интерфейс надо?

Да ну не хочется мне ввязываться в Qt...

> не смотря на то, что mono / net сейчас есть на любой машине

facepalm

тогда придется сношаться

ну тогда 2.71бись с gtk

> А если динамический интерфейс надо?

а если динамический интерфейс надо - не надо пользоваться статическими описателями интерфейсов, такими как glade или qtdesigner

> Я тоже недолюбливаю python, но для гуев возьму его вместо C, время дороже.

Потом пользователи будут недолюбливать тебя за тормозной GUI.

Чем мне понравилась идея валы, так это выплёвывание чисто C-шного кода, который можно скомпилировать. Помню, когда под офтопиком не хотелось устанавливать валу, а gtk уже был всё равно, пригодилось. Да и для проверки/поиска хитрой ошибки прекрасно! В отличие от плюсов.

А я бы создал базовый интерфейс с помощью дизайнера, а потом динамически подменял бы его части. Через glade (а теперь уже и gtkbuilder) можно получить указатель не только, скажем, на поле ввода, но и на его содержащий контейнер.

GTK уникален! Ведь для некоторых (многообещающих) языков (go), это вообще единственный биндинг, если не ошибаюсь.

тебя за тормозной GUI

Уж питон здесь вообще не при чем. Не он же виджеты рисует.

И чем это отличается от «рисования морды» в glade?

>Потом пользователи будут недолюбливать тебя за тормозной GUI.

Как питон сам по себе может затормозить GUI? GTK как была, так и останется сишной библиотекой, пусть даже её юзает питон. Или речь идёт о торможении диспетчеризации сообщений в ивентлупе изза тормозного питона?

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

> Вот понадобился мне ассоциативный контейнер на сишке, что делать? Юзать всякие RBTREE из /sys - привязываться к ОС, таскать их с собой лень

Ну, вот те, кому не лень, получают инвестиции на раскрутку в три ляма зелени. ;)

И да, «таскать с собой» - единственный реально работающий способ максимизации показателя переносимости на другие платформы.

С позиции разработчика я диву даюсь, что до сих пор (наблюдаю за этим уже без месяца 5 лет) в win32 нельзя в потоке вызвать диалог (http://developer.gnome.org/gdk/2.24/):

«GTK+ is „thread aware“ but not thread safe — it provides a global lock controlled by gdk_threads_enter()/gdk_threads_leave() which protects all use of GTK+. That is, only one thread can use GTK+ at any given time.

Unfortunately the above holds with the X11 backend only. With the Win32 backend, GDK calls should not be attempted from multiple threads at all.»

Проверял пару лет назад. Подвисает. Решение в обход: если после какой-то работы в потоке нужно вывести сообщение для пользователя, необходимо создать спец. функцию с этим диалогом, а потом зарегистрировать её вызов как idle-функцию. Ну и надеяться, что сразу после завершения работы в потоке приложению наступит этот idle, иначе будет непонятка. Ну а если таких диалогов много, то эффективной разработке такое не поспособствует.

Из ещё замеченных мною «кроссплатформенностей» была работа с последовательным портом/сетью. Было оно как-то через ..._unix_... / ..._win_... Ну да ладно, это ж glib, не gtk. Хотя они и дружат крепко.